DPP Build vs Buy: An Honest Comparison

The build-or-buy question is usually framed as though it were the main decision on a passport programme. It is not, and treating it that way conceals where the effort and the risk actually sit.

What the decision actually covers

A passport programme divides into work that is specific to your organisation and work that is identical for everybody. Only the second is available to buy.

The first three rows are where most of the calendar time goes, and none of them changes based on the build-or-buy decision. A team that expects a purchase to remove them is going to be disappointed a quarter in.

What building genuinely means

Building is more tractable than vendors suggest for the core mechanics. A resolver is a service that maps identifiers to records with content negotiation. Serving a passport is a web application. Neither is difficult engineering.

The difficulty is not the first version. It is everything that follows.

• Regulatory change — every delegated act adjusts required attributes, and somebody has to track and implement that indefinitely.
• Key management — signing infrastructure, rotation and retention of retired keys, done correctly rather than approximately.
• Availability — a passport that fails to resolve is a compliance failure, not a degraded experience.
• Retention — records must remain reconstructible for the period the regulation specifies, across system migrations.
• Access control — the public and permissioned split is genuinely intricate and easy to get subtly wrong.

The first item is the one that changes the arithmetic. A build is not a project with an end date; it is a permanent commitment to tracking regulatory change across every product group and every market you operate in.

What buying genuinely covers

A platform gives you the commodity layers and, more valuably, somebody whose job is to follow the regulation so your team does not have to.

What it does not give you is populated data. Every platform arrives empty, and filling it is the work in the first three rows of the table above.

When building is defensible

There are genuine cases, and they share a characteristic: the organisation already carries the recurring costs that make building expensive for everybody else.

A company with an existing regulatory affairs function tracking product legislation across markets already pays for the change-tracking. One with a mature platform engineering group already pays for availability and key management. For them the marginal cost of building is genuinely lower than it looks.

The other defensible case is unusual product complexity. Where a product does not fit the shapes a general platform models — deeply configurable industrial equipment, products whose identity changes through their life — a bought platform may need enough adaptation to lose its advantage.

When buying is clearly right

The straightforward cases are organisations without an existing regulatory tracking capability, or without engineering capacity to commit permanently rather than temporarily.

For small and medium manufacturers this is close to decisive. The engineering is not beyond them; the indefinite obligation to follow delegated acts across product groups is, because it requires a function they do not have and cannot justify creating for this purpose alone.

The hybrid that usually wins

Most organisations land somewhere between, and the split that works follows the line between commodity and specific rather than any technical boundary.

Note that the two layers you keep are the two that would be hardest to move to a different vendor later, which is a useful property. Portability is preserved where it matters.

How the costs actually compare over time

Comparisons usually put a build’s development cost against a platform’s subscription and stop there. That framing flatters building, because it counts the part of a build that ends and ignores the part that does not.

The last two rows are what decide it for most organisations. A build sized for one product group in one market is a reasonable piece of work; the same build extended across six product groups as delegated acts arrive is a standing team.

That is not an argument that building is wrong. It is an argument that the comparison should be made against the portfolio you will have in five years rather than the pilot you are starting with, because the pilot is the case where building looks cheapest and least resembles the eventual obligation.

Questions worth asking either way

Whichever direction you take, the same questions determine whether the result survives contact with the second product group.

Can passport records be exported in full, including history? Are identifiers ones you control, or ones tied to a supplier? What happens to resolution if the arrangement ends? How is a record from three years ago reconstructed for an audit? A build answers these by construction; a purchase answers them in a contract, and the answers should be read before signing rather than after.