Capability · Local AI
AI that runs on the device.
We design and build on-device AI products: language models running on phones and laptops, and agents that work on your own hardware. Not demos: shipped products with users on them.
01 Why on-device
The cloud is a choice, not a default.
-
01
Privacy as architecture
When inference happens on the device, "we don't see your data" is a fact about the system, not a promise in a policy. For health, legal, HR and anything involving children, that difference is the product.
-
02
Latency you can feel
No round-trip means responses limited by silicon, not by someone's network. For voice, vision and robotics, the difference between 40ms and 400ms is the difference between working and not.
-
03
Unit economics that scale
Per-token API pricing turns success into a cost problem: the more users, the bigger the bill. Inference on the user's own hardware costs you nothing at the margin. Some products are only viable this way.
-
04
Works with no network
Classrooms, factory floors, planes, markets with unreliable connectivity, or China, where the cloud APIs you'd default to simply aren't there. On-device AI keeps working.
02 Shipped
Five products, all local.
03 The honest part
On-device is an engineering discipline, not a checkbox.
Anyone can call an API. Local AI means living inside real constraints, and knowing which product ideas survive them. This is most of what you're hiring when you hire us.
-
01
Model selection is product design
The model that fits in a phone's memory budget is not the one from the benchmarks. Choosing what to run, and what to cut so the experience still feels smart, is the core decision, made early and tested on real hardware.
-
02
Memory, thermals, battery
Quantization, context limits, thermal throttling on long sessions, battery drain users will actually notice. We prototype on the worst device you intend to support, not the best one on your desk.
-
03
Hybrid when it's honest
Some workloads genuinely need a bigger model. When that's true we say so, and design the split so the sensitive path stays local and the cloud part is a choice the user understands.
-
04
Shipping is the hard part
App-store review with bundled model weights, download size, update strategy for new models, graceful behaviour on older devices. Products die on these details; ours haven't.
04 Working with us
Scoped around your problem.
-
01
Feasibility first
Before anything is built: can your use case run on your users' actual hardware, at quality worth shipping? We answer that with a working spike on a real device, not a slide.
-
02
Senior people build it
The people who scoped the work design and write it. Small team, end-to-end responsibility: model, app, infrastructure and the path to the store.
-
03
Custom engagement
No packages. A local-AI feature inside an existing app, a full product from scratch, or rescuing a prototype that works in the demo and dies on real hardware. Each is scoped on its own.
Building something that shouldn't need the cloud?
Tell us what it is and what hardware it has to run on. You'll get a real answer from the people who'd build it, including "that won't fit on-device yet" if that's the truth.