Most Connected Products Die Somewhere Between Ten Units and a Thousand

Almost everything except the feature list. A prototype is set up by the person who built it, on a known network, with a laptop nearby. A thousand units are set up by strangers, on routers you have never seen, in flats with thick walls and a mobile signal that comes and goes. So the work between the two is provisioning that recovers from failure, a way of identifying and claiming each unit that cannot be spoofed, update delivery that survives a power cut, monitoring that tells you a batch has gone quiet before the customers do, and a support tool that lets somebody on the phone see the state of one device. None of that is visible in a demo, which is why it is rarely in the original budget.

The Product Security and Telecommunications Infrastructure regime sets baseline security duties for consumer connectable products sold in the UK. In practice it means no universal default passwords, a published and monitored route for reporting security issues, and stating the minimum period for which the product will receive security updates, supported by a statement of compliance. Several of those duties land on the firmware and on your company as manufacturer rather than on the app, but they shape what we build: per-device credentials issued during provisioning rather than a shared password, an update channel that stays open for the period you declared, and a disclosure contact that reaches a real inbox. We build to it; your legal adviser confirms the obligations that apply to you.

With a separate tool, and it is worth budgeting for explicitly because the consumer app is the wrong shape for the job. Production provisioning is a bulk operation: an operator scans a code, the unit is issued its identity and credentials, a self-test runs, the result is recorded against the serial number, and the whole thing has to take seconds rather than minutes. It usually needs to work on a site with unreliable internet, which means queuing results locally and uploading later. We have seen more than one launch slip because the only way to prepare a unit was to walk it through the customer onboarding flow by hand.

It is driven almost entirely by how often each device speaks and how long you keep what it says. A sensor reporting every fifteen minutes and retaining a rolling year of readings is typically a few pence per device per month. The same device reporting every second is a different order of magnitude, because you are paying for ingestion, storage and the queries over all of it. The lever people forget is retention: full-resolution data for a fortnight and hourly averages after that will usually answer every question anyone actually asks whilst cutting the bill substantially. We model this during scoping so the running cost is a known number before you commit to a message rate.

That question is the reason we insist on agreeing the boundary in writing at the start. The cloud side records what it last heard and when, so the first diagnostic is always available: did the device stop sending, or did we stop receiving. From there we own everything from the radio upwards on our side of the line, the firmware team owns what happens on the device, and the customer broadband or mobile network owns the middle. In practice most silent devices turn out to be a changed router password or a unit that was unplugged, which is why we build a support view showing last contact, signal quality and firmware version before launch rather than after the first difficult week.