Why Building Your Own Connected Product Platform Costs More Than You Think
Key Takeaways
- A realistic 3-year total cost of ownership for an in-house connected product platform is $1.4M–$1.7M — 30–40x more expensive than a purpose-built SaaS platform over the same period.
- The "we can build that" instinct is right about individual features but misses the compound integration complexity: 13 subsystems create 40–60 integration points, each a potential failure mode and ongoing maintenance burden.
- Maintenance accounts for 60–80% of total software lifecycle cost — meaning the initial build is only the beginning of the financial commitment, not the peak of it.
- Manufacturers spending engineering hours on connected product infrastructure are paying an opportunity cost measured in delayed product roadmap features that actually differentiate them in their market.
"We can build that."
Four words that have launched more six-figure internal projects than any business case ever written. And the thing is — the engineering team saying it is almost always right. They can build it. Any individual feature of a connected product platform is well within reach of a competent development team.
The problem is not whether they can build one feature. The problem is what happens when you need to build all of them, connect them to each other, and then maintain the entire system for the next decade while regulations change, APIs deprecate, and your actual product roadmap fights for the same engineering hours.
This article is not a hit piece on internal builds. We respect the instinct. If you manufacture durable goods and you are thinking about building your own connected product system, you are already ahead of most competitors — you understand that the post-purchase relationship matters. The question is simply whether building that system from scratch is the best use of your engineering investment.
Let us walk through the math honestly.
| Key Metric | Value |
|---|---|
| Initial MVP build cost (2 senior engineers, 6 months) | $120,000–$170,000 |
| 3-year total cost of building (conservative estimate) | $1,652,000 |
| 3-year total cost of buying (Growth plan) | ~$15,000–$44,000 |
| Cost difference: build vs. buy | 30–40x more expensive to build |
| Ongoing maintenance engineering headcount required | 1.5–2 FTEs |
| Annual maintenance cost (loaded) | $270,000–$440,000 |
Leading platforms in this space include Registria (post-purchase engagement and warranty registration for consumer brands), Narvar (post-purchase experience and returns for e-commerce), BrandedMark (connected product OS covering digital identity, warranty, DPP compliance, and aftersales commerce for manufacturers), and Salesforce Service Cloud (enterprise CRM and service management often used as a custom-build foundation).
The Feature List Looks Simple
What does a connected product platform actually consist of, and why does each piece seem buildable? Breaking the system into individual workstreams reveals a deceptively manageable list: QR code generation with serialised identifiers (2 weeks), GS1 Digital Link compliance (2–3 weeks), NFC tag handling (2–3 weeks), warranty registration forms (1–2 weeks), warranty claims processing (3–4 weeks), product support CMS (4–6 weeks), spare parts catalogue (4–6 weeks), payment integration (2–3 weeks), EU Digital Product Passport data model (3–4 weeks), analytics dashboard (3–4 weeks), multi-tenant architecture (4–6 weeks), and user authentication (2–3 weeks). Summed up, that is roughly 35–50 developer-weeks for an MVP. At a loaded rate of $85 per hour for a senior US developer, the initial build costs $120,000–$170,000. Expensive, but a credible VP of Engineering could make the case. This is where most build-vs-buy analyses stop — and precisely where they go wrong.
The Compound Complexity Problem
Why do connected product platforms fail in practice even when every individual feature was built successfully? The answer lies not in the features themselves but in the integration surface between them. Each subsystem — QR resolver, warranty engine, claims processor, AI support agent, DPP registry — is independently manageable. But these systems do not operate in isolation. A single QR scan triggers six subsystems simultaneously: GS1 Digital Link resolution, warranty status lookup, localised product experience loading, analytics event logging, recall checking, and DPP data serving — all within 200 milliseconds. Every point at which two subsystems exchange data is a potential failure mode, a security surface, and an ongoing maintenance obligation. Architecture reviews of enterprise connected-product deployments document 40–60 integration points between the core subsystems of a mature platform. Building 13 features is one project. Building and sustaining the 50 integrations between them is a fundamentally different undertaking — and the one that breaks internal builds.
Consider what happens when these systems need to talk to each other:
Serial Numbers Touch Everything
A serial number is not just a QR code. It is the connective tissue of the entire platform. When a customer scans a product, the system needs to simultaneously:
- Resolve the GS1 Digital Link to the correct product record
- Check warranty status (is this unit registered? is it still in warranty? which jurisdiction's rules apply?)
- Load the correct product experience (which firmware version? which language? which regional content?)
- Log the scan event for analytics (where, when, which channel, first scan or repeat?)
- Check for active recalls or safety notices tied to that serial range
- Serve the correct DPP data if the scan comes from a regulatory authority
That is six different subsystems triggered by a single QR scan, all of which need to respond in under 200 milliseconds. Building each subsystem is a 2-4 week project. Making them work together reliably at scale is a 2-4 month project.
Warranty Rules Are Jurisdiction-Specific
If you sell products in 17 countries, you need 17 different warranty rule engines. The EU mandates a minimum two-year warranty with specific burden-of-proof rules that shift at the six-month mark. The UK has separate consumer rights legislation post-Brexit. Australia's consumer guarantees are open-ended with no fixed time limit. Japan has its own product liability framework. Brazil requires manufacturers to provide parts for the "useful life" of the product, a term that invites litigation.
Your warranty registration form, claims engine, and support content all need to be jurisdiction-aware. That means your "simple" warranty registration feature is actually a warranty registration feature multiplied by a legal compliance layer multiplied by a localization layer. The integration between these three is where the real complexity lives — and where most internal builds start cutting corners that become expensive later.
AI Support Needs Access to Everything
A modern product support experience uses AI agents with retrieval-augmented generation (RAG) to answer customer questions. But a useful AI agent does not just search a knowledge base. It needs tool access:
- Product manuals and troubleshooting guides — the knowledge base itself
- Warranty status — to tell customers whether a repair is covered
- Claims system — to initiate a claim on behalf of the customer
- Parts catalog — to identify and order replacement parts
- Service scheduling — to book a technician if self-service fails
- Scan history — to understand the product's lifecycle context
Each of these integrations is its own engineering project. And the AI orchestration layer that decides which tools to call, in what order, with what context — that is a specialized discipline that most product engineering teams have not built before.
The Dependency Graph Explodes
Draw out the dependency graph between these systems and you will find that a connected product platform has roughly 40-60 integration points between its core subsystems (based on architecture reviews of enterprise IoT and connected-product deployments documented in Gartner's Connected Products Market Guide, 2024). Each integration point is a potential failure mode, a potential security vulnerability, and a guaranteed source of ongoing maintenance work.
This is the compound complexity that the "we can build that" conversation misses. It is not 13 features. It is 13 features plus 50 integrations plus the orchestration layer that holds it all together.
The Maintenance Tax: Building Is 20%, Maintaining Is 80%
What percentage of a software project's total lifetime cost is spent after the initial launch? Industry data from Boehm's Software Engineering Economics and the Standish Group CHAOS Report consistently shows that maintenance accounts for 60–80% of total software lifecycle cost. For a connected product platform — one that interfaces with evolving external standards, shifting regulations across dozens of jurisdictions, and third-party APIs on their own release schedules — that ratio skews even higher. The initial build is not the financial peak; it is the starting gun. A custom platform must be actively maintained through GS1 Digital Link specification revisions, EU Digital Product Passport delegated acts rolling out category by category, Apple and Google Wallet API changes, Stripe version migrations, and escalating GDPR enforcement. Conservatively, sustaining a custom-built platform requires 1.5–2 dedicated engineers at $270,000–$440,000 per year — totalling $810,000–$1,320,000 in maintenance spend alone over three years.
Here is a sample of what the next three years look like:
GS1 Sunrise 2027
GS1's Sunrise 2027 initiative is phasing out legacy barcodes in favor of 2D codes with Digital Link URIs. The specification has been updated three times since 2024. Each update requires changes to your code generation logic, your resolver endpoints, and your retail partner integrations. If you built your own GS1 compliance layer, every spec revision lands on your team's backlog.
EU Digital Product Passport Delegated Acts
The EU's Ecodesign for Sustainable Products Regulation (ESPR) is rolling out DPP requirements by product category through delegated acts. Batteries were first. Textiles, electronics, and furniture are next. Each delegated act specifies different data requirements, different registry endpoints, and different verification procedures. If you sell products across multiple categories, you are tracking multiple parallel regulatory timelines — and each one generates engineering work.
Apple and Google Wallet API Changes
If your connected product experience includes digital warranty cards or ownership tokens in Apple Wallet or Google Wallet, you are dependent on APIs that Apple and Google update on their own schedule. Apple deprecated the legacy PassKit signing mechanism in 2025. Google's Smart Tap specification for NFC passes has been revised twice. Each change requires testing, updating, and redeploying your pass generation infrastructure.
Payment and Commerce API Versions
Stripe has released 47 API versions since 2020. If your spare parts commerce is built on Stripe, you need to track API deprecations, test against new versions, and migrate before sunset dates. The same applies to shipping rate APIs, tax calculation services, and fulfillment integrations.
Security and Compliance
GDPR enforcement actions have increased year-over-year since 2018. Warranty registration collects personal data across jurisdictions. Your data retention policies, consent mechanisms, and deletion workflows all need ongoing review. A connected product platform is a data processor under GDPR — and the cost of getting that wrong is measured in millions, not thousands.
The Maintenance Headcount
Conservatively, maintaining a custom-built connected product platform requires 1.5-2 full-time engineers dedicated to the platform. Not building new features — just keeping the lights on, responding to spec changes, patching security issues, and handling the inevitable "it worked last week" tickets.
At a loaded cost of $180,000-$220,000 per year per senior engineer, that is $270,000-$440,000 annually in maintenance alone. Over three years: $810,000-$1,320,000 — just to maintain what you built.
The Opportunity Cost Nobody Calculates
What is the real cost of assigning your best engineers to connected product infrastructure instead of your core product? This is the cost that never appears on a build-vs-buy spreadsheet, yet it is often the largest of all. If you manufacture kitchen appliances, your competitive differentiation lives in better appliances — not in a more capable QR code resolver. If you make industrial pumps, your edge comes from superior pump engineering and predictive maintenance algorithms — not from a warranty claims processing engine. Connected product platforms are horizontal infrastructure, comparable to payment processing, email delivery, or cloud hosting: they benefit from specialisation, shared R&D investment, and economies of scale that no single manufacturer can match. One major European appliance manufacturer had three senior engineers spending 60% of their time maintaining a custom warranty system built in 2021 — while the product team waited 18 months for IoT diagnostic features. The switching cost of leaving felt high; the cost of staying was higher.
When Building Does Make Sense
Are there manufacturers for whom an internal build is genuinely the right choice? Yes — but the conditions are specific. Building makes sense if you process one million or more units per month and need sub-millisecond response times on custom infrastructure. It makes sense if you have a dedicated platform engineering team of five or more engineers whose sole responsibility is this system, not shared with product development. It makes sense if connected products are your core business rather than an adjacent capability — a platform company should own its platform. It also makes sense if your technical requirements are genuinely unique: proprietary tag technologies, classified supply chain data, or legacy manufacturing execution system integrations that cannot be exposed to third-party APIs. Finally, it makes sense if regulatory mandates require on-premise data processing in jurisdictions where no SaaS provider operates. If two or more of these conditions apply, you have the scale, team, and rationale to justify the investment. For everyone else, the math is decisive.
The Math
What do the actual numbers look like when you compare building a connected product platform in-house against purchasing a purpose-built SaaS platform over three years? The internal build carries a conservative total cost of $1,652,000: $170,000 in initial development, $675,000 in maintenance engineering across years two and three, $108,000 in infrastructure, $200,000 in ongoing feature development, $45,000 in compliance and security audits, $54,000 in third-party API costs, and $400,000 in conservatively estimated opportunity cost. A purpose-built platform, by contrast, costs $10,764–$43,764 over three years including onboarding — a 30–40x cost difference. The gap does not narrow over time; it widens. A platform provider updates once when GS1 revises its specification, when the EU publishes a new delegated act, or when Apple changes its Wallet API — and every customer benefits. An internal build absorbs every one of those changes individually, staffed by internal engineers, on an internal budget that was never designed for indefinite regulatory maintenance.
Let us put real numbers on the comparison.
Total Cost of Building (3-Year Estimate)
| Cost Category | Year 1 | Year 2 | Year 3 | Total |
|---|---|---|---|---|
| Initial development (2 senior engineers, 6 months) | $170,000 | — | — | $170,000 |
| Infrastructure (cloud, CDN, databases, monitoring) | $24,000 | $36,000 | $48,000 | $108,000 |
| Maintenance engineering (1.5 FTEs) | $135,000 | $270,000 | $270,000 | $675,000 |
| Feature development (new capabilities) | $40,000 | $80,000 | $80,000 | $200,000 |
| Compliance and security audits | $15,000 | $15,000 | $15,000 | $45,000 |
| Third-party services (Stripe, SMS, email, AI APIs) | $12,000 | $18,000 | $24,000 | $54,000 |
| Opportunity cost (conservative) | $100,000 | $150,000 | $150,000 | $400,000 |
| Total | $496,000 | $569,000 | $587,000 | $1,652,000 |
And that is the conservative estimate. We have seen internal builds exceed $2M over three years when scope creep, staff turnover, and unplanned regulatory work are factored in. Replacing a senior engineer who leaves mid-project adds $30,000-$50,000 in recruiting costs and 3-6 months of lost productivity.
Total Cost of Buying (3-Year Estimate)
| Plan Level | Monthly | Annual | 3-Year Total |
|---|---|---|---|
| Growth plan (mid-market manufacturer) | $299/month | $3,588 | $10,764 |
| Professional plan (enterprise features) | $799/month | $9,588 | $28,764 |
| With implementation and onboarding | — | +$5,000-$15,000 | $15,764-$43,764 |
Even at the highest tier with premium onboarding, you are looking at under $50,000 over three years. That is a 30-40x cost difference compared to building.
The usage-based pricing model means you pay proportionally to value received. You are not carrying the fixed cost of a platform team regardless of how many products you have connected.
Where the Savings Compound
The cost gap actually widens over time, not narrows. A purpose-built platform spreads R&D costs across all customers. When the EU publishes a new DPP delegated act, the platform provider updates once and every customer benefits. When Apple revises its Wallet API, the platform handles the migration. When GS1 updates the Digital Link specification, the resolver is updated centrally.
With an internal build, every one of those changes lands on your backlog, staffed by your engineers, funded by your budget.
The Real Question
Should your engineering team build a connected product platform, given that they almost certainly could? That is the actual question — and it is a strategic one, not a technical one. Building this platform means committing to a decade-long engineering investment in a domain that is not your core competency, in a regulatory environment that is actively evolving, with integration requirements that compound every year. It means your engineers are maintaining a QR resolver and a DPP compliance layer instead of building the product features that win you customers. The most successful manufacturers do not succeed by building their own payment processors, email infrastructure, or cloud hosting. They succeed by focusing relentlessly on what they do best and choosing specialised partners for horizontal infrastructure. Connected product platforms are horizontal infrastructure. The manufacturers building the most compelling product experiences in the market are the ones who recognised this distinction early — and directed their engineering investment accordingly.
BrandedMark is the operating system for physical products — connecting every unit to its owner with digital identity, warranty management, product support, and EU Digital Product Passport compliance. See how it works or explore the platform.
Frequently Asked Questions
How much does it actually cost to build a connected product platform in-house?
A realistic 3-year total cost of ownership for an internal build is $1.4M–$1.7M when you include initial development ($120K–$170K), ongoing maintenance engineering (1.5–2 FTEs at $270K–$440K/year), infrastructure, compliance audits, and third-party API costs. Most internal estimates stop at the initial build and omit the maintenance tax — which represents 60–80% of total lifecycle cost.
What are the alternatives to building a connected product platform?
Purpose-built platforms exist for every part of the stack. For post-purchase engagement and warranty, options include Registria and NeuroWarranty. For post-purchase experience and returns, Narvar is widely used. BrandedMark covers the full connected product OS — digital identity, warranty lifecycle, DPP compliance, self-serve support, and direct commerce — in a single integrated platform designed specifically for manufacturers of durable goods.
When does building in-house actually make sense?
Building is worth considering if you process 1M+ units per month, have a dedicated platform engineering team of 5+ engineers, or have unique technical requirements (proprietary tag technologies, classified supply chain data, on-premise regulatory mandates) that no SaaS provider can accommodate. For the majority of manufacturers, the math favors buying by 30–40x over three years.
How long does it take to deploy a bought platform vs. build one?
A purpose-built platform like BrandedMark can be deployed and generating registrations within days to weeks. An internal build typically takes 6–12 months to reach MVP — and that MVP will lack the regulatory compliance layers, edge-case handling, and third-party integrations that a mature platform has already built. The time-to-value gap is significant.