Edge Computing Use Cases for Product Leaders

By the time most companies realize they have an edge computing problem, they have already built something that assumes they do not.

The architecture is cloud-first. The latency assumptions are baked in. The data flows are designed around connectivity. Then a constraint arrives: a regulation, a customer requirement, a safety threshold, a data volume the network cannot absorb. And the question that should have been asked at the start of the product brief is now being asked during a retrofit that nobody budgeted for.

The companies getting this right are not the ones with the most sophisticated infrastructure. They are the ones where the product team asks the hard question early, before the architecture is set, before the budget is committed, and before the retrofit becomes the only option left. Because edge computing is, at its core, a product decision. One that belongs in the brief, not the architecture review.

The constraint is always there. The question is when you find it.

In manufacturing, the constraint is unmissable. A vision system inspecting components on a conveyor belt has milliseconds to detect a fault and stop the line. There is no time to send data to a server and wait. Either the processing happens locally, or the product does not work. The constraint is physical, immediate, and non-negotiable.

That clarity is brutal, but it is also useful. It forces the right question early: where does this decision need to happen? Not as an architecture preference, but as a product requirement. Manufacturing teams did not arrive at edge computing because they were visionaries. They arrived there because the alternative was a system that did not work.

The same constraint exists in predictive maintenance, quality inspection, and operator safety systems. In every case, the boundary between local and cloud processing was defined by the consequence of getting it wrong, not by a technology roadmap.

Most software product teams never feel that consequence until it is too late. So they defer the question. And deferring it is where the cost begins.

In vehicles, the industry learned to ask the question first.

Automotive learned this the hard way and at scale. A modern vehicle generates continuous data from cameras, radar, and sensors. The decisions that depend on that data, lane control, driver monitoring, collision response, have consequences measured in fractions of a second. A network round trip is not a latency inconvenience. It is a safety failure.

What the automotive industry understood, and built its entire software-defined vehicle strategy around, is that the boundary between what runs on the vehicle and what runs in the cloud is a product decision with safety, regulatory, and commercial implications. It cannot be delegated to an infrastructure team after the product has been scoped.

Where you draw that line determines what the vehicle can do without connectivity. It determines how behaviour is updated over time. It determines what happens when local and cloud systems need to stay consistent. These are product questions. They require the product organization to define, in advance, which capabilities are critical, which can degrade gracefully, and which can wait for a connection.

As Pratap Jujjavarapu, Associate Vice President of Engineering at Robosoft, puts it:

The business reality first. The architecture second. That is the order that works. It is also the order most teams get backwards.

Mobile is where the deferred question is most expensive.

Consumer mobile is the category where the cost of deferring this question is hardest to see, which is precisely why it is so common.

On-device processing has become standard. Camera apps run segmentation and background replacement locally. Image processors handle scene detection on the chip. Video applications push live filters to the device. This happened not because product teams made a principled decision, but because users noticed when it was slow, and because data leaving the device started carrying consequences nobody had planned for.

That second point is where the real cost lives.

When inference runs on the device, sensitive user data, faces, voices, biometric signals, does not transit a network. For a product team, that is not a privacy feature. It is a business decision that removes a significant category of risk and infrastructure cost. You are not building systems to handle sensitive data securely in transit. You are not carrying the compliance overhead of transmitting health or biometric information across jurisdictions. You are not exposed to the liability of a breach involving that category of data.

Some products have recognised this and made it a deliberate part of their architecture. Most have not. They are running cloud-first processing on data that should never have left the device, carrying risk and cost that a single question in the product brief could have prevented.

The question "where does this data need to live, and what happens if it moves?" should be standard in every mobile product brief. It is rarely asked at all.

Four questions that belong in the brief, not the architecture review.

These are not technical questions. They are product questions. They should be answered before an architecture conversation begins, because the answers define what the architecture needs to do.

1. What does a delayed decision actually cost?

Name it specifically, in your product, in the moment it occurs. A few hundred milliseconds is invisible in a checkout flow. In a vehicle it is a safety event. In a factory it is a defective batch. In a consumer app it is the moment the experience breaks and the user notices. If you cannot name the consequence, the latency requirement may not be as hard as it appears, and you may not need edge at all.

2. Does this need to work without a connection?

If your product must function independently of connectivity, that is a product requirement, not a technical assumption. A factory line that stops every time the network drops is not viable. A vehicle that loses a safety-relevant capability in a tunnel is not acceptable. This constraint belongs in the brief, defined by the product team, before it becomes an architecture problem.

3. Where does the data need to live?

Regulation, customer contracts, and competitive sensitivity often answer this before any technical conversation. If production data cannot leave a facility, processing has to happen inside it. If biometric inference cannot transit a network, it has to run on the device. These are not architecture preferences. They are constraints. The product team needs to own them.

4. Can you afford to move this data?

A high-resolution sensor array can generate more data per hour than it is economical to upload continuously. At that point, processing at the point of collection is not a strategy. It is the only option the economics allow. If your data volumes exceed what your network and cloud budget can absorb, the decision has already been made. It just needs to be named.

If two or more of these have a hard answer, edge belongs in your architecture. If none do, the pressure to include it is coming from somewhere other than the product requirements, and that is worth questioning.

The boundary moves. The habit should not.

The line between what runs locally and what runs in the cloud is not fixed. Models get smaller. Hardware gets cheaper. Connectivity improves and, in some markets, deteriorates. What required local processing two years ago may be viable in the cloud today. What runs comfortably in the cloud today may need to move as privacy expectations tighten or data volumes grow.

Products that treat this as a settled architecture question get caught out when the environment shifts. Products that treat it as an ongoing product question, one that gets revisited as constraints change, stay ahead of it.

That is what edge computing actually demands. Not a technology choice made once. A product discipline applied continuously.

If your team is working through where this boundary sits, whether in manufacturing, automotive, mobile, or another product context entirely, this is the conversation Robosoft has with engineering and product leaders every day. We would be glad to have a chat.