Bygga eller köpa ett system för digitala produktpass (det ärliga svaret)

Du har en regulatorisk deadline — batterier 2027, textilier strax därefter — och ett beslut att fatta: bygga ett system för digitala produktpass internt, eller köpa ett. De flesta artiklar om "bygga eller köpa" är tunt förklädda säljpitchar. Den här försöker vara ärlig, inklusive när det faktiskt är rätt att bygga själv.

Vad "bygga ett eget" verkligen innebär

Ett DPP är inte en databasrad plus en webbsida. För att vara regelkompatibelt och användbart måste ett system klara av allt detta:

• en GS1 Digital Link-resolver med innehållsförhandling (HTML för människor, JSON-LD för maskiner, ett linkset för myndigheter);
• GTIN-/serienummerhantering med oföränderliga identifierare så att tryckta etiketter aldrig slutar fungera;
• oföränderlig, långlivad hosting av passdata (passet måste överleva din nästa CMS-migrering);
• tryckfärdig QR-generering i vektorformat (SVG/EPS) för etikettskrivare;
• kategorispecifik EU-validering — batterireglerna (förordning 2023/1542) och textil-/ESPR-reglerna skiljer sig fält för fält;
• lokaliserade konsumentsidor på EU:s olika språk;
• inlämning till EU-register, skanningsanalys och en revisionslogg.

En realistisk uppskattning för att bygga och driva detta internt är 100 000–500 000 € och mer, och 9–18 månader — och, vilket är avgörande, inget av det är din faktiska produkt.

Vad du får genom att köpa

Det tredje alternativet de flesta artiklar hoppar över: köp infrastrukturen, bygg din UX

Det är inte allt-eller-inget. De dyra, odifferentierade delarna — resolvern, oföränderlig hosting, QR-generering, EU-validering — är exakt det du inte bör bygga. Den del som är värd att äga är din varumärkesupplevelse och dina integrationer. Alltså: köp infrastrukturen via API, bygg din UX ovanpå.

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 är den ärliga omformuleringen av det klassiska argumentet "att bygga det kostar en förmögenhet": köp den del som är svår och likadan för alla; bygg den del som är din.

När det faktiskt är vettigt att bygga internt

För att vara rättvis — ibland är det det:

• DPP är din kärnprodukt (du säljer själv en plattform för regelefterlevnad);
• du har krav som ingen leverantör uppfyller (exotisk dataresidens, en skräddarsydd on-prem-stack);
• extrem skala där styckkostnaderna slår vilken SaaS som helst.

Utanför dessa fall är det vanligtvis en distraktion att bygga det odifferentierade tunga arbetet i stället för att leverera din faktiska produkt före deadline.

FAQ

Är inte ett API bara en annan sorts inlåsning? Mindre än att bygga ditt eget och bli inlåst i din egen ounderhållna kod. GTIN/serienummer är GS1-standarder; passdata är exporterbar JSON-LD. Standarderna är portabla i sin design.

Kan vi börja köpa och bygga senare om vi växer ur det? Ja — det är hela poängen med den hybrida vägen. Börja med API:et idag (klara deadlinen), insourca selektivt senare om ekonomin kräver det.

Hur är det specifikt med deadline-pressen? Att bygga tar 9–18 månader; batteri-DPP:er ska vara klara 2027. Om du inte har börjat bygga är att köpa den enda väg som klarar deadlinen.

Källor

• ESPR — Förordning (EU) 2024/1781
• EU:s batteriförordning 2023/1542

Kom igång gratis och lansera ett regelkompatibelt DPP idag: app.qr3.app/sign-up