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
The surface-level estimate is almost always based on headcount. A product experience platform needs engineers. That part is true.
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
The visible headcount cost is the optimistic number. The following costs are the ones that rarely make it onto the initial proposal.
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
The £300,000 build cost is bad enough in isolation. The opportunity cost is what makes it genuinely painful.
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
The most dangerous assumption in build-vs-buy analysis is that shipping v1 closes the chapter.
It does not.
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
| 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
If you are evaluating the market, a few platforms are worth understanding.
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
Intellectual honesty demands acknowledging this: some companies should build.
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
The "we could build this ourselves" instinct is not wrong. It is just incomplete.
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
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.