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
Here is a reasonable feature list for a connected product platform, broken into individual workstreams with honest time estimates for a senior full-stack developer:
| Feature | Estimated Build Time | Complexity |
|---|---|---|
| QR code generation with unique serial numbers | 2 weeks | Low |
| GS1 Digital Link compliance | 2-3 weeks | Medium |
| NFC tag encoding and read handling | 2-3 weeks | Medium |
| Label/print integration for manufacturing lines | 3-4 weeks | Medium |
| Warranty registration forms | 1-2 weeks | Low |
| Warranty claims processing | 3-4 weeks | Medium |
| Product support content CMS | 4-6 weeks | Medium |
| Spare parts catalog and ordering | 4-6 weeks | Medium |
| Stripe payment integration | 2-3 weeks | Medium |
| EU Digital Product Passport data model | 3-4 weeks | Medium |
| Analytics dashboard | 3-4 weeks | Medium |
| Multi-tenant architecture | 4-6 weeks | High |
| User authentication and access control | 2-3 weeks | Medium |
Add it up and you get roughly 35-50 developer-weeks for an MVP. At a loaded cost of $85/hour for a senior developer in the US, that is $120,000-$170,000 just for the initial build. Expensive, but not outrageous. A VP of Engineering could make a credible case for it.
This is where most build-vs-buy analyses stop. And this is where they go wrong.
The Compound Complexity Problem
Individual features are straightforward. The integration surface between those features is where internal builds collapse.
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%
Let us assume your team builds an excellent V1. Congratulations — you have just signed up for the most expensive phase of the project.
Industry data consistently shows that maintenance costs account for 60-80% of total software lifecycle costs (Boehm, Software Engineering Economics; confirmed by the Standish Group CHAOS Report across enterprise software projects). For a connected product platform that interfaces with external standards, regulations, and third-party APIs, that ratio skews even higher.
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
Every engineering sprint spent on connected product infrastructure is a sprint not spent on your actual product.
This is the cost that never appears in build-vs-buy spreadsheets, and it is often the largest cost of all. If your company makes kitchen appliances, your competitive advantage lives in better appliances — not in a better QR code resolver. If you make industrial pumps, your differentiation is in pump engineering and predictive maintenance algorithms — not in warranty claims processing.
The opportunity cost calculation is uncomfortable because it forces a strategic question: What is your team uniquely good at, and is building a connected product platform on that list?
For most manufacturers, the honest answer is no. Connected product platforms are horizontal infrastructure — like payment processing, email delivery, or cloud hosting. They benefit from specialization, shared R&D investment, and economies of scale that no single manufacturer can replicate internally.
A major European appliance manufacturer we spoke with had three senior engineers spending 60% of their time maintaining a custom warranty registration system built in 2021. Those same engineers could have been building the IoT diagnostics features that their product team had been requesting for 18 months. The switching cost of migrating off that internal system felt high — but the cost of staying on it was higher.
When Building Does Make Sense
We said this would be honest, so here it is: there are scenarios where building your own connected product platform is the right call.
You should consider building if:
- You process 1M+ units per month and need sub-millisecond response times with custom infrastructure optimized for your specific access patterns
- You have a dedicated platform engineering team of 5+ engineers whose sole job is this system — not shared with product development
- Connected products are your core business, not an adjacent capability. If you are a connected product platform company (like us), building is obviously the right choice
- You have unique technical requirements that no existing platform supports — proprietary tag technologies, classified supply chain data, or integration with legacy manufacturing execution systems that cannot be exposed to third-party APIs
- Regulatory requirements mandate on-premise data processing in jurisdictions where no SaaS provider operates data centers
If two or more of these apply to you, an internal build may genuinely be the better path. You have the scale to amortize the cost, the team to sustain it, and the strategic rationale to justify it.
For everyone else — and that is the vast majority of manufacturers — the math points decisively in the other direction.
The Math
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
The question is not whether your engineering team can build a connected product platform. They can. Your engineers are smart, capable, and probably already sketching architecture diagrams on whiteboards.
The question is whether they should.
Building a connected product 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 in complexity every year.
For the small number of manufacturers operating at massive scale with dedicated platform teams, that commitment makes sense. For everyone else, it is a distraction from the work that actually differentiates your products in the market.
The most successful manufacturers we work with did not become successful by building their own payment processors, their own email infrastructure, or their own cloud hosting. They became successful by focusing relentlessly on what they do best — and choosing the right partners for everything else.
Your connected product platform is no different.
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.