If you’ve been in IoT integration for more than a year, you’ve heard some version of this: “Every new client, we build 70% of the same platform again. Connectivity layer. Device management. Dashboards. Alerting. Then we customize the last 30%.” Team of nine engineers. Four projects a year. They wanted to do twelve.
That story isn’t unusual. Most SIs building IoT solutions have hit some version of this wall. The first custom platform felt like an investment. The second felt like repetition. By the fifth, you’re not building solutions anymore. You’re maintaining five slightly different versions of infrastructure you never wanted to be in the business of maintaining.
I’m a Technical Product Manager at Iotellect, so I see the aftermath of this pattern regularly. Partners come to us after two or three years of custom builds, and the conversation always starts with the same realization: the platform work ate the engineering budget.
What Building from Scratch Actually Costs
The visible cost is engineering hours. Everything else hides until it compounds.
Development time. A minimum viable IoT platform (device connectivity, data storage, basic dashboards, user management, alerting) takes a competent team 6-9 months to build. Not the polished version. The version that works well enough to demo and barely well enough to deploy. Protocol drivers alone can consume weeks per protocol. Modbus TCP is straightforward. Modbus RTU over serial with RS-485 addressing quirks on legacy PLCs? That’s a different conversation. OPC UA with certificate management and security policies? Budget a month.
Maintenance load. Software doesn’t age gracefully. Security patches, dependency updates, OS compatibility, database migrations, certificate renewals. Maintenance typically consumes the majority of total software lifecycle costs — I’ve seen teams where two out of five engineers spend their entire week on platform upkeep across client deployments. That burden falls entirely on your engineering team, the same people you need delivering client projects.
The talent problem. Building an IoT platform requires embedded systems knowledge, backend architecture, frontend development, database design, security expertise, and protocol-level debugging. Finding engineers who work across that stack is expensive. Keeping them is harder. You’re competing with product companies who offer stock options and the appeal of working on something used by thousands, not a bespoke platform for one client’s factory.
Scaling kills you. Client one has 200 sensors. Client two has 3,000. Client three needs edge processing because their WAN drops twice a day. Client four requires on-premise deployment because their security team won’t approve outbound data transfer. Each variation means rewriting parts of your platform. Your “reusable” codebase becomes four divergent forks, and your engineers spend more time on infrastructure than on the work clients actually pay you for.
The initial build is the down payment. Maintenance, scaling, security updates, and platform divergence across clients are the mortgage.
The Reusable Platform Model
The alternative isn’t becoming a SaaS reseller. That’s where you lose differentiation and compete on price against every other partner in the vendor’s catalog.
The alternative is separating infrastructure from value. Use a platform for the parts that repeat across every project (device connectivity, protocol translation, data pipelines, dashboards, user management, alerting, device lifecycle). Build custom logic, integrations, and domain-specific workflows on top.
This changes the economics of an SI business.
Delivery speed. When you’re not rebuilding Modbus drivers and dashboard frameworks for every engagement, a project that took six months takes six weeks. The engineering hours shift from infrastructure to client-specific customization, the work that actually differentiates you.
Margins. Custom platform development is a cost center disguised as a capability. Every hour your engineers spend on generic infrastructure is an hour not spent on billable, high-margin integration work. A reusable platform turns that cost into a predictable line item and frees engineering capacity for the work clients value most. Partners we’ve worked with report margin improvements in the range of 15-25 percentage points per project after making the switch.
Scale without rewriting. Client’s PoC had 50 sensors in one building. Production means 4,000 across twelve sites. Next project needs BACnet and LonWorks for a smart campus after you spent a year doing Modbus in manufacturing. Utility client requires air-gapped on-prem with edge processing because their SCADA network can’t touch the internet. On a mature platform, these are configuration changes. On a custom build, each one is a fork.
Your best engineers didn’t join your company to debug MQTT broker configurations. They joined to solve client problems. A platform model lets them do that.
What This Looks Like in Practice
I work on Iotellect, so I’ll use it as the example. The platform ships with 30+ built-in protocol drivers: Modbus (TCP and RTU), OPC UA, MQTT, BACnet, SNMP, HTTP, DLMS/COSEM, EtherNet/IP, IEC 60870-5-104, DNP3, and others. Each driver handles the protocol’s actual complexity (register mapping, polling intervals, data type conversion, connection management) so your team doesn’t build it from scratch every engagement.
The low-code layer means dashboards, workflows, alerting rules, device management screens, and reporting can be configured visually. Your engineers write code for the part that requires it — custom integrations, domain-specific logic, complex data transformations — and configure the rest. Deployment runs cloud, hybrid, on-prem, or edge, depending on what the client’s IT and security teams will approve.
Pricing is tier-based, tied to infrastructure scope, with no per-device fees. This matters more than it sounds. Per-device pricing from other platforms looks reasonable at PoC scale: fifty devices, affordable monthly fee. But your client’s production deployment is 4,000 devices, and the platform cost makes the project economics collapse. Tier-based means your costs don’t scale linearly with device count. You can quote a three-year engagement and know your platform costs in advance.
The Partnership Model Behind the Platform
A platform is a starting point. What determines whether it works for an SI business is how the vendor treats its partners.
Most IoT platform vendors treat SIs as a channel. You sell their product, they take a cut, and if your client calls the vendor directly for the next project — well, that’s business. You invest in certifications, build expertise, develop client relationships, and the vendor competes with you for your own accounts.
We built the Iotellect partnership program around the opposite assumption: the SI owns the client relationship, full stop. That means deal registration with a contractual no-compete commitment, white-label deployment under your brand, structured technical training aimed at self-sufficiency rather than vendor dependency, and partner catalog listing with inbound lead routing by geography and expertise.
None of these are revolutionary individually. What matters is that they come from a vendor that’s been independently owned since 2001, has no PE backers pushing for an exit, and isn’t a non-core division about to get sold. When your vendor’s incentive is platform growth through partner success, the partnership terms stay stable. When the incentive is exit multiple, they don’t.
The Build-vs-Buy Decision in 2026
Your team can build an IoT platform. That was never the question. The question is what it costs you — not in dollars, but in projects you didn’t deliver, engineers who spent Q2 patching infrastructure instead of shipping client solutions, and the four divergent platform forks that nobody wants to maintain but everybody depends on.
Building from scratch made sense in 2015 when the platform market was immature. In 2026, mature platforms handle connectivity, device management, data pipelines, dashboards, and workflow automation out of the box. The custom development that differentiates your SI business is domain expertise and client-specific vertical solutions your competitors can’t replicate by buying the same license. That’s where your engineering hours should go.
The SIs winning in this market aren’t the ones with the most custom code. They’re the ones who figured out what to build and what to stand on.
