Operations

    Build vs Buy a Packaging Compliance System: When Internal Build Stops Making Sense

    The build-vs-buy decision for packaging compliance is not just spreadsheets vs SaaS. The third option, an internal data lake or custom-built compliance stack, is real, technically feasible, and often the wrong call. Here is the engineering reality of internal build and the breakeven where it stops being defensible.

    By Kevin Kai Wong, Managing Partner at gCurv Technologies

    June 2, 2026

    Build vs Buy a Packaging Compliance System: When Internal Build Stops Making Sense

    Table of Contents

    1. 1.The three options, not two
    2. 2.Why internal build is tempting
    3. 3.What an internal build actually has to deliver
    4. 4.The hidden TCO of internal build
    5. 5.When internal build still makes sense
    6. 6.Where internal build typically breaks
    7. 7.How to decide
    8. 8.What this means operationally
    9. 9.What to do in 2026
    10. 10.How Packgine helps
    Share:

    The three options, not two

    The build-vs-buy conversation in packaging compliance often gets framed as spreadsheets vs SaaS, see EPR: Spreadsheets vs Software Compared for that comparison. But the real choice for many mid-to-large producers is three-way:

    Option A: Spreadsheet stack. Manual data assembly, manual filing prep, manual evidence storage. Low capex, high opex, low scalability.

    Option B: Internal build. A data lake, warehouse, or custom-built compliance application maintained by an internal engineering team. Treats compliance as another internal data product.

    Option C: Dedicated compliance platform. A vendor-built application designed for the use case.

    The first option is what most producers start with. The third is what vendors sell. The second, internal build, is what many engineering-strong producers reach for first, and where most build-vs-buy decisions actually go wrong.

    Why internal build is tempting

    Producers with mature data engineering teams often consider internal build because:

    • The packaging data is already in their data lake or warehouse.
    • The internal team can join packaging data to sales data, supplier data, and finance data without integration work.
    • "We can build this" is true in a literal sense, the components are not exotic.
    • Internal build avoids vendor lock-in and per-seat licensing.
    • The compliance work feels like reporting, which the team is already good at.

    For a single-jurisdiction filing on a stable rule base, internal build can work fine. The problem is that compliance is not a single-jurisdiction stable-rule-base problem.

    What an internal build actually has to deliver

    A defensible internal build for multi-jurisdiction packaging compliance has to deliver, at minimum:

    Component-level data model. Per-component weights, materials, recycled content, recyclability attributes, supplier evidence references. Effective-dated. With audit history.

    Jurisdictional taxonomy mappings. Each internal material category mapped to UK pEPR categories, EU PPWR categories, California SB 54 categories, Oregon, Colorado, Maine, Maryland, Minnesota, Washington categories, each with its own rule and refresh cadence.

    Producer determination logic. Per SKU, per jurisdiction, with the rule applied.

    Channel and country attribution. Tying sales volumes to placement-on-market jurisdictions with documented allocation rules.

    Evidence storage and linkage. Supplier declarations, certifications, mass balance documentation, with structured metadata and validity tracking.

    Reporting templates per PRO and per regulator. Each in the format the receiving entity expects, with format updates as PROs change their requirements.

    Audit trail. Who changed what, when. For every field, for every period.

    Filing reproducibility. The ability to re-derive a prior period's filing from the underlying data and methodology.

    Change-of-rules handling. When a jurisdiction updates its taxonomy, fee schedule, or evidence requirements, the system propagates the change without requiring full re-tagging.

    This is not a weekend project. It is also not a one-quarter project. A realistic internal build, done well, takes 6 to 18 months and continues to consume engineering capacity indefinitely.

    The hidden TCO of internal build

    Internal build cost is not just initial development. Steady-state ongoing cost includes:

    Engineering capacity. 1 to 3 engineers maintaining the platform, depending on scope. Continued work on integrations, performance, evidence handling, reporting.

    Regulatory analyst capacity. Someone has to track rule changes across jurisdictions and translate them into platform updates. Without this, the platform decays.

    Methodology specialists. Per-jurisdiction depth that the engineering team does not have. Either internal hires or consultants.

    Opportunity cost. Engineering capacity spent on compliance is engineering capacity not spent on the producer's actual product.

    Risk cost. A bug in an internal build that produces a wrong filing is the producer's problem. There is no vendor to escalate to.

    A realistic internal-build TCO for mid-to-large multi-jurisdiction producers is rarely under $750K, $2M annually once steady-state is reached, and the opportunity cost is on top of that. Ranges depend heavily on internal cost structure; substitute your own figures before quoting these to finance.

    When internal build still makes sense

    Internal build can be the right call when:

    • The producer has a single jurisdiction or two, both of which are stable.
    • The packaging portfolio is narrow (one material, few formats, low SKU complexity).
    • The producer has unusual data requirements that no vendor handles well.
    • Compliance is integrated with another internal system in a way that vendor solutions cannot replicate.
    • The producer has confirmed engineering and regulatory capacity to maintain the build over years.

    Outside those conditions, internal build is usually a 24-month detour that arrives at the same buying decision after burning capacity.

    Where internal build typically breaks

    Break point 1, Adding the third jurisdiction. Two jurisdictions can be hand-modeled. The third reveals that the modeling abstractions were jurisdiction-specific and have to be redone.

    Break point 2, A regulator changes a rule. The engineering team has to re-tag historical data and re-run prior filings. The internal build has no built-in versioning of regulatory rules.

    Break point 3, Audit response. The regulator asks for evidence in a format the internal build cannot produce without weeks of engineering work. The producer scrambles.

    Break point 4, The lead engineer leaves. The internal build was their project. Documentation is patchy. The remaining team cannot maintain the system at the same pace.

    Break point 5, Vendor solutions catch up. What was a build advantage two years ago becomes a buy advantage as platforms mature. The internal build is now a maintenance burden, not a strategic asset.

    How to decide

    The decision factors that actually matter:

    • Jurisdictional count and growth trajectory. More jurisdictions tilts toward buy.
    • Rule volatility. More volatile rules tilt toward buy (vendors absorb the volatility).
    • Engineering availability. Less engineering capacity tilts toward buy.
    • Methodology requirements. Standard methodologies tilt toward buy. Genuinely novel ones may justify build.
    • Audit risk. High audit exposure tilts toward buy (vendor accountability is a feature).
    • Existing system landscape. Strong fit with existing systems can tilt toward build, but rarely as much as the team initially thinks.

    The producers who get this right tend to evaluate honestly. The producers who get it wrong tend to over-estimate internal capacity and under-estimate ongoing maintenance.

    What this means operationally

    The build-vs-buy decision is not made once. Most producers who built internally end up buying within 24 to 36 months when the build's maintenance burden becomes visible. Producers can save the detour by being honest about the inputs upfront.

    A clean way to evaluate: write down the steady-state TCO for build (engineering, regulatory, methodology, opportunity cost) for the next three years. Compare to vendor pricing for the same scope. The decision is usually clear once the steady-state numbers are on the table.

    What to do in 2026

    • If you are considering build, write down the steady-state staffing model and the three-year TCO before committing.
    • Identify what specifically internal build would deliver that vendor solutions cannot. If the answer is "we'd own it," that is not enough.
    • For producers already operating an internal build, evaluate whether the maintenance burden is sustainable and whether the original rationale still holds.
    • For producers in a vendor evaluation, treat internal build as a real third option to compare against, not a default fallback if vendors disappoint.

    How Packgine helps

    Packgine handles the volume of regulatory rule maintenance and jurisdictional taxonomy updates that consume internal engineering capacity in a build. Producers stay focused on data quality and methodology, the parts of compliance that are theirs to own, while the platform handles the rule layer that changes on regulators' calendars, not theirs.

    See the producer-side workflow or book a working session.

    Ready to automate your packaging compliance?

    See how Packgine manages EPR, PPWR, and sustainability reporting from a single dashboard.

    Other Related Content

    The Packaging Data Model: What Fields You Actually Need at SKU and Component Level

    May 8, 2026

    The Packaging Data Model: What Fields You Actually Need at SKU and Component Level

    ERP Integration Patterns for Packaging Compliance: Pulling Data from SAP, Oracle, NetSuite, and D365

    May 5, 2026

    ERP Integration Patterns for Packaging Compliance: Pulling Data from SAP, Oracle, NetSuite, and D365