Build or buy a DPP: which is right for textile SMBs

The first DPP question every textile founder asks themselves, somewhere in the weeks after they finally read the ESPR articles, is whether to build their own passport system or buy one. Engineering teams favor build. Operations favors buy. Procurement wants a TCO model that compares them honestly. Most of those models do not.

This post is a frank look at when build makes sense for a textile SMB, when buy does, and what a hybrid is doing in the wild. It is written by a DPP vendor, so the bias should be obvious. The numbers are real, and they are not flattering to either path in all cases.

The question hiding inside the question

A Digital Product Passport is not one piece of software. It is at least six, loosely coupled.

1. A data model that matches what ESPR and the textile delegated act will require: fibre composition, country of origin per processing stage, durability, care, recycling pathway, supplier identifiers.
2. A supplier data-collection workflow that gets that data out of tier-1 and tier-2 supplier inboxes and into structured fields.
3. A resolver that turns a GS1 Digital Link QR scan into a passport URL, served from a stable jurisdiction, in multiple languages, in under two seconds.
4. A consumer-facing renderer that displays the passport content cleanly on any phone, on any network speed, without an app install.
5. A tamper-evident audit layer that signs every change to a published passport so an auditor can verify the chain without trusting you.
6. An integration layer that connects to Shopify, your ERP, your PIM, or your CAD system so SKUs do not have to be re-keyed.

Each of those is a non-trivial engineering project on its own. Together, they are roughly the same shape as a small SaaS company. That framing is the honest one.

What build actually costs

The temptation when an engineering team scopes this is to count only the build cost. Six engineers for six months, ship a v1, done. We have seen those plans. We have also seen the eighteen-month overrun, the consumer QR that does not work in Chrome's camera-app fallback, the audit log that turns out not to be cryptographically chained.

A realistic v1 build for a textile SMB looks like:

• 3 to 4 engineers (one platform, one front-end, one DevOps, ideally a half-time security engineer for the credentials layer)
• 9 to 14 months to a usable v1 that handles real supplier data and a working consumer scan
• £140k to £260k in direct salary cost
• £30k to £60k per year ongoing for maintenance, regulatory updates, security patches, and supplier portal evolution

Those are the headline numbers. They do not include the parts that catch build teams out.

Standards drift. GS1 Digital Link was at version 1.4 in 2024. Version 1.5 in mid-2025. CEN/CENELEC TC 442 is publishing new technical specifications quarterly. The textile delegated act will land somewhere between late 2026 and Q2 2027, with practical adoption deadlines in mid to late 2028. Each change is a non-zero engineering cost for whoever owns the platform. A vendor amortizes that work across all its customers; a builder pays it alone.

Cryptographic key management. A tamper-evident audit trail in the form ESPR Article 7 expects is a W3C Verifiable Credentials chain with proper key rotation, key escrow, and signature verification by independent parties. If you have not built that before, the security review is going to find things, and your founders are going to have personal liability questions about how the keys are managed.

Consumer-side performance. A QR scan on a garment in a Berlin store must load in under two seconds on a 4G connection. The same scan on a garment exported to São Paulo must load in under three seconds on a stretched mobile network. That is a CDN problem, a caching problem, a font-loading problem, and a service-worker problem. None of those are problems most textile brand engineering teams have solved before.

Supplier portal UX. This is the biggest hidden cost. The DPP content is mostly supplier-generated, and your tier-2 supplier is not going to learn a new SaaS for you. The portal has to support spreadsheet upload, email-based back-and-forth, and a graceful degradation to phone-camera capture of certificates. Each of those is a feature your team will discover the hard way after the supplier ignores the first three onboarding emails.

The honest v1 build estimate, including the things teams forget at scoping time, is closer to £250k to £400k through year two, with £50k to £80k per year ongoing thereafter.

What buy actually costs

We covered the procurement side in detail in choosing a DPP platform: 12 questions to ask, so the short version here.

For a textile SMB with 200 to 2,000 SKUs, expect £8,000 to £40,000 per year all-in for a serious vendor. Cheaper than that and you are missing the supplier collection workflow, the audit chain, or both. More expensive than that and you are paying for an enterprise feature set you will not use.

Onboarding cost is the line item that gets understated. Migrating supplier data, building the integration to your existing systems, and training your operations team typically lands at £8k to £20k of professional services on top of the platform license. Expect six to twelve weeks before the first SKU has a fully populated passport in production.

Three-year total cost of ownership for buy, on representative numbers:

• Year 1: £18k license + £14k onboarding = £32k
• Year 2: £20k license = £20k
• Year 3: £22k license (modest escalation) = £22k
• Three-year total: £74k

Three-year total cost of ownership for build, on the same scope, with the honest numbers:

• Year 1: £180k build + £40k maintenance = £220k
• Year 2: £60k maintenance and ongoing dev = £60k
• Year 3: £60k maintenance and the textile delegated act response = £60k
• Three-year total: £340k

The build option costs roughly 4.5 times what buy costs over three years for a textile SMB. Some teams still take it. Three reasons usually surface.

When build is the right call

We have only met a handful of textile SMBs where building was the right call. The pattern looks like this.

You are already a software company that happens to also make textiles. A small handful of brands employ more engineers than they do designers. Existing infrastructure, existing engineering culture, existing approach to security review. The marginal cost of building a DPP module is genuinely lower than the SaaS subscription. We can think of three brands in Europe that fit this and they all built. We do not pitch them.

You have a workflow no vendor matches and the workflow is strategic. Some brands have an unusual supplier model (vertically integrated dyeing, in-house spinning, on-loom traceability tags) that turns the data collection problem inside out. If the workflow is genuinely strategic, it might be worth building around. Test that with a small workflow exercise before committing six engineers.

You want to sell the platform to other brands. A small but interesting move some SMBs have made is to build the DPP for themselves, polish it, then offer it as SaaS to brands in adjacent categories. This is the same move that produced Shopify (out of Snowdevil) and Basecamp (out of 37signals' internal project management). It is rare, and most attempts fail because running a SaaS is a different business than making clothes. But the move exists.

If none of those three apply, build is almost certainly the wrong call.

The hybrid that actually works

In practice, the smartest brands run a hybrid. They buy the platform layer (resolver, consumer renderer, audit chain, base data model) and they build their own thin layer on top of the integration and supplier-data side.

What this looks like in production:

• The vendor handles the GS1 Digital Link resolver, the QR rendering, the multilingual consumer page, the audit chain, and the data schema updates when the delegated act lands.
• The brand builds a small custom adapter that pulls SKU data from their PIM, runs whatever proprietary transformation matters to them (e.g. mapping their internal fibre classification to ESPR's), and pushes the result to the vendor via API.
• The brand also builds (or commissions) a custom supplier-side workflow if their supplier base is unusual. For many, the vendor's portal is fine and this step gets skipped.

The hybrid costs roughly £30k to £60k in first-year build cost for the custom adapter, on top of the platform license. It buys the brand a defensible position: vendor handles the parts that change with the regulation, brand handles the parts that change with its own product catalog.

This is what we see Filovera customers settle into after the first quarter. It is what we recommend.

How to decide in twelve weeks

If your team is genuinely weighing build vs buy, the cheapest way to de-risk the decision is a structured twelve-week trial.

Weeks 1 to 4: scope the supplier-data problem. Pick fifty SKUs across three suppliers. Define the data fields you need to collect. Email the suppliers. Track how long it takes to get usable data back, in what format, and what gets rejected. This exercise alone will tell you whether you have a "fill in a form" problem (vendor can handle it) or a "renegotiate every supplier contract" problem (vendor cannot help you with the latter, but neither can a custom build).

Weeks 5 to 8: stand up two vendor trials in parallel. Most reputable DPP vendors offer a 30 to 60-day trial. Load your fifty SKUs into both. Measure: time to first passport, supplier response rate via the portal, audit log usability, scan-to-render time on real consumer phones in three geographies.

Weeks 9 to 12: cost the build alternative honestly. Have your engineering team scope a v1 that matches what the vendor trial gave you. Insist on a date-stamped scope: the v1 must include the resolver, the consumer renderer, the audit chain, the supplier portal, and integration to your existing PIM. Compare the headline build cost to the three-year vendor TCO. If the build cost is more than 1.5 times the buy cost, the decision is made.

Twelve weeks of focused work. Maybe £15k of internal time, no platform commitment, and a real answer.

What we tell prospects

We tell most prospects to buy, including ones who go on to buy from someone else. The reason is simple: the engineering work behind a serious DPP platform is larger than most textile brands realize at scoping time, the standards layer keeps moving, and the supplier-data problem is largely unmoved by whether the platform is built or bought.

We tell the handful where build genuinely makes sense to build, and we wish them well. Most of that handful end up subscribing to Filovera for the resolver layer two years in anyway, because that part of the work turns out to be heavier than they planned.

If you want to walk through the cost model for your specific SKU count and supplier base, book a call. If you want to look at the platform side first, features is the place to start. If your engineering team is leaning build, please bring this post to the scoping meeting. The worst version of the DPP project is the one where engineering is six months in before procurement notices the SaaS option costs a quarter as much.

Related reading

• Choosing a DPP platform: 12 questions to ask once you have decided to buy
• GS1 Digital Link explained for textile DPP for what the resolver layer actually looks like under either approach
• ESPR for textile SMBs: what 2028 actually requires for the regulatory backdrop shaping the cost model

Frequently asked questions

Should a small textile brand build its own Digital Product Passport platform?

In almost all cases, no. The engineering scope is larger than most brands realize at the start. A realistic build is £140k to £260k in first-year salary cost, plus £30k to £60k per year ongoing for maintenance and regulatory updates. The same three-year period costs £60k to £90k all-in with a serious DPP vendor. Building only makes sense for brands that already operate as software companies, brands with a genuinely strategic workflow no vendor matches, or brands planning to commercialize the platform as SaaS to other brands.

How long does it take to build a DPP platform?

A realistic v1 takes 9 to 14 months with 3 to 4 engineers. That includes the data model, supplier portal, GS1 Digital Link resolver, consumer renderer, audit chain, and basic ERP integration. Brands that scope the project at 6 months tend to discover the missing pieces (cryptographic key management, multilingual rendering, mobile performance, supplier UX) after the v1 lands and the first real audit fails.

What is the three-year cost difference between build and buy?

For a textile SMB with 200 to 2,000 SKUs, expect approximately £74k to buy over three years and approximately £340k to build over the same period. Build runs roughly 4.5 times more expensive. The gap closes only if the brand has unusual existing infrastructure or plans to commercialize the platform.

What is a hybrid DPP approach?

A hybrid uses a DPP vendor for the platform layer (resolver, consumer renderer, audit chain, data schema) and builds a thin custom adapter on top for the brand's specific integration and supplier-data needs. Typical first- year build cost on top of a platform license: £30k to £60k. It gives the brand a defensible split where the vendor handles parts that change with the regulation and the brand handles parts that change with its own catalog. Most Filovera customers settle into this pattern after the first quarter.

Can I switch from buy to build later?

Yes, if the vendor takes data portability seriously. Before signing, confirm the export contract includes the audit log, that QR codes on physical garments can be re-pointed to a new resolver without reprinting, and that there is no exit fee. Vendors who object to those clauses are vendors you should not start with.

What happens if the textile delegated act changes my DPP requirements?

The textile delegated act will publish somewhere between late 2026 and Q2 2027. From that day, every DPP platform has to update its data schema, field definitions, and verification rules. A vendor absorbs that work across its customer base; a builder absorbs it alone. Brands that are building should budget at least one engineer-quarter for the delegated act response in 2027, on top of normal maintenance.

---

Disclaimer. Filovera is software, not legal or compliance advice. The exact text of the textile delegated act has not been published as of June 2026, and cost estimates in this post reflect current vendor pricing and engineering market rates in mid-2026. Brands with high-value product lines or complex supplier networks should engage qualified advisors before making a build-vs-buy decision based on this post alone.