The Hidden Cost of Building Product Experience Software In-House
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 many manufacturers, even large ones, are surprised by where the real costs accumulate. So let us work through the trade-offs 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) takes a meaningful team of developers working full time for many months. That is not a pessimistic estimate; it reflects what scope honestly defined tends to demand.
The fully-loaded cost of an engineer (salary, employer taxes, benefits, tooling, management overhead) is well above their headline salary. Multiply that by a multi-person team across many months, and the build lands at a substantial six-figure sum before a single pixel goes live. 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. For a financial assessment of product identity infrastructure, the CFO's case for product identity ROI provides a framework for quantifying these hidden 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 standard that encodes structured data such as GTIN, serial number, batch, and expiry into a single scannable URI. Getting this right is not a configuration task; it is a standards compliance exercise. The specification is published by GS1.
Your in-house team will need to study and implement the GS1 Digital Link specification, work through conformance, 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 many software developers have never encountered.
Then there is the EU Digital Product Passport, introduced under the Ecodesign for Sustainable Products Regulation (ESPR). The framework sets data model requirements and rolls out obligations by product category over time, as described by the European Commission. Building a DPP-aligned data model, one that will satisfy regulators across EU markets, requires understanding a regulatory framework that is still being detailed. Your internal team will be reading policy documents as a core engineering task.
Multi-Jurisdiction Warranty Logic
Consumer protection and warranty rules are not uniform. The UK Consumer Rights Act 2015 and equivalent regimes in the EU, the US, Australia, and other markets each impose their own obligations on repair versus replacement and on what protections a buyer is owed. The details differ by jurisdiction, and they change over time.
If you sell into more than two or three markets, and many 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 regulated markets can carry real 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 frequently 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 high availability, a CDN strategy, security hardening aligned to recognised practices such as those from OWASP, 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 build cost is bad enough in isolation. The opportunity cost is what makes it genuinely painful.
The 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 often 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 detailed as product category-specific rules are finalised. Standards bodies release new versions. Consumer protection law changes. 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 dedicated engineering to maintain and evolve the platform in perpetuity. That ongoing cost rarely appears in the original business case, and over several years the total cost of ownership can run well past the initial build. 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 | Substantial six-figure build | Subscription or per-unit licensing |
| Time to first value | Many 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 |
How to Evaluate the Market
If you are evaluating platforms rather than building, the right question is not which vendor is best in the abstract. It is which one was built for your product category, your regulatory environment, and your post-purchase use cases.
Useful evaluation criteria include: native support for GS1 serialisation, readiness for the EU Digital Product Passport, the depth of multi-jurisdiction warranty handling, integration with your existing ERP and label-printing systems, and how the vendor absorbs ongoing regulatory change. A platform that scores well on these axes removes exactly the hidden costs that make an internal build so expensive.
When Building In-House Actually Makes Sense
Intellectual honesty demands acknowledging this: some companies should build.
If you have a large engineering organisation 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 many manufacturers, even sophisticated ones with capable engineering teams, none of these conditions 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. A structured approach to digital product identity implementation helps evaluate these trade-offs objectively.
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: a substantial six-figure build, plus ongoing headcount. The hidden costs, including compliance, serialisation at scale, multi-jurisdiction logic, security operations, and the regulatory treadmill, can outweigh the visible figure over time. 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) takes a meaningful engineering team many months to reach production-ready quality. That assumes no significant delays on compliance work such as GS1 and DPP, no integration complexity with existing ERP or label printing systems, and a well-defined spec from day one. Many real projects slip on at least one of those assumptions.
What are the biggest underestimated costs in an in-house product experience build?
The costs that consistently surprise teams are: GS1 Digital Link compliance and resolver implementation, multi-jurisdiction warranty logic, and the ongoing maintenance burden once the EU Digital Product Passport regime 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 sense when you have a dedicated platform engineering team with capacity to spare, clear proprietary requirements that no vendor can meet, and a regulatory or product catalogue environment that is genuinely unusual. For many manufacturers, including large ones with capable teams, the build-vs-buy decision tends to favour buying, because the ongoing compliance and maintenance burden is a poor use of scarce engineering capacity.
BrandedMark is the Product Operating System for manufacturers of physical goods: serialised product identity, connected experiences, warranty registration, and Digital Product Passport readiness in one platform. See how it works at brandedmark.com.