DPP Build vs Buy — Should You Build Your Own DPP System?

The Question Every Tech-Forward Brand Asks Eventually

It usually starts in a product meeting. Someone from engineering mentions that the DPP data structure doesn't look too complicated. A few JSON fields, a QR code generator, maybe a simple API — how hard could it be? The slide deck gets built. The case for building internally gains momentum.

This instinct isn't entirely wrong. For a handful of companies, building makes genuine sense. For most, it leads to a project that costs four times the original estimate, takes eighteen months instead of four, and then requires a rewrite when the first Delegated Act drops with different mandatory data fields than anyone anticipated.

Before your engineering team writes a single line of code, this analysis is worth reading carefully.

What Building a DPP System Actually Involves

The people who underestimate build complexity usually think of DPP as a data storage and QR code problem. Store product data, generate a QR code that links to it, done. That's technically accurate but misses most of the real requirements.

A production-ready DPP system needs: a data schema that maps to ESPR regulation requirements across multiple product categories; a mechanism to update that schema as Delegated Acts are finalised without breaking existing passports; QR code generation that meets GS1 Digital Link standards; passport page rendering that works across devices in multiple languages; an audit trail that proves data integrity over the passport's lifetime (which must match product lifetime); supplier-facing input interfaces so you're not manually entering data from emails; API access so your ERP can push data automatically; and a compliance reporting layer so you can demonstrate conformity to regulators.

That's not a weekend project. It's a medium-complexity software product, and it needs to be maintained like one.

The Real Costs of Building In-House

Initial development: €100,000–€500,000+

This range depends heavily on scope and team composition. A minimum viable DPP system — basic data entry, QR generation, simple passport page — might be built in 3-4 months by two senior developers. Call it €60,000–€80,000 at market rates. But "minimum viable" rarely survives contact with compliance requirements. By the time you add audit trails, supplier interfaces, regulatory mapping, and multi-language support, you're looking at 6-12 months and a team of four. At €80,000–€100,000 per developer per year fully loaded, that's €160,000–€400,000 before the system is production-ready.

Some enterprise teams report initial builds exceeding €500,000 when they include the data architecture work, security audits, and the inevitable scope creep that comes from discovering mid-project what ESPR actually requires.

Regulatory update costs: €20,000–€80,000 per major update cycle

This is the cost most build advocates forget to model. ESPR Delegated Acts are being finalised category by category over the next several years. Each one may add mandatory data fields, change verification requirements, or alter technical standards for QR codes and data formats. Every time that happens, your custom system needs a developer to interpret the regulatory text, redesign affected data schemas, migrate existing passports, update supplier-facing interfaces, and re-validate compliance.

A platform built by a company whose entire business is DPP compliance handles this as a core product function. Your internal team handles it as an interruption to their other work, at full developer-hour cost.

Ongoing infrastructure and maintenance: €30,000–€100,000/year

Hosting, security patching, database maintenance, performance monitoring, bug fixes, and the occasional developer who needs to be onboarded when the original builder leaves. Custom software doesn't maintain itself. Budget a minimum of one developer at 25% allocation to keep a basic DPP system running reliably, more if you have complex integrations or high passport volumes.

The full cost picture is explored in more detail in our article on digital product passport costs.

The Time-to-Market Problem

ESPR enforcement is not waiting for your development team to finish sprints. The battery regulation Delegated Act is already in force. Textile requirements are rolling out. Electronics and other categories follow.

A typical build project — properly scoped, reasonably staffed — takes 9-18 months from kickoff to production deployment. A SaaS platform like DPP-Tool can have your first compliant passports live in days, and your full product catalogue covered within weeks.

That time difference has regulatory risk attached to it. Operating without compliant passports during an enforcement period exposes you to fines and potential market access issues in the EU. Being six months late to compliance because your build project ran long is not a mitigating factor regulators will accept.

Review the DPP requirements checklist to understand current enforcement timelines for your product category.

When Building Actually Makes Sense

There are genuine scenarios where an in-house build is defensible:

Massive scale with existing infrastructure: If you're a manufacturer with 50,000+ SKUs and an existing team of 20+ engineers who already maintain complex product data systems, the marginal cost of building DPP capability into your existing infrastructure may be lower than adopting and integrating an external platform. The key word is marginal — you're not building from scratch, you're extending.

Highly specialised compliance requirements: Certain regulated sectors (aerospace components, medical devices, nuclear equipment) have DPP-adjacent requirements so specific that no horizontal platform will fit without significant customisation. At that point, building something tailored may genuinely be cheaper than wrestling a general-purpose platform to fit.

Existing data platform that can be extended: Some large manufacturers have sophisticated PLM (product lifecycle management) or PIM (product information management) systems that already hold most of the data a DPP requires. Adding DPP output and QR code generation to an existing system is meaningfully cheaper than either building from scratch or adopting a separate DPP platform.

Notice what's not on this list: "we have good developers," "we want to own the data," "we don't want vendor lock-in," or "we think we can do it cheaper." These are arguments people make for building that rarely hold up once the actual project is scoped.

When Buying Is the Obvious Choice

For the vast majority of companies — including most that initially consider building — buying a dedicated DPP platform is the right call. The signals that point clearly toward buying:

Your engineering team has other priorities. DPP compliance is important, but so is your core product. Every developer month spent on DPP infrastructure is a developer month not spent on features that differentiate your business.

You have fewer than 5,000 SKUs. Below this threshold, even a mid-market SaaS plan costs a fraction of what self-managed infrastructure would.

You need to be compliant within the next 6 months. There's no realistic path to a production-ready custom system in that timeframe.

Your compliance requirements are standard. If you're in textiles, consumer electronics, furniture, or batteries — the product categories ESPR is targeting first — a general-purpose DPP platform already maps to your requirements. You don't need custom-built.

You want regulatory updates handled for you. This is underrated. The cost of staying current with ESPR as Delegated Acts roll out is real and ongoing. Outsourcing that problem to a specialist platform makes sense unless you have deep regulatory expertise in-house.

The DPP software comparison walks through specific platform options across the price spectrum. Understanding what's available is the first step to a good buy decision.

The Hybrid Path Worth Considering

Some companies start with a SaaS platform to get compliant quickly, then evaluate after 12-18 months whether any aspects justify custom development. This approach has real advantages: you learn your actual data requirements from production use before making architecture decisions, you avoid the regulatory risk of a long build timeline, and you preserve engineering capacity for your core product during the critical compliance window.

DPP-Tool's API access on higher plans makes this approach practical — you can build integrations with your internal systems without rebuilding the entire passport infrastructure. Check the features page for current API capabilities and the pricing page for plan comparison.

If you're at the stage of actually creating your first passports, the DPP creation guide covers the practical steps regardless of which platform or approach you choose.

The Honest Verdict

Building your own DPP system is a legitimate choice for a small number of large enterprises with specific circumstances. For everyone else — and that is the vast majority of companies facing DPP compliance requirements — buying a purpose-built platform is faster, cheaper in total cost of ownership, and lower-risk from a regulatory timeline perspective.

The engineering energy that would go into building and maintaining a custom DPP system is almost certainly better spent on your actual product. DPP compliance is a legal requirement, not a competitive differentiator. Treat it accordingly.