Consider a small software team that has built a cold-chain monitoring system for a logistics operator. Sensors report temperatures from refrigerated warehouses and trucks, while dispatchers receive alerts when conditions put shipments at risk. After months of adjustments, the system runs reliably, the client is satisfied, and five other operators express interest in a similar service.
The team assumes it now has a product to sell. Yet the first prospective customer asks how its contractors will access vehicle data, who will configure new sensors, and whether its own incident procedures can be supported. The requests are reasonable, but answering them means reopening decisions made for the first client. A second deployment is beginning to look almost as labour-intensive as the first.
A SaaS product has a different obligation. It must serve organisations that were not involved in its original design without forcing the team to develop, update, and support a separate version for each customer. A founder may see five new contracts as growth; the engineering team may see five separate implementations. The gap between those perspectives can become expensive long before the customer base looks particularly large.
Moving the application to the cloud and charging a subscription will not resolve the problem. Productisation requires deciding which capabilities should be shared, which customer differences can be handled through configuration, and which requests justify individual development. Those decisions shape the roadmap and determine how much additional work comes with every new sale.
For the cold-chain team, the first deployment proves that its software solves a real operational problem. It has yet to establish whether the same value can be delivered repeatedly without turning every customer relationship into another development project.
The requests themselves are ordinary. The original system, however, may have no way to handle them without code changes. Perhaps device credentials are created manually, access permissions are tied to a fixed organisational structure, or alert rules are embedded in application logic. The first operator never needed anything else, so there was little reason to question those decisions.
The team can accommodate the differences. Engineers add another protocol adapter, adjust permissions, and modify the alerting workflow. But the third customer may bring a different warehouse management system, and the fourth may need separate access for its transport partners. What began as a few reasonable exceptions gradually becomes a collection of customer-specific code, configurations, and deployment procedures.
Those customer-by-customer changes stay with the team after launch. When a bug is fixed or a new feature is released, the team must account for differences between customer environments. Support engineers need to know which configuration or software version each client uses. Even routine changes can require additional testing and coordination.
The warning sign is the amount of engineering involvement required for each new account. If adding a customer means copying an existing deployment and then modifying it until it fits, the company is still largely delivering projects. To change that pattern, the team needs to identify which parts of the system should become reusable product capabilities before those differences multiply.
These common functions should work through established processes rather than being recreated for each deployment. A new customer organisation needs its own users, devices, data, and access boundaries. Equipment should follow a consistent provisioning process, with credentials and ownership recorded from the start. Firmware updates, configuration changes, and troubleshooting also need to work across customer fleets without requiring separate maintenance procedures.
A reusable foundation for multi-tenant device management helps bring these operations into a common model. Customer onboarding, tenant isolation, and device lifecycle management can be handled through established platform capabilities instead of custom implementation work. This is particularly useful when clients have different organisational hierarchies or involve external partners who need restricted access to certain equipment.
Building every one of these capabilities specifically for a new SaaS product is possible, but it also means taking responsibility for developing and maintaining functions that are largely independent of the product's competitive advantage. Starting with prebuilt IoT modules allows a team to concentrate more of its engineering effort on the workflows, integrations, and customer experience that distinguish its service.
Reusability does not mean that every customer must share the same physical infrastructure. Some organisations may need dedicated environments because of security policies, contractual requirements, or operational constraints. What matters is whether those environments can be provisioned, configured, monitored, and updated through a repeatable delivery model.
Many of these differences belong in configuration rather than application code. Temperature limits, notification recipients, user permissions, and reporting schedules can be defined per customer while the underlying mechanisms remain unchanged. The product supports different operating practices without maintaining a separate implementation for each one.
Other requests call for extensions. If a customer needs to exchange shipment data with a particular transport management system, the team might develop an integration adapter that becomes available to other customers. A new reporting capability could follow the same approach. The initial request comes from one organisation, but the resulting functionality becomes part of a product that serves many.
Some requirements will still justify bespoke development. The important question is whether a requested change belongs in the shared product, can be isolated as an extension, or should remain outside the standard offering. That decision involves more than technical feasibility. The team must consider likely demand, maintenance costs, and the effect on its roadmap.
Configuration itself also needs limits. An application with hundreds of interdependent settings can become nearly as difficult to maintain as multiple custom deployments. The aim is to support meaningful customer differences through a manageable set of options, rather than make every aspect of the software independently adjustable.
For the cold-chain platform, that process might involve creating a customer account, assigning administrators, registering equipment, selecting alert templates, and connecting any required external systems. Some steps may still require assistance, particularly where physical devices are involved. A useful test is whether an implementation specialist can onboard the next operator using a documented procedure without developers modifying the application or relying on undocumented workarounds.
AWS makes this distinction explicit in its SaaS design principles, recommending a single, repeatable tenant onboarding process and tenant-aware operations. The same guidance recognises that customers may have different isolation requirements and service expectations without needing entirely separate product versions.
Billing introduces its own operational questions. Subscription plans, service tiers, usage limits, and feature entitlements need to correspond to capabilities the product can actually deliver. If a customer upgrades to more advanced reporting or adds another operating region, the change should ideally be handled through established account and configuration procedures rather than a new development request.
After launch, support engineers need to identify which tenant owns an affected device, inspect its configuration, review relevant events, and distinguish customer-specific problems from platform-wide incidents. Updates should also follow a controlled release process, with enough consistency across deployments to avoid maintaining several incompatible versions.
Each extra onboarding step, support exception, or customer-specific release adds to the cost of serving that customer. Revenue may increase with each new subscription, but profitability depends partly on how much onboarding, support, and maintenance effort accompanies that growth. A product that can accommodate additional customers without continuously expanding its implementation workload has a much stronger basis for sustainable growth.
The team assumes it now has a product to sell. Yet the first prospective customer asks how its contractors will access vehicle data, who will configure new sensors, and whether its own incident procedures can be supported. The requests are reasonable, but answering them means reopening decisions made for the first client. A second deployment is beginning to look almost as labour-intensive as the first.
A successful IoT project is not automatically a SaaS product
An individual IoT deployment is built against a known set of requirements. Devices need to connect reliably, data must reach the right people, and workflows have to match the customer's operations. Meeting those requirements can involve sensible shortcuts: a dedicated integration, manually configured accounts, or rules designed around one team's processes. None of that prevents the project from being a success.A SaaS product has a different obligation. It must serve organisations that were not involved in its original design without forcing the team to develop, update, and support a separate version for each customer. A founder may see five new contracts as growth; the engineering team may see five separate implementations. The gap between those perspectives can become expensive long before the customer base looks particularly large.
Moving the application to the cloud and charging a subscription will not resolve the problem. Productisation requires deciding which capabilities should be shared, which customer differences can be handled through configuration, and which requests justify individual development. Those decisions shape the roadmap and determine how much additional work comes with every new sale.
For the cold-chain team, the first deployment proves that its software solves a real operational problem. It has yet to establish whether the same value can be delivered repeatedly without turning every customer relationship into another development project.
The second customer exposes the first product decisions
The next logistics operator has a different setup. Some refrigerated vehicles belong to contractors, warehouses use sensors from several manufacturers, and regional managers should only see shipments they are responsible for. Temperature alerts also need to reach different people depending on the cargo, route, and time of day.The requests themselves are ordinary. The original system, however, may have no way to handle them without code changes. Perhaps device credentials are created manually, access permissions are tied to a fixed organisational structure, or alert rules are embedded in application logic. The first operator never needed anything else, so there was little reason to question those decisions.
The team can accommodate the differences. Engineers add another protocol adapter, adjust permissions, and modify the alerting workflow. But the third customer may bring a different warehouse management system, and the fourth may need separate access for its transport partners. What began as a few reasonable exceptions gradually becomes a collection of customer-specific code, configurations, and deployment procedures.
Those customer-by-customer changes stay with the team after launch. When a bug is fixed or a new feature is released, the team must account for differences between customer environments. Support engineers need to know which configuration or software version each client uses. Even routine changes can require additional testing and coordination.
The warning sign is the amount of engineering involvement required for each new account. If adding a customer means copying an existing deployment and then modifying it until it fits, the company is still largely delivering projects. To change that pattern, the team needs to identify which parts of the system should become reusable product capabilities before those differences multiply.
What should become reusable before the next customer arrives
The first priority is to separate functions that every customer needs from the features that make the product valuable in its particular market. For a cold-chain monitoring service, the differentiating features might include shipment tracking, temperature compliance rules, exception reporting, and integrations with logistics systems. But creating customer accounts, connecting devices, assigning permissions, and maintaining equipment are recurring requirements regardless of the operator.These common functions should work through established processes rather than being recreated for each deployment. A new customer organisation needs its own users, devices, data, and access boundaries. Equipment should follow a consistent provisioning process, with credentials and ownership recorded from the start. Firmware updates, configuration changes, and troubleshooting also need to work across customer fleets without requiring separate maintenance procedures.
A reusable foundation for multi-tenant device management helps bring these operations into a common model. Customer onboarding, tenant isolation, and device lifecycle management can be handled through established platform capabilities instead of custom implementation work. This is particularly useful when clients have different organisational hierarchies or involve external partners who need restricted access to certain equipment.
Building every one of these capabilities specifically for a new SaaS product is possible, but it also means taking responsibility for developing and maintaining functions that are largely independent of the product's competitive advantage. Starting with prebuilt IoT modules allows a team to concentrate more of its engineering effort on the workflows, integrations, and customer experience that distinguish its service.
Reusability does not mean that every customer must share the same physical infrastructure. Some organisations may need dedicated environments because of security policies, contractual requirements, or operational constraints. What matters is whether those environments can be provisioned, configured, monitored, and updated through a repeatable delivery model.
Keep the product configurable without turning it into custom software
One logistics operator may need alerts based on strict temperature thresholds, while another uses different rules for pharmaceuticals, frozen food, and fresh produce. Their reporting requirements and escalation procedures may differ just as much as their equipment.Many of these differences belong in configuration rather than application code. Temperature limits, notification recipients, user permissions, and reporting schedules can be defined per customer while the underlying mechanisms remain unchanged. The product supports different operating practices without maintaining a separate implementation for each one.
Other requests call for extensions. If a customer needs to exchange shipment data with a particular transport management system, the team might develop an integration adapter that becomes available to other customers. A new reporting capability could follow the same approach. The initial request comes from one organisation, but the resulting functionality becomes part of a product that serves many.
Some requirements will still justify bespoke development. The important question is whether a requested change belongs in the shared product, can be isolated as an extension, or should remain outside the standard offering. That decision involves more than technical feasibility. The team must consider likely demand, maintenance costs, and the effect on its roadmap.
Configuration itself also needs limits. An application with hundreds of interdependent settings can become nearly as difficult to maintain as multiple custom deployments. The aim is to support meaningful customer differences through a manageable set of options, rather than make every aspect of the software independently adjustable.
Make onboarding, billing and support part of the product model
Reusable software solves only part of the delivery problem. The team also needs a consistent path from a signed contract to a working service.For the cold-chain platform, that process might involve creating a customer account, assigning administrators, registering equipment, selecting alert templates, and connecting any required external systems. Some steps may still require assistance, particularly where physical devices are involved. A useful test is whether an implementation specialist can onboard the next operator using a documented procedure without developers modifying the application or relying on undocumented workarounds.
AWS makes this distinction explicit in its SaaS design principles, recommending a single, repeatable tenant onboarding process and tenant-aware operations. The same guidance recognises that customers may have different isolation requirements and service expectations without needing entirely separate product versions.
Billing introduces its own operational questions. Subscription plans, service tiers, usage limits, and feature entitlements need to correspond to capabilities the product can actually deliver. If a customer upgrades to more advanced reporting or adds another operating region, the change should ideally be handled through established account and configuration procedures rather than a new development request.
After launch, support engineers need to identify which tenant owns an affected device, inspect its configuration, review relevant events, and distinguish customer-specific problems from platform-wide incidents. Updates should also follow a controlled release process, with enough consistency across deployments to avoid maintaining several incompatible versions.
Each extra onboarding step, support exception, or customer-specific release adds to the cost of serving that customer. Revenue may increase with each new subscription, but profitability depends partly on how much onboarding, support, and maintenance effort accompanies that growth. A product that can accommodate additional customers without continuously expanding its implementation workload has a much stronger basis for sustainable growth.
IndianWeb2.com is an independent digital media platform for business, entrepreneurship, science, technology, startups, gadgets and climate change news & reviews.
