The Hidden Cost of Building Product Experience Software In-House
Key Takeaways
- A credible v1 product experience platform requires 2–4 engineers for 12–18 months: £260,000–£375,000 in loaded UK engineering costs before a pixel goes live.
- Hidden costs — GS1 Digital Link compliance, multi-jurisdiction warranty logic, serialisation at scale, and security operations — routinely double the three-year total cost of ownership.
- The opportunity cost of diverting engineers from core product development is real but rarely appears in any budget line.
- In-house builds rarely make sense unless you have 5+ dedicated platform engineers and genuinely unique requirements no vendor can meet.
Every product leader has heard this one in the room: "We could build this ourselves."
It is not an unreasonable instinct. Your engineers are talented. Your internal team understands your product catalogue better than any vendor. And at first glance, the spec looks manageable — a QR code that lands on a web page, some warranty form logic, maybe a spare parts lookup. How hard could it be?
The answer: considerably harder, and considerably more expensive, than the whiteboard suggests. This article is not designed to scare you away from in-house development. Some companies genuinely should build. But most manufacturers — even large ones — are consistently surprised by where the real costs accumulate. So let us work through the numbers honestly.
The Visible Costs: What You Can Price Before You Start
What are the upfront engineering costs a manufacturer can realistically estimate before committing to an in-house product experience platform build? The surface-level estimate is almost always based on headcount, and that part is true: a product experience platform requires engineers. A credible v1 — QR landing pages, warranty registration, basic product data management, a CMS, multi-language support — requires between two and four developers working full time for twelve to eighteen months. That is not a pessimistic figure; it is what competent teams consistently report once scope is honestly defined (McKinsey Digital, "The True Cost of Custom Software," 2022). At fully-loaded UK engineering costs — salary, National Insurance, benefits, tooling, management overhead — mid-level engineers run £70,000–£100,000 per year. A team of three for fifteen months lands at roughly £260,000–£375,000 before a single pixel goes live. For US-based teams, substituting $120,000–$160,000 per engineer makes the calculation worse. These are the costs visible at the start of a build. They are also the optimistic numbers.
Developer Time and Loaded Cost
A credible v1 — QR landing pages, warranty registration, basic product data management, a CMS for content, multi-language support — requires somewhere between two and four developers working full time for twelve to eighteen months. That is not a pessimistic estimate; it is what competent teams consistently report once scope is honestly defined (McKinsey Digital, "The True Cost of Custom Software," 2022).
At fully-loaded UK engineering costs (salary, NI, benefits, tooling, management overhead), mid-level engineers run £70,000–£100,000 per year. A team of three for fifteen months lands at roughly £260,000–£375,000 before a single pixel goes live.
For a US-based team, substitute $120,000–$160,000 per engineer and the maths gets worse. For teams that rely on contractors to move faster, day rates compound the figure further.
This is the cost you can see. Most CFOs reviewing a build-vs-buy decision stop here. They should not.
The Hidden Costs: Where Projects Quietly Bleed
What are the costs that rarely appear in the initial build proposal but consistently cause in-house product experience projects to exceed budget? Four categories account for most of the overspend. First, GS1 Digital Link compliance: implementing the standard correctly requires studying the GS1 Digital Link specification at version 1.1, passing conformance testing, and building resolver logic that handles the full range of application identifiers — work that most software developers have never encountered and that GS1 membership and conformance fees compound. Second, EU Digital Product Passport readiness: ESPR data model requirements are still being finalised, meaning engineers must read evolving policy documents as a core engineering task. Third, multi-jurisdiction warranty logic: warranty law differs across UK, EU, US, and Australian markets in ways that affect database schema, UI flows, and legal obligations — not a feature to bolt on later. Fourth, security and uptime operations for a consumer-facing service: 99.9%+ availability, CDN strategy, OWASP compliance, penetration testing, and incident response are ongoing operational burdens, not one-time costs.
GS1 Compliance and Digital Link Certification
Modern product experience platforms do not run on simple QR codes. They run on GS1 Digital Link — the international standard that encodes GTIN, serial number, batch, expiry, and other structured data into a single scannable URI. Getting this right is not a configuration task; it is a standards compliance exercise (GS1 Digital Link Standard v1.1, GS1 Global Office, 2023).
Your in-house team will need to study and implement the GS1 Digital Link specification (currently at version 1.1), pass conformance testing, and ensure your resolver logic handles the full range of application identifiers correctly. GS1 membership and conformance testing are not free. More importantly, the engineers doing this work need time to become fluent in a standard that most software developers have never encountered.
Then there is the EU Digital Product Passport. The ESPR regulation is already setting data model requirements, and the first product categories come under mandatory DPP obligations starting in 2027. Building a DPP-compliant data model — one that will satisfy regulators in Germany, France, and the broader EU — requires understanding a regulatory framework that is still being finalised. Your internal team will be reading policy documents as a core engineering task.
Multi-Jurisdiction Warranty Logic
Warranty law is not uniform. The UK Consumer Rights Act, the EU Sale of Goods Directive, US Magnuson-Moss rules, Australian Consumer Law, and a dozen other jurisdictions each impose different minimum warranty periods, different obligations on repair versus replacement, and different rules about what constitutes a valid warranty registration.
If you sell into more than two or three markets — and most manufacturers do — you need jurisdiction-aware warranty logic baked into your data model from day one. This is not a feature you bolt on later. It affects database schema, UI flows, communications, and legal review. Getting it wrong in the EU carries real regulatory exposure.
QR Serialisation at Scale
There is a significant difference between generating QR codes and generating serialised QR codes at manufacturing scale. Every unit needs a unique, collision-resistant serial number. Those serials need to be provisioned before the product reaches the line, printed in batches, verified, and linked to your product identity database. Anti-counterfeiting and anti-diversion logic typically layers on top.
The integration between your platform and your label printing workflow — often a legacy system — is almost always underestimated. The data pipelines, the retry logic for print failures, the audit trail: none of it is trivial.
Security, Uptime, and Ongoing Operations
A product experience platform is a consumer-facing service. It gets scanned by customers at unboxing, in the field, and in service situations. Downtime is visible and reputational. You need 99.9%+ availability, a CDN strategy, OWASP-compliant security, regular penetration testing, and a response plan for incidents.
This is not a one-time cost. It is an ongoing operational burden that your team will carry indefinitely.
The Opportunity Cost: Your Engineers Are Not Free
What is the strategic cost of diverting engineering capacity to an in-house product experience build, beyond the direct financial outlay? The £300,000 build cost is significant in isolation. The opportunity cost is what makes it genuinely painful. Engineers building a product experience platform are not building the core product during that period — not shipping the features that drive revenue, reduce churn, or establish differentiation. In markets where product velocity determines category leadership, reallocating capable engineers to compliance-heavy infrastructure that could be purchased as a service is a strategic cost that never appears in any budget line, but is felt in every quarterly review where the core roadmap has slipped. For most manufacturers, product experience infrastructure is not a source of competitive advantage. It is a prerequisite. The strategic value comes from what the platform enables, not from having built it. Before committing to a build, working through the questions that surface real scope typically reveals complexity that was invisible at the whiteboard.
The two or three engineers building your product experience platform are not building your core product during that time. They are not shipping the features that drive revenue, reduce churn, or differentiate you from competitors. In a market where product velocity matters, reallocating your best engineers to infrastructure that could be bought off the shelf is a strategic cost that does not appear in any budget line.
Before committing to a build, most product and operations leaders benefit from working through the questions that surface real scope. The exercise typically reveals complexity that was not visible at the start.
The Maintenance Trap: v1 Is Not the End
Why is shipping v1 of an in-house product experience platform the beginning of the cost burden rather than the end? The most dangerous assumption in build-vs-buy analysis is that a successful launch closes the chapter. It does not. Regulatory requirements evolve: the EU DPP data model is updated as product category rules are finalised, GS1 Digital Link releases new versions, and warranty law changes require ongoing technical review. Each change demands the internal team assesses impact, updates the data model, regression tests, and redeploys. A platform vendor absorbs this as part of their business model. For an internal team, it is unplanned work competing against the product roadmap indefinitely. The v1.1-forever problem compounds this: after launch, requests accumulate for new product categories, DPP data gaps, retailer integrations, and regional content variants. Maintaining the platform typically requires a dedicated engineer — sometimes two — in perpetuity. That ongoing headcount cost almost never appears in the original business case but consistently dominates the three-year total cost of ownership.
The Regulatory Treadmill
Regulatory requirements evolve. The EU DPP data model is being updated as product category-specific rules are finalised. GS1 Digital Link releases new versions. Warranty law changes (the UK is currently mid-review on several consumer rights provisions). Each change requires your internal team to assess impact, update the data model, regression test, and redeploy.
A platform vendor absorbs this cost as part of their business model. For an internal team, it is unplanned work competing against your product roadmap indefinitely.
The v1.1 Forever Problem
v1 ships. Then a product manager requests support for a new product category with different warranty rules. Then the compliance team identifies a DPP gap. Then a retailer integration requires a new data export. Then a region wants localised content. Each of these is a new sprint, a new ticket, a new round of testing.
The team that built v1 does not shrink once the platform goes live. It typically needs a dedicated engineer — sometimes two — to maintain and evolve the platform in perpetuity. That ongoing cost rarely appears in the original business case.
The total cost of ownership over three years typically exceeds the initial build cost. A rigorous ROI framework for product identity infrastructure makes this calculation considerably more tractable.
Build vs. Buy: A Direct Comparison
How do in-house product experience builds compare to buying a specialist platform across the dimensions that determine total cost of ownership? The table below maps eight decision dimensions — upfront cost, time to first value, compliance handling, warranty logic, maintenance burden, regulatory update responsibility, scalability, and opportunity cost — against both options. The comparison is deliberately direct: for the majority of manufacturers, the case for building resolves to a few specific conditions — a dedicated platform engineering team of five or more, genuinely unique requirements that no vendor addresses, and a regulatory context unusual enough to justify the ongoing maintenance burden. Outside those conditions, the mathematics consistently favour buying. Specialist platforms spread compliance and maintenance costs across many manufacturers rather than requiring each to absorb them independently, which is a structurally more efficient model at scale.
| Dimension | In-House Build | Platform (Buy) |
|---|---|---|
| Upfront cost | £200,000–£400,000+ | Subscription or per-unit licensing |
| Time to first value | 12–18 months | Weeks |
| GS1 / DPP compliance | Your team's problem | Included and maintained |
| Multi-jurisdiction warranty | Custom build required | Configured, not coded |
| Ongoing maintenance | Dedicated headcount | Vendor absorbs |
| Regulatory updates | Unplanned work | Vendor obligation |
| Scalability | You own the infrastructure | Vendor SLA |
| Opportunity cost | High — diverts core engineers | Minimal |
Competitors and Alternatives Worth Knowing
Which platforms should manufacturers evaluate when assessing the buy side of the build-vs-buy decision for product experience infrastructure? The market includes several platforms with different centres of gravity, and choosing between them requires understanding which was built for your specific product category, regulatory environment, and post-purchase use cases. Registria has a long track record in consumer goods warranty and post-purchase registration, with strong CRM integration but a narrower focus on registration rather than full lifecycle management. Brij takes a QR-first approach oriented toward CPG and fashion, with consumer registration, loyalty, and content capabilities. Layerise offers product experience management with a no-code builder targeting mid-market manufacturers, focused on guided setup, documentation, and after-sales engagement. The right question when evaluating any of these is not which platform is abstractly best, but which handles the specific combination of GS1 serialisation, DPP data readiness, and multi-jurisdiction warranty logic that your product categories require.
Registria is a warranty and consumer engagement platform with a long track record in the consumer goods sector. It focuses primarily on post-purchase registration and consumer data capture, with strong CRM integration capabilities.
Brij takes a QR-first approach, enabling brands to link product packaging to digital experiences including registration, loyalty, and content. It is consumer-brand oriented and particularly strong in CPG and fashion categories.
Layerise offers product experience management with a focus on guided setup, product documentation, and after-sales engagement. It serves mid-market manufacturers with a no-code builder for product flows.
Each platform has a different centre of gravity. The right question is not which vendor is best in the abstract, but which one was built for your product category, regulatory environment, and post-purchase use cases — including GS1 serialisation, DPP readiness, and warranty jurisdiction logic.
When Building In-House Actually Makes Sense
Under what conditions does building a product experience platform in-house represent the genuinely correct decision rather than a costly instinct? Intellectual honesty demands acknowledging that some companies should build. If you have a dedicated platform engineering team of five or more engineers, genuinely unique requirements — proprietary hardware integrations, unusual data models, or regulatory environments no existing vendor has addressed — an internal build may be the right answer. Technology companies for whom software platforms are a core competency may also find that buying standard infrastructure feels like conceding competitive advantage. These are the legitimate cases. For the typical manufacturer — even a sophisticated one with a capable engineering team — none of these conditions usually apply. The requirement is not a unique technical problem; it is a compliance-heavy, multi-jurisdiction infrastructure project. That is precisely what specialist platforms are designed to absorb at scale, and precisely the kind of work that is inefficient when solved independently by every manufacturer that needs it.
If you have fifty or more engineers and a dedicated platform team, the calculus changes. If your product experience requirements are genuinely unique — unusual data models, proprietary hardware integrations, regulatory environments that no vendor has solved — then an internal build may be the right answer. If you are a technology company for whom software platforms are a core competency, buying standard infrastructure may feel like giving away competitive advantage.
But for the typical manufacturer — even a sophisticated one with a competent engineering team — none of these conditions usually apply. The requirement is not a unique technical problem; it is a compliance-heavy, operationally intensive, multi-jurisdiction infrastructure project. That is precisely what specialist platforms exist to absorb.
Assessing your actual DPP readiness before committing to a build or buy decision is a useful starting point. The gaps that surface often reframe the conversation.
The Honest Conclusion
What is the honest summary of the build-vs-buy decision for product experience infrastructure, for manufacturers approaching this choice in 2025 and 2026? The "we could build this ourselves" instinct is not wrong — it is incomplete. The visible build cost is real: £200,000–£400,000 for a credible v1, plus ongoing maintenance headcount. The hidden costs — GS1 Digital Link compliance, EU Digital Product Passport data modelling, multi-jurisdiction warranty logic, security operations, and the regulatory treadmill — typically double the three-year total cost of ownership. The opportunity cost of diverting capable engineers from core product development is harder to quantify but consistently underestimated. Specialist platforms like BrandedMark exist because these problems are most efficiently solved once and shared across many manufacturers. For the majority of manufacturers — including large, sophisticated ones — the case for buying is not about capability. It is about where engineering capacity creates the most value. The question is not whether you can build it. It is whether you should.
The visible cost is real: £200,000–£400,000 for a credible build, plus ongoing headcount. The hidden costs — compliance, serialisation at scale, multi-jurisdiction logic, security operations, and the regulatory treadmill — often double that figure over three years. And the opportunity cost of diverting your engineers from your core product is harder to quantify but very real.
Platforms like BrandedMark exist because these problems are solved once and shared across many manufacturers — which is a fundamentally more efficient model than every brand solving them independently. If your organisation fits the profile above, the question is not whether you can build it. The question is whether you should.
Frequently Asked Questions
The questions below address the practical sizing questions that arise when manufacturers are working through a build-vs-buy decision for product experience infrastructure.
How long does it realistically take to build a basic product experience platform in-house?
A minimal viable implementation — QR landing pages, warranty registration, basic product content management — typically takes a team of two to three engineers between twelve and eighteen months to reach production-ready quality. That estimate assumes no significant delays on compliance work (GS1, DPP), no integration complexity with existing ERP or label printing systems, and a well-defined spec from day one. Most real projects slip on at least one of those assumptions.
What are the biggest underestimated costs in an in-house product experience build?
The three costs that consistently surprise teams are: GS1 Digital Link compliance and resolver implementation, multi-jurisdiction warranty logic (especially for EU and UK markets), and the ongoing maintenance burden once the EU Digital Product Passport regulation requires data model updates. None of these are one-time costs — they require sustained engineering attention for as long as the platform is live.
At what company size or engineering scale does building in-house start to make sense?
As a rough guide, in-house builds start to make economic sense when you have a dedicated platform engineering team of five or more engineers, clear proprietary requirements that no vendor can meet, and a regulatory or product catalogue environment that is genuinely unusual. For the majority of manufacturers — including large ones with capable engineering teams — the build-vs-buy maths typically favours buying, because the ongoing compliance and maintenance burden is a poor use of scarce engineering capacity.