Tienes una fecha límite regulatoria —las baterías en 2027, los textiles poco después— y una decisión que tomar: desarrollar internamente un sistema de Pasaporte Digital de Producto o comprar uno. La mayoría de los artículos sobre "desarrollar vs comprar" son argumentos de venta apenas disfrazados. Este intenta ser honesto, incluyendo cuándo desarrollar es realmente la decisión correcta.
Qué implica realmente "desarrollar el tuyo propio"
Un DPP no es una fila de base de datos más una página web. Para ser conforme y útil, un sistema tiene que hacer todo esto:
- un resolver de GS1 Digital Link con negociación de contenido (HTML para personas, JSON-LD para máquinas, un linkset para las autoridades);
- gestión de GTIN/número de serie con identificadores inmutables para que las etiquetas impresas nunca dejen de funcionar;
- alojamiento inmutable y de larga duración de los datos del pasaporte (el pasaporte debe sobrevivir a tu próxima migración de CMS);
- generación de QR lista para impresión en formatos vectoriales (SVG/EPS) para impresoras de etiquetas;
- validación específica de la UE por categoría: las normas para baterías (Reg. 2023/1542) y las normas de textiles/ESPR difieren campo por campo;
- páginas para el consumidor localizadas en los distintos idiomas de la UE;
- envío al registro de la UE, analíticas de escaneo y un registro de auditoría.
Una estimación realista para desarrollar y operar eso internamente es de 100.000-500.000 € o más y de 9 a 18 meses y, lo que es crucial, nada de eso es tu producto real.
Qué consigues al comprar
| Desarrollar internamente | Comprar (p. ej. qr3.app) | |
|---|---|---|
| Tiempo hasta el primer DPP conforme | 9-18 meses | minutos |
| Coste inicial | 100.000-500.000 €+ | 0 € (plan gratuito) |
| Coste continuo | tu equipo de ingeniería | desde 29 €/mes |
| Actualizaciones de cumplimiento (actos delegados de la ESPR) | tú haces el seguimiento + implementas | incluido |
| Resolver de GS1 + negociación de contenido | desarrollar + operar | incluido |
| Páginas para el consumidor localizadas | desarrollar | incluido |
| Dónde se centra tu equipo | infraestructura | tu producto |
La tercera opción que la mayoría de los artículos omiten: compra la infraestructura, desarrolla tu UX
No es todo o nada. Las partes caras y no diferenciadoras —el resolver, el alojamiento inmutable, la generación de QR, la validación de la UE— son exactamente lo que no deberías desarrollar. La parte que merece la pena poseer es tu experiencia de marca e integraciones. Así que: compra la infraestructura a través de la API y desarrolla tu UX por encima.
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.
Ese es el replanteamiento honesto del clásico argumento de que "desarrollarlo cuesta una fortuna": compra la parte que es difícil y la misma para todos; desarrolla la parte que es tuya.
Cuándo desarrollar internamente tiene sentido de verdad
Para ser justos, a veces lo tiene:
- el DPP es tu producto principal (tú mismo vendes una plataforma de cumplimiento);
- tienes requisitos que ningún proveedor cumple (residencia de datos exótica, una pila on-premise a medida);
- escala extrema en la que la economía por unidad supera a cualquier SaaS.
Fuera de esos casos, desarrollar el trabajo pesado no diferenciador suele ser una distracción que te aparta de lanzar tu producto real antes de la fecha límite.
Preguntas frecuentes
¿No es una API solo otro tipo de dependencia (lock-in)? Menos que desarrollar el tuyo propio y quedar atado a tu propio código sin mantenimiento. GTIN/número de serie son estándares de GS1; los datos del pasaporte son JSON-LD exportable. Los estándares son portables por diseño.
¿Podemos empezar comprando y desarrollar más adelante si se nos queda pequeño? Sí, ese es el sentido de la vía híbrida. Empieza hoy con la API (cumple la fecha límite) e internaliza selectivamente más adelante si la economía lo exige.
¿Qué pasa concretamente con la presión de la fecha límite? Desarrollar lleva de 9 a 18 meses; los DPP de baterías son obligatorios en 2027. Si no has empezado a desarrollar, comprar es la única vía que cumple la fecha límite.
Fuentes
Empieza gratis y lanza hoy mismo un DPP conforme: app.qr3.app/sign-up
