Build vs buy the EPCIS 2.0 layer: the real three-year cost is the second implementation, not the first

Every build-vs-buy memo for a standards layer makes the same mistake: it prices the first implementation. Weeks to a working capture endpoint, a sprint for the XML importer, a few days for the hash. It looks buildable — a couple of engineers, a quarter, done. So the memo says build, and it's not wrong about the first implementation.

It's wrong about the second one. And the third. Because a conformance layer is not a feature you ship once; it is a standing obligation welded to a document you don't control, and the document keeps revising. The true cost isn't the code you write this quarter. It's the engineer you can't reassign for three years because the standard moved, a supplier sent a dialect your parser has never seen, and a customer's auditor is now asking a question your "we support EPCIS" answer can't survive.

This is the honest CFO-legible version of the decision. No primary source needed — this is an argument about engineering economics, and you can check every number against your own team's history with standards work.

The first implementation is cheap. That's the trap.

Standing up an EPCIS 2.0 capture-and-query interface against GS1's OpenAPI description is genuinely not hard. A competent engineer does it. The demo works. The RFP cell gets a "Yes."

Then the cost structure inverts, and everything expensive arrives after the memo was approved:

• The standard revises, and your pin has to move. EPCIS and CBV are living standards. Every revision is a diff you have to read, a schema you have to re-pin, a test suite you have to re-green — forever, on your maintenance budget, whether or not you shipped a single customer feature that quarter.
• The translator is 90% the same as everyone else's and 100% yours to maintain. Decade-old 1.1/1.2 XML — extension-wrapped, namespace-salted, CBV in the shape it was in eight years ago — is where importers go to die. The parser you write is nearly identical to the one every other vendor wrote, differentiates your product by zero, and is the thing you're patching at 2 a.m. when a supplier sends a dialect you've never seen.
• The event hash has to match a stranger. The §8.9 hash is only worth computing if it byte-matches what your customer's other vendor computes. Getting that right — and keeping it right across GS1 Digital Link normalisation edge cases — is a permanent interop liability, not a one-time task.
• The conformance question comes back with an auditor attached. "We support EPCIS 2.0" was never the same claim as "we can demonstrate it." The first time a customer's auditor tests it, you discover which one you actually built — and if it's the first, you're now doing the second under deadline.

None of that showed up in the memo, because the memo priced the demo. The demo is the cheapest moment in the layer's entire life.

Every engineer on the standard is a feature you didn't ship

Here's the framing that makes the decision legible to a CFO who has never heard of EPCIS: conformance differentiates your product by exactly zero.

Your customers didn't choose you for your schema validator. They chose you for the RFID deployment software, the record-keeping workflow, the traceability product with your name on the renewal. Every engineer-quarter you spend on the standards layer is an engineer-quarter not spent on the thing they're actually paying for — and it buys you no competitive advantage, because your competitors all have to pay the same tax to say the same "Yes." It is pure cost of participation, and it compounds: the maintenance liability grows with every standard revision and every supplier dialect, while the differentiation it produces stays flat at zero.

Put the three-year number in front of the memo, not the three-week one:

• Year 1: the "cheap" build, plus the first schema revision, plus the first three supplier dialects your parser didn't anticipate.
• Year 2: an engineer you can't spare now permanently owns the translator and chases schema revisions; the first customer audit lands and you're reworking the hash to match someone else's vectors.
• Year 3: the layer is a load-bearing dependency nobody wants to touch, staffed by whoever drew the short straw, and the conformance question is still recurring — now as a renewal risk.

That is the real cost, and it is a subtraction from your roadmap, not a line in your infrastructure budget.

What "buy" actually means here: a pinned dependency, not a vendor lock-in

The reflex against "buy" for a standards layer is reasonable — you don't want to trade a maintenance liability for a proprietary dependency you can't inspect or leave. So be precise about what the right "buy" is: it is not a black-box SaaS. It is the conformance surface taken as a pinned, inspectable dependency — built against GS1's official OpenAPI (not a proprietary API you'd have to wrap), pinned by digest, and evaluated the only way that counts: by running it on your own corpus, not by taking a meeting.

The economics that flip: the schema pin, the round-trip translator, the §8.9 hash against independent vectors, the RFC 7807 exception behaviour — these move once, in one place, for everyone embedding the layer, instead of once per revision, in your codebase, on your budget. The 90%-identical translator every vendor rebuilds gets built and maintained a single time. Your squad goes back to the 10% that is actually yours and actually differentiating.

If you want that same layer from the implementing engineer's side — the eight laws the standard implies but doesn't hand you as code, and how to stand up capture and query without reinventing the interfaces — that's the developer view: how to stand up an EPCIS 2.0 repository without reinventing the standard.

Proof, not adjectives. The embeddable layer this argues for answers today — POST /translate, /validate and /hash on this origin, npx epcis.dev on your own bench. Our intent is that capture is $0 per event — intent, until published terms bind it. The build-vs-buy math above holds regardless of price, because the expensive variable was never the license — it was the three years of your own engineers.

The decision, stated cleanly

Build, and you own a standards implementation forever: a translator you patch at 2 a.m., a pin you chase every revision, a conformance answer that fails its first real audit, and an engineer you can't reassign — all to differentiate your product by zero. Buy the right way — a pinned, inspectable, standards-native layer you embed underneath your product — and the maintenance liability moves off your roadmap while your squad goes back to what your customers actually pay for.

The way to test that claim is not a demo. It's your own worst corpus.

→ Get a capture key — conformance evaluation

Line up the decade-old customer XML that broke your last importer and the interop hash you need to match. That corpus is the evaluation. One address, one row. Keys are provisioned from this list, in order. One email when yours is ready — one, not a drip campaign. No account, no demo, no sequence.