A connected product can look finished long before the engineering around it is complete. The prototype is stable, data reaches the cloud, the app shows the right values, and the first batch of devices is already in users’ hands. At that point, the backend may still be simple enough that the team knows almost every device individually. Provisioning can be handled with a script, configuration changes can be made manually, and if something fails, an engineer can usually trace the problem directly.
Then it has to start living in the real world. A second hardware revision appears. Some customers are still using the first revision. Firmware versions begin to diverge. A new configuration is needed for a different customer or market, while older devices still need updates and support.
Nothing is necessarily broken. The software behind the device has simply acquired a lifecycle of its own.
That transition is easy to miss because the prototype can continue working perfectly well. But once multiple versions of the same physical product have to coexist in the field, the backend is no longer just infrastructure behind the hardware. It becomes part of the product architecture itself.
A working connected prototype is not yet a scalable product
A prototype has an important job: prove that the system works end to end. The device performs its core function, firmware communicates with the backend, telemetry arrives where it should, commands make the return trip, and a mobile or web interface exposes the functionality to a user.
What it usually has not proved is how well the same system handles variety.
The first twenty devices may all run the same firmware, be built to the same hardware revision, and be configured by the same engineers. At that stage, manual registration, direct configuration changes, or a small onboarding script can be entirely sensible. Building production-grade tooling before the product has proved itself may be premature.
Scale changes the problem. Devices stay offline, get replaced, run different firmware, and require different customer configurations. Support has to distinguish a unit that was never provisioned correctly from one that is misconfigured or simply unreachable.
Prototype debt often starts this way: not with a bad decision, but with a temporary one that remains in place after the product has moved on. And one of the first things that forces that transition into view is the hardware itself. A new revision does not simply replace the old one; it has to coexist with it.
Every hardware revision creates a software lifecycle problem
A new hardware revision rarely arrives as a clean replacement for the old one. In practice, both versions remain in the field, sometimes for years. Add a transition batch, a few firmware branches, and customer-specific configurations, and the fleet quickly becomes more diverse than the original product model suggests.
The software layer can no longer treat every unit as an abstract “device.” It needs to know what that particular unit is capable of doing.
A revised board may use a different sensor, communication module, or controller. A command that is valid for the latest version may not be supported by an earlier one. Calibration values can change. Configuration limits can shift. A firmware package suitable for one generation may be unsafe for another.
Physical product engineers already work this way. Two components that look almost identical are not interchangeable if their revisions, tolerances, or specifications differ. Connected products create the same problem on the software side: the platform needs a reliable way to understand which version of the physical product it is talking to and what rules apply to it.
Consider a product whose first revision uses one calibration procedure while the second introduces a new sensor and a different set of parameters. To the customer, both units may still be the same product. To the platform, they cannot be.
If those differences are not represented explicitly, they tend to leak into application logic as special cases. One workflow checks a serial-number range. Another uses a firmware version as a proxy for hardware generation. A third contains an exception added after support discovered an older batch behaving differently in the field. None of these fixes looks especially dangerous on its own, but together they make every future change harder to reason about.
Older hardware rarely disappears on schedule. Product teams naturally focus on the newest revision, while customers often keep earlier versions much longer than expected. The platform therefore has to support several generations at once rather than assuming the installed base will ever converge on a single current state.
Once that happens, hardware evolution and software lifecycle management become inseparable. The platform needs to know not only where a device is and whether it is online, but what it is, what it can run, how it should be configured, and which changes are safe to apply.
And before any of those questions can be answered reliably, each device has to enter the system in a consistent way.
Provisioning is where manual engineering stops scaling
Provisioning looks simple when the fleet is small: create a device record, enter a serial number, generate credentials, assign the unit to a customer, apply a configuration, and move on. For a few dozen devices, handling some of this manually may still be the right choice.
At production scale, however, provisioning sits at the intersection of device identity, credentials, ownership, configuration, and lifecycle state. A mistake made during onboarding can affect how the unit is operated and supported long after it leaves the factory.
A spreadsheet may no longer match what is actually installed. A replacement device needs the right customer association without inheriting the wrong identity. Factory resets create another path through the process. An installer can assign a unit to the wrong account, leaving support to determine whether it is offline, incorrectly provisioned, or simply carrying the wrong configuration.
Once answering those questions routinely requires a developer to inspect a database or run an internal script, the process has stopped scaling with the product.
Duplication is another warning sign. Each product variant starts acquiring its own onboarding script, configuration tool, or installer workflow. Those differences may look small, but the underlying responsibility is the same. Provisioning has become reusable platform infrastructure rather than a setup task attached to a particular device.
And it is rarely the only capability that needs to become reusable.
The platform layer should become reusable infrastructure
Once several products or hardware revisions share the same basic needs, some software capabilities stop being product-specific. Device identity, provisioning, connectivity, telemetry, firmware delivery, lifecycle state, fleet visibility, and diagnostics are good examples. Rebuilding them for every new variant creates more code and more operational paths to maintain without making the product itself any more distinctive.
Teams rarely set out to create this duplication. Small differences accumulate around each product until the team is maintaining several implementations of what has become the same engineering responsibility.
A cleaner boundary is to separate the product layer from the platform layer. The product layer contains the behavior, workflows, interfaces, integrations, and domain logic that make a particular device valuable. The platform layer handles mechanics that should remain consistent even as the hardware changes.
As connected products move beyond their first release, device provisioning, device lifecycle management, fleet management, and support tooling become shared infrastructure rather than one-off project details. An IoT PaaS for enterprises can provide that reusable platform layer across multiple products or product variants, handling standard device and data management through reusable building blocks while engineering teams keep their custom effort focused on hardware, workflows, and user experience.
A common foundation still has to leave room for real product differences. A new device may need a different data model, configuration flow, integration, or control logic, and those differences should remain easy to introduce. The goal is simply to avoid making every difference drag along another device registry, telemetry pipeline, provisioning mechanism, or set of fleet-management tools.
The platform may look like overhead while the team is building the first product and like an asset by the second or third. Once the common operational mechanics are in place, a new variant can inherit a working foundation instead of arriving with another backend that the team will have to maintain for the rest of that product’s life.
Keep custom engineering where the product is actually different
A reusable platform should not make connected products more generic. Its job is to remove repeated engineering from the parts that do not create differentiation.
Custom effort still belongs in device behavior, domain-specific logic, workflows, user experience, specialized integrations, and the way a particular product interacts with the physical world. Those are exactly the areas where engineering choices can make one product meaningfully better than another.
What rarely deserves the same treatment is the surrounding operational plumbing. A basic version and an industrial version of the same machine may need different sensors, controls, and interfaces, but they should not require separate ways to identify devices, track firmware versions, or manage a fleet.
I would rather see engineers spend that time refining how the product behaves in the field than rebuilding mechanics the team already has in place for another product. A shared foundation does not reduce the scope for custom engineering; it protects that effort from being consumed by infrastructure.
The real test comes when the team starts product number two.
A good platform makes the next product easier than the first
If product number two requires almost the same platform work as product number one, very little has actually been reused.
A new variant should be able to inherit the parts of the operating model that have not changed: provisioning flows, identity, lifecycle mechanics, fleet tools, firmware processes, support visibility, and common integrations. Engineering effort then goes into the differences — perhaps a new sensor package, another control workflow, or a customer-specific integration — instead of reconstructing the foundation.
A new hardware generation puts the same idea under more pressure. Its capabilities may change substantially while older units remain active in the field. A mature platform can support both without forcing the team to maintain two separate platform stacks for what customers still perceive as one product family.
None of this requires one monolithic backend. Different products may still need clear architectural boundaries. What matters is avoiding a second implementation of the same engineering responsibility without a good reason.
That is when the platform becomes an asset rather than accumulated overhead. Support has fewer parallel tools to understand, releases follow more consistent paths, and adding another product becomes a controlled extension instead of another backend the company inherits indefinitely.
Treat the platform as part of the product architecture
Physical products are designed with revisions, serviceability, manufacturability, and future changes in mind. Connected products need the same discipline on the software side.
The first backend can be temporary. So can the first provisioning script or support tool. There is nothing inherently wrong with that. Problems begin when those temporary mechanics quietly become permanent architecture while the product itself continues to evolve.
By then, the connected product is no longer just hardware, firmware, and an app. It also depends on the infrastructure that identifies each device, understands its capabilities, applies the right configuration, supports updates, and helps teams diagnose problems years after shipment.
Once that layer is treated as product architecture, the division becomes clearer: standard mechanics stay reusable, while custom work goes into what actually distinguishes one product or product family from another.
The strongest platform is not simply the one that makes the first connected product possible. It is the one that lets the engineering team build the second, third, and fourth without inheriting a new backend every time.
