On-Device AI, Not AI Slop: Insights That Never Leave Your Phone
There are two kinds of AI in software: the kind that does a specific job and the kind bolted on to raise a valuation. The difference is architectural. Here is how we build the first kind.
There are two kinds of AI in software right now. One does a specific job and gets out of your way. The other is a feature badge bolted on to raise a valuation — a chatbot nobody asked for, a "summary" that paraphrases what you already wrote, a model quietly trained on your data. We build the first kind. On-device AI insights, like the budgeting analysis in nint, are a clear example of AI done the right way — and the difference is architectural, not cosmetic.
What "AI slop" actually is
Slop is not "AI I don't like." It has a shape:
The tell is simple: remove the AI and ask whether the user is worse off. If the honest answer is "no, they're relieved," it was slop.
- It exists to be marketed, not to remove work. The feature's real job is the "AI-powered" label.
- It sends your data somewhere to earn its answer, often to a model that trains on it.
- It generates plausible filler instead of a verifiable result.
- It is bolted on after the fact, disconnected from the actual job the product does.
On-device AI: the job comes first
The alternative starts from the job, not the model. In nint, the job is: tell you something useful about your spending without your financial data ever leaving your phone. That constraint — never leave the phone — is what forces the right design.
Inference runs locally, on CoreML
The model runs on-device through CoreML, using the hardware already in your phone. Your transactions are analyzed where they already live, in the local-first store, decrypted only in memory on your own device. No request to a server. No data to harvest. The insight is computed next to the data instead of shipping the data to the compute.
Scoped to a real question
On-device inference has a budget — memory, battery, latency. That is a feature, not a limitation: it keeps the AI honest. You cannot afford a giant general model doing vague "magic," so you ship a small model answering a specific question — "is this month's dining trend going to blow the budget?" — and it answers fast, every time, offline.
Nothing is harvested to train
Because inference is local, there is no training pipeline fed by your data. We do not have your transactions to train on even if we wanted to — the architecture makes it impossible, which is exactly the point. Privacy-preserving AI is not a setting you toggle; it is a consequence of running the model where the data already is.
"On-device" is not a downgrade
The common assumption is that local models are the weak version of real cloud AI. For scoped jobs, the opposite is true:
The cloud wins when a job genuinely needs a frontier model. A huge share of useful product AI does not — it needs a focused model close to the data, and that is precisely where on-device shines.
- Latency: no network round trip, so insights are instant and work on a plane.
- Privacy: the data never moves, so there is nothing to leak and nothing to harvest.
- Reliability: no dependency on an API staying up or a rate limit staying generous.
- Cost: no per-token bill, so the feature can be generous instead of metered.
The stance, in code
"AI the right way" is easy to say and easy to fake. The way to prove it is to make the privacy claim structural: run inference on-device so the data physically cannot be harvested, scope the model to a real job so it earns its place, and delete the feature in your head — if the user is relieved, don't ship it.
That is the bar every AI feature we build has to clear. You can see it working in nint's on-device budgeting insights — AI that does one useful thing, on your terms, without your data ever leaving your device.
