Three vendors, one product, and the gaps between them

A sanitiser station on a wall in a busy store reports that its tank is empty. The store manager opens the app. The app says 40%. Somebody will have to refill the unit anyway, and somebody else will have to find out why two parts of the same product disagree. Here is who gets the call: the hardware shop that built the unit, who say the sensor is fine and the firmware must be misreading it; the firmware contractor, who says the reading left the device correctly and the cloud must be ingesting it wrong; and the app agency, who say, truthfully, that the app shows whatever the cloud gives it. Three invoices, one problem, no owner.

This is the normal way a connected product gets built, and it is why so many of them stall. The product is one system. The market that builds it is organised by discipline. You buy the hardware from a hardware company, the firmware from an embedded specialist, the cloud from a platform team and the app from an agency, and each of them is good at its own layer. The product lives in the joins between the layers, and nobody is paid to live there.

Where the gaps actually are

The gaps are not abstract. They are the same four, project after project.

The first is the data contract. The device sends a reading; the cloud expects a slightly different one. Units, timestamps, what happens when the device has been offline for an hour and has forty readings buffered, whether a missing value means zero or unknown. Each of these is decided twice, by two teams, and the decisions drift apart the moment the first document is out of date.

The second is the set of assumptions about power and connectivity. The app team builds for a device that is always on and always online, because that is how a phone behaves. The firmware team builds a device that sleeps to make a battery last a year and checks in every fifteen minutes, because that is how a field device survives. Both are right. The product is wrong.

The third is updates. A fix needs new firmware. Who ships it, who tests it against the current app, who decides which units get it first and what happens when a store's unit is halfway through the update when the shop opens? If three companies have to agree, the fix waits for a meeting.

The fourth is support. When a unit fails in the field at seven in the morning, the person who gets the call usually cannot see past their own layer. Finding the fault means a chain of emails across three companies, and the customer watches the chain.

What the gaps cost

None of this shows up in the quotes. Each vendor prices its own layer competently. The cost appears later, as the months of integration that nobody budgeted, as a launch that slips a quarter, and as a version one that works most of the time, which in a connected product means a version one nobody trusts.

The bigger cost is slower to notice. A product built across three vendors becomes very hard to change. Every improvement, however small, is a three-party negotiation: a change to the device needs a change to the cloud needs a change to the app, and each company has its own backlog and its own idea of the priority. The product you launched is roughly the product you are stuck with.

What changes when one team owns the whole thing

Handee builds the device, the firmware, the cloud and the web and mobile software as one team, and the difference is mostly about where decisions get made. There is one data model, owned end to end, so the question of what an offline device sends when it reconnects is answered once, by the people who wrote both sides. There is one backlog. The engineer who wrote the firmware sits in the same stand-up as the one who built the dashboard, and quite often is the same person. A disagreement between a sensor and a screen is fixed in an afternoon, because it is one team's bug.

We learned this the hard way, on our own first product. In 2020, five of us built a sanitiser station that knew how much was left in its tank, how many people it had served and when something was wrong, and we built the hardware, the cloud and the store app under lockdown with nobody to hand anything to. That station now runs in more than 800 units across 500 stores, unattended, and has counted over 100 million sprays. It would not have survived its first winter as a three-vendor product.

The same logic shaped Unimet, a prepaid wallet for a home's electricity and water on South African estates. Because the team that read the meter also built the app, the low-credit warning was designed where the data is produced, not bolted onto a screen afterwards. Residents get warned days ahead instead of finding out when the lights go off.

The honest caveat

One team is not automatically better. It only works if the team has real depth in every layer, which is rarer than the brochures suggest, and it concentrates your risk in one supplier. The remedies for that are not complicated: senior engineers on the hardware calls as well as the software ones, documentation produced alongside the code rather than written at the end, and a handover you could actually take if you ever needed to. We build all three into the way we work, and we would say so to any client who asked why they should put everything in one place.

One question to ask every vendor

If you are planning a connected product, ask every vendor you talk to the same question: when the sensor says one thing and the app says another, who fixes it? If the answer involves a meeting, you have found the gap before you have paid for it. Then either hire one team to own the whole product, or write the contracts so that one party, unambiguously, does.

We are happy to be asked the question ourselves. Send us a brief, or write to hello@handee.co.za.