Notes from the workshop.

A prototype answers one question cheaply. Not ten questions — one. The teams who waste money on prototypes are the ones who treat them as a rough draft of the whole product; the teams who benefit treat them as an experiment with a pass/fail answer.

Prototype when the question is expensive to get wrong: will farmers carry this device every day? Will customers trust a face-verification step? Will the sensor survive the rain? Those questions cost little to test and a fortune to guess.

Skip the prototype when the question is already answered — a marketing site, a CRUD platform, anything where the risk is execution rather than discovery. There, the fastest path is simply to build it well.

Our rule from three years of field work: if a wrong assumption would cost more than the prototype, build the prototype. That is the whole decision.

The honest trade-off is distribution versus capability. A web app reaches anyone with a browser — no store review, no install friction, one codebase. A native app reaches the phone's hardware: GPS in the background, the camera, offline storage, push notifications that actually arrive.

Ask the question most teams skip: where is your user when they use this? A logistics dashboard is used at a desk — build web. A bag-recovery tool is used in a panic, on the street, maybe offline — that wants native.

Kenya-specific reality: data costs matter. A web app that streams 2 MB on every visit loses to a native app that syncs once over Wi-Fi. If your users are on metered connections, weight that heavily.

And the middle path is real: many of our builds start as a solid web app, then add a thin native wrapper only for the two or three features that truly need hardware access. You don't have to choose everything on day one — you just have to choose deliberately.

The device is the cheapest part. This surprises everyone the first time. The build gets the headlines; the run eats the budget.

The recurring costs, from our own deployments: connectivity (SIM and data for every unit, every month), power (solar kits and battery replacements in the field), physical failure (housing cracks, connectors corrode — plan for a percentage of units dying per year), and the dashboard itself (hosting, updates, and someone who answers when it goes down).

A rough planning rule from running sensors in real conditions: budget roughly the cost of the device again, every year, to keep it running. If that number breaks the business case, the business case was never real.

Which is why we push clients to prototype with maintenance in mind from the start: pick components you can actually source locally, design the housing for the weather it will meet, and build the dashboard so one person can monitor a hundred units — not ten.