Why we run the AI on your phone instead of ours

Every AI-powered inbox on the market works the same way. Your messages are uploaded to a server, a large model reads them there, and an answer comes back. It is the obvious architecture. It is also the one we refused to build.

Not because cloud inference is badly engineered; it isn't. Because of what it makes possible, and what it therefore makes you trust.

The problem with "we don't look at your messages"

When a company processes your conversations on its own hardware, its privacy promise is a policy. Policies are written by people, changed by people, and enforced by nobody in particular. A policy can be revised in a funding round, reinterpreted after an acquisition, or quietly overridden by a subpoena.

More practically: a policy cannot survive a breach. If the data is on a server, then a server compromise exposes it. Your only protection is that nobody made a mistake, ever, at a company you have never met.

The strongest privacy guarantee is not a promise not to look. It is not having the data.

That is the whole thesis. Everything else in Textly follows from it.

What "on-device" actually means here

The models that power search, summaries, suggested replies, scam detection and entity extraction are compiled into the application package. When you install Textly, you install them. When you ask a question, the computation happens on your phone's own processor, the same silicon that renders the screen.

There is no API key in the app because there is no endpoint to call. There is no fallback to a cloud model when the local one is uncertain. There is no "anonymised telemetry" carrying fragments of your text. The network permission exists for exactly one reason: talking to the messaging services you connected.

You do not have to take this on faith, which is the point. Turn on airplane mode and ask Textly a question about your inbox. If the answer arrives, nothing was uploaded. It is the rare privacy claim you can falsify in ten seconds.

What it cost us

Honesty requires listing the trade-offs, because there are real ones.

• Model size. A model that fits in a phone's memory budget is smaller than one running on a datacentre GPU. Ours is tuned narrowly for messaging rather than being generally clever.
• Speed on older hardware. Inference speed tracks your chipset. On a recent device answers feel immediate; on a four-year-old budget phone they do not.
• Slower iteration. Improving a cloud model means deploying. Improving ours means shipping an app update and waiting for people to install it.
• Battery and storage. Running models locally costs both. We spend a disproportionate amount of engineering time on making that cost small enough to ignore.

We think this is a good trade. You may reasonably disagree, but you should get to make that decision with the trade-offs stated, rather than discover them later.

The unexpected benefit

Something we did not anticipate: on-device processing unlocked a feature that cloud processing would have made unacceptable.

Textly notices commitments you make. When you write "I'll send it tonight," it keeps that promise visible until it is done. To do that, the app has to read your outgoing messages, continuously, across every channel.

Ask yourself whether you would enable that if the reading happened on someone else's server. We wouldn't either. Because it happens on your phone, the question does not arise.

Where this goes

The gap between what fits on a phone and what fits in a datacentre is closing faster than most people expect. Mobile chips ship with dedicated neural accelerators, and small models keep getting better at specific tasks.

We are betting that in a few years, "your data went to a server to be understood" will read the way "your password was stored in plain text" reads today: not evil, just obviously the wrong way to have built it.