An IoT system integrator can build almost everything from scratch. The more difficult question is whether it should.
I have met many system integrators who are confident about sensors, wiring, network installation, control panels and customer requirements. Yet when an IoT project requires a device management platform, mobile application, dashboard, alert engine, database, analytics, cybersecurity controls and long term support, the project suddenly becomes far more complicated than expected.
The first version may still look manageable. A developer connects several sensors, stores the readings in a database and creates an attractive dashboard. Everyone is pleased during the demonstration. The customer sees colourful charts, the sensors are transmitting, and the project team begins to believe that most of the work has been completed.
In reality, the demonstration is often the easy part.
The real test begins when the system must operate every day, support hundreds or thousands of devices, manage different users, recover from communication failures, protect customer data and continue working after the original developer has left the company.
This is where an IoT system integrator must make one of its most important business decisions: what should we build ourselves, what should we buy, and where should we work with a partner?
Why Building Everything Feels Attractive
Building everything internally creates a strong sense of ownership. The integrator controls the source code, the user interface, the product roadmap and the customer experience. There is no dependence on an external platform provider, and the company can present the system as its own solution.
That sounds attractive, especially when the first project is small. A basic IoT application may only require a few devices, a simple database and several dashboard screens. The initial development cost may also appear lower than purchasing an enterprise platform.
But the first project rarely reveals the full cost of owning an IoT system.
Once the system moves into an operational environment, the integrator becomes responsible for matters such as:
- Device registration and authentication
- Communication protocols and message handling
- Database capacity and data retention
- User accounts, roles and permissions
- Alerts, rules and escalation procedures
- Dashboard maintenance
- API management
- System monitoring and backups
- Security updates and vulnerability management
- Technical support throughout the contract period
The cost is no longer limited to writing the software. It includes maintaining, testing, documenting, securing and supporting it for many years.
A system integrator may successfully build a platform, but it must then ask a harder question: are we prepared to become a software platform company?
What an IoT System Integrator Should Build
I believe system integrators should build the parts that reflect their industry knowledge, customer relationships and understanding of the operational problem.
For example, an integrator serving water utilities may understand how pump failures occur, which pressure changes require attention, how technicians respond to alarms and what managers need to see each morning. That knowledge is far more valuable than building another generic data ingestion engine.
The integrator should consider building:
1. Industry Specific Workflows
A water monitoring solution, building management system and cold chain application may use similar IoT components, but their operational workflows are very different.
The integrator should design how an alert becomes a task, who receives it, what action must be taken, when the issue should be escalated and how the action is verified. This is where the integrator’s experience creates real value.
2. Customer Specific Applications
Some customers need specialised reports, approval processes, billing calculations or connections to existing systems. These customer facing components may justify custom development because they directly support how the organisation works.
3. Operational Rules and Domain Logic
The integrator should own the rules that turn sensor readings into meaningful operational decisions.
A temperature reading of 8°C is only a number until someone understands what it means for a vaccine refrigerator, food storage facility or industrial process. The domain logic that interprets the reading is part of the integrator’s business knowledge.
4. The Customer Experience
The integrator should control how the complete solution is presented, delivered and supported. Even when an external platform powers the system, the integrator can still own the customer account, project design, deployment, training and service relationship.
In simple terms, build what makes the solution different. Do not spend most of the development budget recreating components that customers will never see or appreciate.
What an IoT System Integrator Should Buy
Buying is often the better choice for mature, repeatable components that require continuous technical maintenance.
These may include IoT platforms, cloud infrastructure, device connectivity services, cybersecurity products, data visualisation tools and specialised hardware. Buying these components allows the integrator to focus more of its time on delivering the customer’s outcome.
An existing IoT platform, for example, may already provide:
- Device and user management
- MQTT, HTTP, CoAP and API connectivity
- Data storage and retrieval
- Dashboards and visualisation
- Rules and alerts
- Multi-tenant account structures
- Remote device communication
- Security controls
- Backup and system monitoring
- Technical documentation
Recreating these capabilities may take months or even years. They will also require permanent developers, testers and support personnel.
The buying decision should not be based only on the subscription or licensing price. The integrator should compare that price with the total cost of internal development, including salaries, infrastructure, testing, documentation, upgrades, security reviews, customer support and staff replacement.
Cheap software development can become very expensive software ownership.
When Partnership Is the Better Choice
Some IoT opportunities are too complex for a simple build versus buy decision. In these cases, partnership may provide a better commercial model.
A partner does more than sell a product. A suitable partner helps the system integrator design the architecture, prepare demonstrations, estimate project costs, answer technical questions, support deployment and solve problems after the system goes live.
Partnership is especially useful when the system integrator has strong customer access and sector knowledge but does not have an internal software development team. This is common among Malaysian system integrators. Many are skilled in hardware, networking, electrical systems, automation, project management and government procurement, but they may not want to maintain a full IoT software team.
This should not prevent them from participating in IoT projects.
A partnership allows each party to concentrate on its strongest contribution. The system integrator owns the customer relationship and project delivery. The platform partner provides the reusable software foundation and technical support. Hardware partners supply the sensors, gateways or communication modules required by the project.
The customer receives a complete solution without forcing one company to pretend that it can do everything alone.
A Practical Decision Framework
Before deciding whether to build, buy or partner, I would ask five questions.
1. Does This Capability Differentiate Our Business?
If the component represents unique sector knowledge or a process that customers value, consider building it. If it is a standard technical function, buying may be more sensible.
2. Do We Have the People to Maintain It?
Having one developer who can create the first version is not the same as having a team that can maintain a production system. Think about what happens when that person resigns, becomes unavailable or is assigned to another project.
3. How Quickly Must We Reach the Market?
If the opportunity must be delivered within a few weeks, building a complete platform is unlikely to be practical. An existing platform can shorten the time between the customer’s request and the first working deployment.
4. What Happens After the Pilot?
The architecture must support the project if it expands from ten devices to one thousand devices, or from one site to fifty sites. A prototype that cannot grow will eventually need to be rebuilt, usually at the most inconvenient time.
5. Who Carries the Long Term Risk?
Every custom component creates an obligation. Someone must fix bugs, install updates, monitor security, answer customer questions and ensure compatibility with new devices. The integrator should understand this responsibility before accepting it.
A useful rule is:
- Build the industry knowledge, workflows and customer experience.
- Buy mature technical components that would be costly to recreate and maintain.
- Partner when the project needs skills, technology or long term support beyond the integrator’s internal capacity.
The Hybrid Model Is Often the Strongest
The best answer is rarely to build everything or buy everything. Most successful IoT projects use a hybrid approach.
The integrator may purchase sensors from one vendor, use a ready IoT platform, create a sector specific application and connect the solution to the customer’s existing enterprise systems. The final result still belongs to the integrator’s solution portfolio, even though several partners contribute to it.
This model gives the integrator control over the parts that matter most while reducing the technical and financial risks of owning every layer.
It also creates room for recurring revenue. Instead of earning only from hardware installation, the integrator can offer platform subscriptions, monitoring services, maintenance contracts, reports and operational support. The customer relationship can continue long after the physical installation has been completed.
Build a Business, Not Just a System
An IoT system integrator should not measure its strength by how many components it can develop alone. The better measure is whether it can deliver a dependable solution, solve the customer’s operational problem and support the system throughout its working life.
There is no shame in buying a proven component. There is no weakness in working with a platform partner. Even the largest technology companies depend on ecosystems of specialised providers.
The real mistake is spending months building a generic platform while the customer is still waiting for the original problem to be solved.
My advice is simple: own the customer, own the operational knowledge and own the outcome. Build the parts that carry your experience. Buy the components that others have already perfected. Partner where shared capability helps you deliver with greater confidence.
For an IoT system integrator, the goal is not to prove that it can build everything. The goal is to create a solution that continues working when the demonstration is over, the project team has gone home and the customer begins depending on it every day.
What has been your experience? Does your company prefer to build its own IoT software, buy an existing platform or work with a technology partner? I would be interested to hear which model has worked for you and what lessons you learned along the way.
Leave a Reply