When building an IoT product, the usual question is whether you should build your own IoT platform or buy one. I think that is the wrong way to frame the decision. The better question is: which parts of your technology are actually your product, and which parts are infrastructure that somebody else has already spent years building?
Imagine building a generic software application 15 years ago. Would you start by writing your own operating system? Almost certainly not. The operating system solves an enormous number of problems that are essential to your application but have nothing to do with what makes your application unique. Trying to build it yourself would simply consume most of your development resources before you even started creating the actual product.
The same logic applies outside software. Suppose you manufacture a smartwatch or some specialized industrial device for diagnosing problems in optical cables. Would you build your own semiconductor factory just to manufacture the processor you need? Again, probably not. Chip manufacturing is fundamental infrastructure. Unless your business is actually about designing and manufacturing chips, building a semiconductor factory would be an irrational use of resources.
The same applies to car manufacturing. A modern airbag is a surprisingly sophisticated product. It includes electronics, sensors, chips, mechanical components, software, the actual inflatable bag, packaging, safety logic, and many other pieces. Yet car manufacturers normally don’t start building their own airbags from first principles simply because airbags are important. There are specialized suppliers whose entire business is making that reusable component work properly.
IoT platforms belong to exactly the same class of technology. They are infrastructure. Unless your objective is to become an IoT platform vendor yourself, rebuilding the entire platform layer simply to create one or several IoT products, solutions, or SaaS services usually makes very little sense.
Infrastructure Is Layered
Using existing infrastructure does not mean stopping at the lowest possible level. AWS, Azure, databases, message brokers, containers, Java, React, Kubernetes, and similar technologies are all infrastructure. But an IoT application platform is another infrastructure layer built on top of them.
A semiconductor chip does not eliminate the need for an airbag. In the same way, having access to AWS, a database, an MQTT broker, React, and containers does not mean you already have an IoT application platform. Those technologies provide important building blocks, but somebody still has to assemble them into a coherent environment that can be reused across applications.
That higher-level environment has to handle data modeling, device connectivity, permissions, security, multi-tenancy, workflows, automation, alarms, events, HMIs, dashboards, audit trails, failover clustering, on-premise deployment, edge deployment, cloud deployment, migrations, upgrades, APIs, application lifecycle management, and many other concerns.
None of those capabilities is necessarily exotic in isolation. The hard part is making all of them work together consistently, securely, and predictably for many years.
The 95% You Probably Don’t Want to Build
Inside our own platform, Iotellect, we see this principle very clearly. For roughly every one million lines of code we write ourselves, we use around twenty million lines of code from Java, React, and other libraries and technologies underneath us.
We do not write our own relational databases, NoSQL databases, graph databases, or round-robin storage engines simply because storage is a critical part of an IoT platform. Existing technologies already solve those problems well, and we believe their evolution will continue to satisfy our future needs. The same logic applies to communication libraries, UI technologies, and many other foundational components.
Our value as a platform vendor is therefore not in rebuilding everything underneath us. Our value is in creating another reusable infrastructure layer on top. One of the most important parts of that layer is the unified data model, which ties all the underlying technologies together so that databases, communications, security, permissions, UI, application logic, and other subsystems can interact consistently.
After roughly 25 years of evolution, that integration layer itself consists of millions of lines of code. Much of that code exists simply to make all the underlying technologies work together through a common model so that application developers can reuse them relatively easily.
The same principle repeats one layer above us. In many mature software products, perhaps only a relatively small part of the total technology is truly unique. The rest consists of common capabilities that thousands of other products also need.
Scalability is usually not your product. Permissions are not your product. Failover clustering is not your product. Multi-tenancy is not your product. Audit trails are not your product. Device connectivity is probably not your product. Yet somebody still has to build, test, maintain, document, secure, and evolve all of them.
The rational goal is therefore to reuse everything that does not differentiate you and invest your engineering resources into the part that does.
Using a Platform Does Not Mean Giving Up Custom Development
One common misconception is that adopting a platform means accepting whatever the platform vendor gives you and losing the ability to build anything custom. That should not be how a good platform works.
If an existing UI component does what you need, use it. If a workflow engine solves the problem, configure it instead of rebuilding the same infrastructure yourself. If an existing industrial protocol driver works, use it. But when the platform’s abstraction no longer fits your requirements, you should be able to move down the stack and build the missing piece yourself.
In Iotellect, for example, you can create custom React and TypeScript UI components, write Java code, create scripts and plugins, and develop your own communication drivers. Using a platform does not mean that React, Java, databases, or other lower-level technologies somehow disappear.
The platform simply lets you work at a higher abstraction level whenever that abstraction is useful. You use the platform where it fits, and you fall back to lower-level technologies where your product genuinely requires something custom.
That means the real choice is not “platform development versus custom development.” Serious products usually need both.
The Real Question Behind Vendor Lock-In
Vendor lock-in is a real concern, but I think it is often exaggerated. The mistake is to imagine that avoiding an IoT platform somehow eliminates lock-in altogether.
Every major technology choice is a strategic bet. If you choose Java today, moving a large mature product to .NET later will be expensive. If you choose one database architecture, replacing it ten years later may be painful. If you build deeply on AWS, moving everything to another cloud provider may require substantial effort. Even if you build your own framework, you become dependent on your own framework.
We have experienced this ourselves. We started our technology in C++ more than two decades ago and later made a major strategic decision to move to Java. That migration took years and required substantial investment. But it was an important architectural bet, and in retrospect we believe it was the right one. Today it would still be extremely painful for us to move the entire platform from Java to .NET or Python, but Java does not materially limit what we can do.
The same applies to any IoT platform or infrastructure component. The objective is not to eliminate lock-in. The objective is to make sure the lock-in is survivable.
What Survivable Lock-In Looks Like
If you are making a strategic technology choice, one of the most important things to investigate is whether you retain visibility throughout the stack.
If you create application logic, workflows, models, dashboards, or other low-code artifacts, they should not exist only as opaque proprietary objects hidden inside a black box. There should be a way to export them into a machine-processable format so that, if something seriously goes wrong, they can be understood, transformed, and migrated elsewhere.
The same principle applies to the platform itself. If the platform is strategically important to your business, you should consider mechanisms such as source-code escrow. If the vendor disappears, discontinues a critical module, stops maintaining something you depend on, or simply goes out of business, you should have a contractual path to obtain the source code and continue operating or maintaining the technology yourself.
That does not mean you actually want to maintain the platform. Normally, you absolutely do not. The whole point of buying infrastructure is to avoid doing that work yourself. But in a worst-case scenario, you should have the option to modify a specific layer rather than being forced to throw away the entire stack and start over.
For us, source access and escrow arrangements are part of many strategic partnership agreements for exactly this reason.
Platform Failure Is Real, but Migration Is Usually Survivable
Since the IoT term became widely used, and even before that, the market has seen hundreds of technologies that were effectively IoT platforms. Before 2015, many of them were simply called intelligent device management frameworks, M2M platforms, remote monitoring frameworks, or something similar.
A large number of them disappeared. In many cases, founders and investors underestimated how complex it is to build and maintain this kind of fundamental technology.
We have seen customers migrate to Iotellect from other platforms after the original vendor disappeared, stopped evolving the product, or no longer met the customer’s needs. Those customers were clearly locked into their previous technology to some degree, but in most cases we still found a way to migrate a large part of their application logic and UI.
The migration created work, some disruption, and some temporary loss of momentum, but it was rarely a catastrophe. Vendor lock-in is usually more of a migration cost than an existential threat.
And today AI is making this situation even less dangerous. Migration is exactly the kind of one-off engineering task where AI can help enormously: understanding unfamiliar code, translating application logic, reconstructing components, converting APIs, and assisting with testing.
So vendor lock-in deserves serious consideration, but I believe it is often feared far more than the actual risk justifies.
A POC Is a Garage Prototype
There is, however, one obvious situation where I would not recommend buying an IoT platform: a disposable proof of concept.
Think about a car prototype. If you are creating one experimental vehicle just to see whether the concept works and whether anyone is interested, you can build it in a garage. You do not need to build a production line before you even know whether the car has a future.
The same applies to an IoT POC. If you are simply trying to show something to a potential customer, test an idea, or validate whether anyone might pay for it, you can use whatever technology lets you move quickly and cheaply. You can write code directly, use open-source tools, or use the free version of a commercial platform.
At this point, it makes little sense to accept major commercial commitments. The POC exists to test whether the idea deserves to become a real product.
An MVP Is the Beginning of the Production Line
The situation changes the moment you start believing the prototype has a real commercial future.
If you build a successful prototype car in a garage and customers at a car show clearly want to buy it, you do not simply continue building the next hundred cars in the same garage. You start preparing a production line.
The same applies to software. Once you have enough confidence that the POC is going to become an actual product, solution, or service, you should start thinking about the infrastructure required to support that product over many years.
The trigger is not a specific number of devices, customers, users, or integrations. It is not “we reached 100,000 devices” or “we now need multi-tenancy.”
The real trigger is commercial confidence.
A POC should optimize for experimentation. A product should optimize for repeatability, maintainability, scalability, extensibility, and longevity.
So What Should You Build Yourself?
The principle is ultimately very simple.
Build what differentiates your product. Reuse what does not.
If an infrastructure technology exists that satisfies your current needs and you trust that its architecture and evolution are capable of satisfying your future needs, it probably makes sense to use it.
If no suitable infrastructure exists, or if you have strong reasons to believe the available technologies will constrain you strategically in the future, then building some part of the infrastructure yourself can be justified.
But rebuilding fundamental technology simply because you can is usually a poor use of engineering resources.
A software company should not write its own operating system merely to build an application. A smartwatch manufacturer should not build a semiconductor factory merely to obtain a processor. A car manufacturer should not reinvent the airbag merely because safety is important.
And an IoT product company should not rebuild an entire IoT platform unless building IoT platforms is actually the business it wants to be in.