Most AI apps today have a quiet, unspoken deal built into them: send us your conversations, your habits, your journal entries, and we'll process them somewhere in a data center you'll never see. You don't get to opt out of the deal — it's the deal.
I built BrainBox specifically to break that deal. It's a local-first AI lifestyle app — on-device chat, personas, habit and routine tracking, journaling — where the model runs on your phone, not in my cloud, because there is no cloud in the loop at all.
Why local, not just 'privacy-friendly cloud'
'Privacy-friendly cloud' is a marketing phrase, not an architecture. If your data ever leaves the device, it exists somewhere else, under someone else's control, subject to someone else's breach, someone else's subpoena, someone else's outage. Local-first isn't a friendlier version of cloud-first. It's a different category of trust model — the kind where the honest answer to "where does my data go" is "nowhere, it never left."
There's also a much less philosophical reason: latency and reliability. A model running on-device answers the moment you ask, no round trip to a server, no spinner, no dependency on whether your signal has three bars. Offline-first isn't a nice-to-have feature bullet. On a train, in a basement gym, at 3am with the wifi down, it's the difference between the app working and the app being furniture.
The technology that makes this possible now
This wasn't really practical a few years ago. What changed is the ecosystem around llama.cpp and the GGUF model format — an open-source inference engine, originally built by Georgi Gerganov, that runs large language models efficiently in plain C/C++ across ordinary consumer hardware, no server farm required. GGUF is the compressed, quantized file format that makes a model small enough to actually live on a phone instead of a rack in a data center. That project, plus tools like llama.rn for React Native and Ollama for local model management, are the quiet infrastructure that made it possible for someone like me — one engineer, no cloud budget — to ship real on-device inference inside a consumer app instead of just writing a wrapper around someone else's API.
BrainBox uses this stack directly: llama.rn and GGUF-format models running the on-device chat and persona layer, WatermelonDB handling all data storage locally so the app works fully offline, and computer vision components that never need to phone home either. Nothing about the core experience requires a network request to function.
Problem, built, stack, status
I try to think about every project the same way: what problem, what got built, what stack, what's the actual status — not the pitch-deck version. The problem here was simple: I wanted an AI companion for chat, personas, habit tracking, and journaling that didn't quietly become a data pipeline pointed at someone else's server. What got built is BrainBox — on-device LLM chat through llama.rn and GGUF models, a habit and routine tracker, a journaling layer, and a gamified wellness engine rendered with React Native Skia at 60fps, all sitting on top of WatermelonDB for fully offline data storage, with computer vision components running locally too. The status isn't a pitch either — it's live on Google Play, shipped, being used.
Building all of that as one person, without a cloud budget or a backend team, only worked because none of the pieces required a server round-trip to function. Habit tracking doesn't need the network. Journaling doesn't need the network. Even the chat doesn't need it, because the model lives on the same device as the data it's reasoning about. Every piece of the stack was chosen specifically because it could run without asking permission from a server somewhere else.
Sovereignty over convenience
I'll be honest about the trade-off, because pretending there isn't one would be dishonest. On-device models are smaller and less capable than the giant frontier models running on cloud GPUs. You give up some raw intelligence for full control of your own data. I make that trade deliberately, and I built BrainBox for people who'd make the same one — the same instinct that has me running Ubuntu as a daily driver instead of a locked-down consumer OS, and reaching for physical books instead of always defaulting to a screen. Convenience is real. So is the cost of trading your privacy for it, quietly, one API call at a time.
Why a generalist background actually helps here
Shipping something like this end to end isn't really a single-skill job, and I don't think it could have come from a narrow specialist. The on-device model layer needed the same mindset as the Kotlin-based automation work I've built separately; the offline data layer needed the same discipline as any backend system, just inverted to live on the client; the wellness engine's animation layer needed frontend and motion sensibility as much as engineering. None of those are the same skill, but all of them had to agree with each other inside one small app running on one phone with no server to fall back on when something didn't fit.
That's the actual argument for generalism I keep coming back to: specialists build excellent pieces. Someone still has to be in the room who understands enough of every piece to make them agree to run together, offline, on hardware you don't control the specs of. That was my job on this build, and it's the same job on most of what I ship.
The takeaway
Before you install the next AI app, ask one question: where does my data actually go when I hit send? If the honest answer involves a server you don't control, that's a choice being made for you, not by you. Local-first AI isn't about distrust for its own sake — it's about putting the decision back where it belongs.