What a working slice of an IoT product looks like after ten days

The most expensive sentence in product development is "we'll know once it's built". In a connected product it is doubly expensive, because the thing being built has a device, a radio, a cloud and an app in it, and a wrong assumption in any one of them is baked into the others by the time anyone notices. So before we build a product properly, we build a thin version of the whole thing, end to end, and we try to do it in days rather than months. We call it a working slice. This is what one looks like.

Real, not representative

A working slice is not a mock-up and not a demo. It has real firmware running on real hardware, usually a development board or a first-cut PCB, with the actual sensor or actuator the product will depend on. It has a live cloud: readings leave the device over the real radio, land in a real database, and can be queried. And it has a first screen, on the web or on a phone, that shows a real number that changed because something happened in the physical world.

Everything about it is thin. One device, not a fleet. One sensor, not six. One screen, not an app. But nothing about it is fake, and that is the point. A slide showing the product can be argued with for a month. A box on the table that reports its own state over the internet settles most of the arguments in an afternoon.

For the Woolworths sanitiser station, the slice was a single unit that counted sprays, measured how much liquid it had left and reported both to a screen. Everything that followed, from the store app to the fleet of more than 800 units, was a thickening of that first loop: a device that knows its own state, a cloud that records it, a screen that shows it to the person who needs to act.

What ten days buys you

The reason to do this first, before the proper build, is what you find out. Four things, usually.

You find out whether the sensor can measure what you need it to. Datasheets describe a sensor in a lab. A slice tells you how it behaves on a wall, in a cabinet, next to a motor, in the Highveld in January. More than one product idea has changed shape at this stage, and that is the cheapest possible moment for it to happen.

You find out what the data actually looks like. How often the device needs to report, how much of that is noise, what the cloud has to do to turn readings into something a person can act on. The data model you design from a real feed survives. The one you design from a whiteboard gets rewritten.

You find out what the person holding the phone cares about. Put a real screen in front of a store manager, an estate resident or a parking operator and they will tell you in a minute which number matters and which three you can delete. For Unimet, the question that mattered to a resident was not the meter reading at all. It was how many days of credit were left, and whether somebody would warn them before it ran out.

And you find out what it will cost. Not to the rand, but to the order of magnitude that lets you decide whether to continue, change course or stop. A slice that works makes the business case concrete. A slice that struggles has saved you the full build.

What we deliberately leave out

A slice is useful only if it stays thin, so we are strict about what does not go in. No enclosure design, beyond whatever keeps the board safe on a desk. No provisioning or over-the-air updates, because one device does not need a fleet manager. No authentication, roles or billing in the software. No polish on the screen: real data, plain layout. And no attempt to make the firmware power-efficient yet; that work matters later and would slow the slice down now.

The discipline is harder than it sounds. Every one of those things is a good idea, and every one of them turns a ten-day slice into a three-month project. The slice has one job, which is to answer the questions above as fast as possible. The proper build has the other job.

What you can decide once you are holding it

With a working slice on the table, a client can make the decisions that are otherwise made on faith. Whether the product is worth building at all. Which sensor, radio and board to commit to, with evidence rather than a datasheet. What the first real version must do and, just as valuable, what it must not. Roughly what it will cost and how long it will take. And whether this is the team to build it with, which is a fair thing to want to know before signing a larger contract.

The slice also becomes the spine of the real build. The data model, the device-to-cloud contract and the first screen all carry forward; they get thickened, hardened and tested, but rarely thrown away. That is why we can move from a brief to a prototype in days and from a prototype to production without starting over.

How to brief one

If you want a working slice of a product idea, we need three things from you. The one physical thing the product must sense or control. The one decision a person should be able to make because of it. And access to a realistic place to try it, even if that is a desk in your warehouse rather than a store. From there, ten days is usually enough to put something in your hands that reports its own state over the internet. Then we talk about what to build properly.

Send us a brief, or write to hello@handee.co.za.