When the decision cannot wait for the network
On-device inference is not a feature. For a lot of products it is the difference between working and not working.
"Edge computing" is usually sold as an optimisation — lower latency, lower bandwidth cost, better privacy. For a certain class of product it is none of those things. It is the difference between a product that works and a product that does not.
When the network is not a given
A great deal of connected-product design quietly assumes reliable connectivity, because it is designed in places that have it. Move the same product to a rural clinic, a basement plant room, a moving vehicle or a site in a country with patchy coverage, and the assumption fails.
If the product's core function depends on a round trip to a server, then in those conditions the product has no core function. It has a loading state.
The question to ask early
There is one question that settles the architecture, and it is worth asking in the first week rather than the sixth month: what must this product still do with no network at all?
The honest answer is often more than the team expected. A diagnostic instrument must still produce a reading. A controller must still hold the machine in a safe state. A tracker must still record, and send later. Once that list exists, it defines what has to run on the device — and everything else can legitimately live in the cloud.
What it costs
On-device processing is not free. It raises the specification of the processor, it raises power consumption, and it makes updates harder because the logic is now distributed across every unit in the field rather than sitting on one server.
That trade is worth making deliberately. The failure we see most often is not choosing the cloud — it is choosing the cloud by default, because the first prototype was built with a network cable plugged in.
Working on something like this?
We design and manufacture hardware end to end. The first call is with an engineer and costs nothing.
