All services

The data never leaves the machine.

Some data cannot go to a provider, and some products cannot depend on a network round trip. Running the model on the device solves both, and introduces its own problems: quantization without wrecking quality, memory budgets on hardware you do not control, and shipping a model inside a signed, notarized build. We have done this in production, including transcription clean enough to sync straight to a CRM.

On-device
Live-meeting detection
55%80%
Plans completed without a human
18%10%
Transcription error rate

Built for production, not the demo.

01 / ON_DEVICE

Models running locally, for data that cannot leave the machine.

For data that cannot leave the machine. Quantized models inside signed desktop builds, with the latency and memory work that makes them usable.

Usually shipped with

  • PII redaction and data boundaries
  • AI product engineering
  • Self-hosted model deployment

Not a bundle to buy. Whichever you start from, the engagement covers what the build actually needs.

02 / Scope

What we build.

  • Quantization tuned to hold quality at the size the device allows
  • Models embedded in signed, notarized desktop builds
  • Memory and latency budgets set against real target hardware
  • Hybrid local and cloud routing where only some data is sensitive
  • Update paths for a model that ships inside an application

03 / Outcomes

What you can ship.

  • Products that work with no data leaving the device
  • Latency with no network round trip
  • Deployments in environments that forbid external calls

04 / Deliverables

Artefacts, not activities.

  • The embedded modelQuantized to your hardware budget, inside a signed, notarized build.
  • Quality measurementsPer-quantization-level scores against your eval set, so the trade is documented.
  • The update pathHow a model version ships to installed applications without a full reinstall.

05 / Stack

What it is built on.

Runtimes
llama.cpp / ONNX Runtime / Core ML
Quantization
GGUF / INT8/INT4
Packaging
Signed builds / Notarization / Auto-update
Platforms
macOS / Windows / Edge devices

06 / Why us

We have shipped this, not benchmarked it

On AnyTeam the transcription runs entirely on the rep's laptop and is clean enough to sync straight to a CRM. On-device work fails on packaging and thermals far more often than on model quality.

Quantization measured, not assumed

A quantized model that lost ten percent on your task is a bug you will find in production. We measure against your eval set at each size before choosing.

Signed and notarized is part of the job

Shipping a model inside a desktop application is a distribution problem as much as an ML one, and it is where most on-device projects stall.

A path from your problem to production.

  1. Week 1

    Set the hardware budget first

    Memory, thermal and latency limits on the machines your users actually have, not on a workstation. The budget decides the model, not the other way round.

  2. Week 1-3

    Quantize against an eval set

    Every size reduction costs quality somewhere. We measure where, so the trade is chosen rather than discovered after release.

  3. Week 3-5

    Ship it inside the build

    Embedded in a signed, notarized application, with the packaging and update path that implies.

  4. Week 4-6

    Decide the hybrid line

    Which requests stay local and which may go to a provider, and what happens when the network is gone.

The boundary is physical, so the update channel is the risk.

A capability check decides whether a device can run the model at all, and if it cannot it falls back to a smaller one rather than silently uploading the data — the failure that quietly defeats the entire point. The bundle is quantised and runs against a local store, and the answer never leaves. Updates travel the other way: a signed build whose origin can be proved, released to a staged cohort before the rest of the fleet. Telemetry is counts, not content, so you learn how the model behaved without learning what anyone asked it.

DATA THAT CANNOT LEAVEATTEST THE DEVICErooted ones get nothingCAN IT RUN THE MODEL?BUNDLEQUANTISEDINFERLOCAL STOREon the deviceGUARDRAILSchecked on the deviceAN ANSWER, LOCALLYSMALLER MODELnever a silent uploadSIGNED BUILDyou can prove its originSTAGED ROLLOUTa cohort, then the restTHE DEVICE EDGEnothing personal crossesCOUNTS, NOT CONTENTaggregate onlyWHAT CROSSES THE EDGEon device → counts → nothingWHAT THE FLEET REPORTS
Fine points of light scattered across a dark field

Production-proven

Built by engineers who've already shipped this in production.

The questions buyers actually ask.

Will a local model be good enough?

For narrow tasks, frequently yes, and the eval set answers it in the first fortnight rather than after the build. For open-ended reasoning, usually not, which is what the hybrid line is for.

What hardware do users need?

We set the budget against your actual install base. That constraint drives model choice, rather than picking a model and hoping.

How do model updates reach installed apps?

Through the update path we build, separate from application releases where that makes sense, so a model improvement does not require a full reinstall.

Can some requests still use a provider?

Yes, and that is usually the right design. Sensitive or offline requests stay local; the rest can route out when the network allows.

Let's scope your on-device and edge inference build.

Tell us where you are and what you're trying to ship. We'll come back with a concrete plan, the right engineers, and a path to production, not a generic pitch.