Cloud inference is the default because it is easy. It also means every interaction pays for a round trip to a server, every byte of user data travels to someone else’s computer, and the feature stops working when the connection does. For health signals, camera feeds and always-on assistants, that trade is often the wrong one.
What we do
We take a model, off the shelf or fine-tuned on your data, and engineer it onto the device it needs to run on: phones, wearables, embedded hardware. That means quantisation and distillation to fit the memory budget, optimisation for the specific chip, and the product engineering around the model that makes it dependable in people’s hands: caching, fallbacks and a safe update path.
Why on-device
Latency. No network round trip, so the feature responds immediately. That matters for anything that runs while the user is doing something else.
Privacy. The data never leaves the device. For health, camera and personal data, that is often the only acceptable design, and it simplifies your compliance story.
Reliability. The feature works in a basement, on a plane and in the field.
Cost. Inference on the user’s hardware has no per-request bill.
We run it on our own apps
Three of our own apps, MyDate, Breathr and Habit Builder, keep their data on the device and work without a connection. The habits that made those apps dependable are the ones we bring to client work.
Where this fits
Teams usually start smaller: an AI-native product build, then assistants and agents, then fine-tuned and on-device models as the product’s edge sharpens. You can start at any step.
Building a device, or exploring a hardware AI use case? Tell us about it. We reply within one working day.