Build vs buy for EU age verification: the numbers, including the one that works against me

The three routes (and which one deserves numbers)

When someone evaluates building EUDI age verification in-house, they almost always cost the wrong scenario: implementing OID4VP from scratch, against the spec, with home-grown cryptography. Nobody in their right mind does that, so the "building is incredibly hard" argument collapses on its own — and anyone using it to sell you something is treating you like a fool.

The real routes are three:

• From scratch. Dismissed in the previous paragraph.
• Self-hosted on a pre-built engine. The actual build route. It comes in two flavours: open-source engines (there are several in the ecosystem; the one we know first-hand is EUDIPLO, Apache 2.0, in the OpenWallet Foundation's labs — espuni runs on it) and licensed stacks, which shift part of the maintenance onto a vendor in exchange for a licence fee and proprietary lock-in. The licensed flavour is really a hybrid: it looks more like buying than its buyer usually thinks, but without the exit clause we'll get to at the end.
• Managed service. Buying.

This article costs the second route honestly — including the break-even above which building wins and buying (from us, for instance) stops making sense. And one important note upfront: as you'll see, almost none of the maths depends on which engine you pick. I use EUDIPLO as the worked example because its weeks are what that path actually cost us — lived data, not brochure estimates.

What building costs: the honest scenario

Assume the favourable case: a senior developer who already knows OID4VP. That's not the common case — if nobody on the team has touched the ecosystem, add 4 to 6 weeks to the total — but it's the scenario that works least in my favour, which is why it's the one I use.

• Understand the AV Profile, DCQL, mso_mdoc, ISO 18013-5/7 — 2 to 4 weeks
• Deploy and configure the engine of your choice — 1 to 2 weeks
• Integration with your backend (sessions, webhooks, states) — 2 to 3 weeks
• Trusted List: parsing, certificate chains, caching, refresh — 1 to 2 weeks
• Frontend: QR, deep link, DC API, fallbacks, cross-device — 2 weeks
• Testing against real wallets — 1 to 2 weeks

Total: 9 to 14 weeks. At the fully loaded cost of a senior developer in Europe (€5,000–7,500 per month), that's €12,000 to €25,000 one-off. Infrastructure is noise next to it: €600–2,400 per year.

Notice one detail: of the whole list, the only line that depends on which engine you pick is the second one. The rest — understanding the profile, integrating with your business, operating Trusted Lists, fighting the frontend fallbacks, testing against real wallets — is yours whatever you choose. That's why it barely matters what goes in that box: the "I'd use a different engine" objection doesn't move the maths.

There's another honest detail worth stating: today there is no "AV-only" engine. Either you deploy a general-purpose credentials engine to query a single claim — complexity you don't use but do operate — or you pick a minimal component and the missing glue becomes your code. Either way, the cost lands back in the list above.

So far, building looks reasonable. The problem isn't in this list.

The cost nobody budgets

The initial integration is the visible part. The invisible part is that the ecosystem you just built on won't hold still:

• The Age Verification Blueprint evolves; v2 will bring changes.
• ISO 18013-7 is still in draft, and the browsers' Digital Credentials API keeps changing shape while it standardises.
• Every Member State ships its wallet with its own quirks. I already told this story with AltID: the Danish wallet flatly rejected requests the reference implementation accepted without blinking — strict schema validation, no DC API in v1, its own QR format. Seven more front-runners are on the way, each with its own reading of the same spec.
• Trusted Lists rotate certificates, and your issuer validation has to keep up.

None of this is hypothetical; it's the list of what has already changed in recent months. Keeping a verifier interoperable against that moving target costs, conservatively, 0.2 to 0.3 FTE on a continuous basis: €12,000 to €27,000 per year, forever. It's not a project; it's a permanent budget line. And it's the line that never shows up in the "we'll build it in a sprint" business case. (In the licensed flavour, part of this line turns into a licence fee — it changes name, not existence.)

The break-even, on the table

With those two numbers, the maths is one division:

break-even (verifications/year) = internal annual cost ÷ price per verification

At €25,000 per year of internal maintenance cost and a managed service priced in the low single-digit cents per verification, the break-even lands in the order of half a million verifications a year — around 40,000 per month, give or take depending on where in that band the price sits.

That number works against me and I'm publishing it anyway: above ~40,000 verifications per month, building on an open-source engine pays off if you have the team and want that work in your backlog. I won't tell you otherwise.

Below it, the asymmetry is brutal. A platform doing 5,000 verifications a month pays a managed service a few thousand euros a year at most — against €25,000 or more in year one alone of building it. Well over ten times more expensive to build. And it's no accident that the threshold falls where the largest integrations live: at that volume, the conversation is a different one.

The CFO's objection: CapEx vs OpEx

There's a legitimate financial objection: building is paying once, a service is paying forever, and some CFOs prefer the former on principle. The honest answer is that building is not paying once. It's paying once for the integration plus a fraction of a person indefinitely — the previous section. If the internal business case only contains the first half, it isn't miscalculated: it's incomplete.

"But the engine already exists and it's free"

True, and it's the best argument on the build side — which is why this article uses it as its baseline instead of hiding it. A competent team can stand up EUDIPLO, or any of its alternatives, in a matter of days.

But the engine is the engine, not the car. It doesn't come with the metering and session layer over your business, or the frontend with every fallback real wallets demand, or Trusted List operations, or — above all — someone whose job is to track the specification for you while seven Member States ship seven wallets with seven different behaviours. The engine is 70% of the work. The car is most of the rest.

Vendor risk, also on the table

If you're evaluating buying, there's an uncomfortable question you should ask any vendor, me included: what happens if you disappear? Your DSA Article 28 compliance can't depend on your vendor doing well.

Our answer isn't a promise; it's structural: espuni is built on the same open-source EUDIPLO you could deploy yourself. If we're gone tomorrow, you deploy EUDIPLO, point your integration at it and keep operating — with the maintenance cost from this article, but without rewriting anything. That's exactly the exit clause a proprietary stack can't offer you, and the reason building-on-open-source isn't just a technical choice of ours: it mitigates your risk, not ours.

What you buy today isn't where it ends

One more thing that changes the maths over a multi-year horizon. Age verification is not a standalone system: it runs on the same rails as the entire European identity wallet ecosystem — OID4VP, mdoc credentials, Trusted Lists. It is, deliberately, the first use case of that infrastructure to reach production.

Which means today's decision isn't just "AV yes or no". The EUDI ecosystem will keep adding credential types — identity attributes, driving licences, whatever each Member State issues next — and each will bring its own paradigm shifts, just as AV is bringing its own now. Whoever builds in-house goes back to the task list above for every one of them. Our service is built on those common rails precisely so it can grow with them: the integration that verifies age today is the same API through which we'll keep supporting what comes next, with the ecosystem's changes absorbed on the far side of that API, progressively, so no single shift becomes a project of yours. Integrating early with AV is, in practice, entering the European wallet through the small door — and never having to go through the big one.

The practical takeaway

You could run your own SMS gateway; nobody does, and not because it's impossible. The right question was never "can we build it?" — on a pre-built engine the answer is yes, in a quarter. The question is whether you want to own this problem forever.

The value of buying isn't in the initial integration: it's in never having this topic in your backlog. It's that when the next Member State ships its wallet and something breaks — and it will, because it already has — the sprint that breaks isn't yours.

And if you're moving more than 40,000 verifications a month: the numbers above are yours, use them. They're the same ones I would use.

---

The figures in this article are my own estimates based on European market costs and on the experience of building espuni on top of EUDIPLO (OpenWallet Foundation Labs, Apache 2.0); the task breakdown reflects the real work described in earlier articles in this series, including testing against AltID's test environment. Nothing here reflects internals of any employer's systems; all linked sources are public.