The IoT Build-vs-Buy Trap: Why Most Platforms Fail to Scale
Tobiloba OdejinmiBy Tobiloba Odejinmi
Education
May 28, 2026 • 9:53 PM
2m2 min read
Verified
Source: Unsplash
The Core Insight
This analysis explores the strategic trade-offs for OEMs choosing between building internal IoT stacks or purchasing reusable platforms. While 'buy' strategies significantly reduce time-to-market and break-even periods, they carry high risks of vendor lock-in and project failure if the platform doesn't align with the product portfolio. Success depends on a portfolio-first approach, rigorous capability testing, and ensuring vendor survivability.
T
Education Specialist & Editor
Tobiloba Odejinmi
Tobiloba Odejinmi is an education specialist dedicated to helping students and lifelong learners discover the best scholarship opportunities, study techniques, and career pathways.
The Kodawire Editorial Team consists of experienced journalists and subject matter experts dedicated to delivering accurate, well-researched, and engaging content.
The Hidden Cost of IoT Speed: Why 'Buying' Often Backfires
The Bottom Line
The Speed Trap: While "buying" an IoT platform cuts time-to-market from 16 to 9 months, only 13% of these projects exceed expectations.
The 30% Rule: If more than 30% of your user stories require custom code, you aren't buying, you’re building on someone else’s runtime.
Portfolio Math: Reusable platforms only make financial sense once you have three to five connected products to amortize the costs.
Vendor Risk: High-profile exits (like Google IoT Core) prove that platform selection is a long-term strategic bet, not just a software purchase.
In my years covering the industrial technology sector, I’ve seen the same cycle repeat: an OEM leader, feeling the pressure of a 41-month average time-to-market, decides that "buying" a platform is the silver bullet. They want to skip the heavy lifting of custom development. But as I’ve dug into the data, it’s clear that speed is often a vanity metric. If you pick the wrong platform, you aren't just losing money, you’re building a foundation on shifting sand. Much like ignoring critical specifications in hardware engineering, choosing the wrong software foundation can lead to catastrophic long-term failures.
Evaluating the long-term viability of an IoT platform requires looking beyond initial speed metrics. (Credit: Tirth Jivani via Unsplash)
How I Researched This
To provide this analysis, I’ve synthesized data from recent industrial IoT research, including the 2023/2024 commercialization reports that tracked over 300 industrial initiatives. I’ve cross-referenced these findings with historical vendor exit patterns and developer feedback from technical forums. My goal here isn't to sell you a specific tool, but to provide a framework for evaluating the "buy vs. build" decision that actually accounts for the five-year lifecycle of a connected device.
The Three Paths: Build, Buy, or Hybrid
When you look at the landscape of IoT development, three distinct strategies emerge. Each carries a different risk profile, and understanding them is the first step toward avoiding the "vendor tax."
Build (47% of projects): This is the high-control route. While it’s slower to start, it boasts a 40% success rate in exceeding expectations. You own the stack, but you pay for every line of code.
Buy (30% of projects): This is the "fast" route. It cuts break-even time from 20 months down to 12. However, it’s the most fragile; only 13% of these projects actually hit their targets.
Buy-and-integrate (38% of projects): This is often the worst of both worlds. You buy a platform, realize it misses 30% of your requirements, and then pile custom code on top. You end up with the maintenance burden of a "build" and the constraints of a "buy."
The Hidden Technical Debt of Integration
The "Buy-and-integrate" path is the most dangerous because it creates a "black box" dependency. When you integrate custom code into a proprietary platform, you lose the ability to perform seamless vendor updates. You are essentially creating a fork of the platform that the vendor will never support, meaning every time they push a security patch, your custom integration risks breaking. This creates a permanent, high-cost maintenance cycle that often exceeds the cost of building a custom solution from scratch. Just as proper tool selection is vital for professional results in manufacturing, choosing the right architecture is essential for software longevity.
Scalability requires a robust, multi-tenant architecture that avoids proprietary bottlenecks. (Credit: Shubham Dhage via Unsplash)
The Scalability Paradox
With 60% of IoT projects stalling at the Proof of Concept (PoC) stage and less than 30% of Industry 4.0 pilots reaching full-scale production, the bottleneck is rarely the hardware. It is the inability to transition from a single-tenant PoC to a multi-tenant enterprise architecture. If your chosen platform cannot handle multi-tenancy natively, you will be forced to spin up separate instances for every client, which destroys your margins as you attempt to scale.
The Portfolio Math: When Reusable Platforms Actually Pay Off
One connected product rarely justifies a platform. If you are only shipping one device, the overhead of a reusable platform will almost always exceed the cost of a lean, custom build. The math changes, however, when you reach the third or fifth product.
By the time you hit your fifth product, the platform capabilities you’ve already paid for, data standardization, API management, and security protocols, are essentially "free" to deploy. You are no longer building a product; you are building a business line. This is where the network effects kick in, allowing you to amortize the fixed costs across your entire portfolio. Much like the strategic shift toward agentic AI, successful IoT scaling requires a long-term view of how your technology stack supports future growth.
The Decision Matrix
If you are currently debating your next move, ask yourself these three questions:
Does my roadmap include at least 3 connected products? (If no, consider a custom build).
Does the platform meet 70% of my core user stories out of the box? (If no, you are building, not buying).
Can I white-label the interface without custom engineering? (If no, you’ll be trapped in a vendor-locked UI).
My Recommended Setup
When I look at the current landscape, I focus on three categories of tools that provide the most stability:
Low-Code Application Layers: Platforms like Mendix or OutSystems have become the standard for a reason, they have the maturity to handle enterprise-scale deployments.
White-Label Backends: Look for vendors that prioritize the OEM's brand over their own. If you can't remove their logo from the dashboard, keep looking.
Machine-Readable Data Exports: Always prioritize platforms that allow you to export your asset models in a format that isn't proprietary.
The Unpopular Opinion
Most industry experts will tell you that "time-to-market" is the ultimate KPI. I disagree. In the world of industrial IoT, "time-to-market" is a vanity metric if your product is obsolete or unsupported three years later. I would rather see an OEM take six months longer to launch on a platform they truly own than rush to market on a platform that might be retired by the vendor in two years.
We’ve seen a massive shift from the "build everything" mentality of 2020 to the "buy everything" rush of 2024. Now that we’ve seen the fallout of major vendor exits, do you think the industry is swinging back toward a more cautious, hybrid approach? I’ll be in the comments for the next 24 hours to discuss your experiences with platform lock-in.
Buying an IoT platform is risky because only 13% of such projects exceed expectations. It often leads to vendor lock-in, and if the vendor exits the market (like Google IoT Core), the project may become unsupported.
The 30% rule states that if more than 30% of your user stories require custom code, you are not truly 'buying' a platform; you are building on someone else's runtime, which creates a high-cost maintenance burden.
A reusable platform typically becomes financially viable once you have three to five connected products, allowing you to amortize the fixed costs of data standardization, API management, and security across your entire portfolio.
Active Engagement
Was this information helpful?
Join Discussions
0 Thoughts
Editorial Team • Question of the Day
"Have you ever had to migrate an IoT project after a vendor retired their platform, and what was the single biggest lesson you learned from that process?"
