You have a regulatory deadline — batteries in 2027, textiles soon after — and a decision to make: build a Digital Product Passport system in-house, or buy one. Most "build vs buy" articles are thinly veiled sales pitches. This one tries to be honest, including when building is actually the right call.
What "building your own" really involves
A DPP is not a database row plus a web page. To be compliant and useful, a system has to do all of this:
- a GS1 Digital Link resolver with content negotiation (HTML for people, JSON-LD for machines, a linkset for authorities);
- GTIN/serial management with immutable identifiers so printed labels never break;
- immutable, long-lived hosting of passport data (the passport must outlive your next CMS migration);
- print-ready QR generation in vector formats (SVG/EPS) for label printers;
- category-specific EU validation — the battery rules (Reg. 2023/1542) and textile/ESPR rules differ field by field;
- localized consumer pages across EU languages;
- EU registry submission, scan analytics, and an audit trail.
A realistic estimate for building and operating that in-house is €100k–500k+ and 9–18 months — and crucially, none of it is your actual product.
What buying gets you
| Build in-house | Buy (e.g. qr3.app) | |
|---|---|---|
| Time to first compliant DPP | 9–18 months | minutes |
| Upfront cost | €100k–500k+ | €0 (Free tier) |
| Ongoing | your engineering team | from €29/mo |
| Compliance updates (ESPR delegated acts) | you track + implement | included |
| GS1 resolver + content negotiation | build + operate | included |
| Localized consumer pages | build | included |
| Where your team's focus goes | infrastructure | your product |
The third option most posts skip: buy the infrastructure, build your UX
It is not all-or-nothing. The expensive, undifferentiated parts — the resolver, immutable hosting, QR generation, EU validation — are exactly what you should not build. The part worth owning is your branded experience and integrations. So: buy the infrastructure via API, build your UX on top.
import { QR3 } from "@qr3/sdk";
const client = new QR3({ apiKey: process.env.QR3_API_KEY! });
// The hard, compliance-heavy part — one call, straight from your ERP/PIM:
const passport = await client.dpp.create({
gtin: product.gtin,
serial: product.serial,
product_name: product.name,
manufacturer: "ExampleTech GmbH",
origin_country: "DE",
category: "battery",
battery_data: product.batteryData,
});
// Build YOUR experience on top: your dashboard, your branding, your
// integrations. React to scans in your own systems via webhooks:
// qr.scanned -> update analytics, trigger re-orders, flag a recall.
That is the honest reframe of the classic "building it costs a fortune" argument: buy the part that's hard and the same for everyone; build the part that's yours.
When building in-house actually makes sense
To be fair — sometimes it does:
- DPP is your core product (you're selling a compliance platform yourself);
- you have requirements no vendor meets (exotic data-residency, a bespoke on-prem stack);
- extreme scale where per-unit economics beat any SaaS.
Outside those cases, building the undifferentiated heavy lifting is usually a distraction from shipping your actual product before the deadline.
FAQ
Isn't an API just a different kind of lock-in? Less than building your own and being locked into your own unmaintained code. GTIN/serial are GS1 standards; passport data is exportable JSON-LD. The standards are portable by design.
Can we start buying and build later if we outgrow it? Yes — that's the point of the hybrid path. Start on the API today (meet the deadline), insource selectively later if economics demand it.
What about the deadline pressure specifically? Building takes 9–18 months; battery DPPs are due in 2027. If you haven't started building, buying is the only path that meets the deadline.
Sources
Start for free and ship a compliant DPP today: app.qr3.app/sign-up
