Byg vs. køb et Digital Product Passport-system (det ærlige svar)

Du har en lovgivningsmæssig deadline — batterier i 2027, tekstiler kort efter — og en beslutning at træffe: byg et Digital Product Passport-system selv, eller køb et. De fleste "byg vs. køb"-artikler er tyndt forklædte salgstaler. Denne her forsøger at være ærlig, herunder hvornår det rent faktisk er det rigtige at bygge selv.

Hvad det "at bygge sit eget" reelt indebærer

Et DPP er ikke bare en databaserække plus en webside. For at være compliant og brugbart skal et system kunne alt dette:

• en GS1 Digital Link-resolver med content negotiation (HTML til mennesker, JSON-LD til maskiner, et linkset til myndigheder);
• GTIN-/serienummer-håndtering med uforanderlige identifikatorer, så trykte etiketter aldrig bliver ugyldige;
• uforanderlig, langtidsholdbar hosting af passdata (passet skal overleve din næste CMS-migrering);
• printklar QR-generering i vektorformater (SVG/EPS) til etiketprintere;
• kategorispecifik EU-validering — batterireglerne (Forordning 2023/1542) og tekstil-/ESPR-reglerne adskiller sig felt for felt;
• lokaliserede forbrugersider på tværs af EU-sprog;
• indberetning til EU-register, scanningsanalyse og et revisionsspor.

Et realistisk estimat for at bygge og drive dette internt er 100.000–500.000+ € og 9–18 måneder — og afgørende: intet af det er dit egentlige produkt.

Hvad du får ud af at købe

Den tredje mulighed, de fleste artikler springer over: køb infrastrukturen, byg din UX

Det er ikke enten-eller. De dyre, udifferentierede dele — resolveren, den uforanderlige hosting, QR-genereringen, EU-valideringen — er præcis det, du ikke bør bygge. Den del, der er værd at eje, er din brandede oplevelse og dine integrationer. Altså: køb infrastrukturen via API, og byg din UX ovenpå.

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.

Det er den ærlige omformulering af det klassiske argument om, at "det koster en formue at bygge det": køb den del, der er svær og ens for alle; byg den del, der er din egen.

Hvornår det rent faktisk giver mening at bygge selv

For at være fair — nogle gange gør det:

• DPP er dit kerneprodukt (du sælger selv en compliance-platform);
• du har krav, som ingen leverandør opfylder (eksotisk datalokalisering, en skræddersyet on-prem-stak);
• ekstrem skala, hvor økonomien pr. enhed slår enhver SaaS.

Uden for disse tilfælde er det at bygge det udifferentierede tunge arbejde som regel en distraktion fra at få dit egentlige produkt ud inden deadline.

FAQ

Er et API ikke bare en anden slags lock-in? Mindre end at bygge dit eget og være låst inde i din egen uvedligeholdte kode. GTIN/serienummer er GS1-standarder; passdata er eksporterbar JSON-LD. Standarderne er bærbare fra bunden.

Kan vi begynde med at købe og bygge selv senere, hvis vi vokser fra det? Ja — det er hele pointen med den hybride vej. Start på API'et i dag (nå deadline), og insourc selektivt senere, hvis økonomien kræver det.

Hvad med selve deadline-presset? At bygge tager 9–18 måneder; batteri-DPP'er skal være klar i 2027. Hvis du ikke er begyndt at bygge, er det at købe den eneste vej, der når deadline.

Kilder

• ESPR — Forordning (EU) 2024/1781
• EU's batteriforordning 2023/1542

Start gratis og udgiv et compliant DPP i dag: app.qr3.app/sign-up