Why We Built Bodhi With No Server
The short answer: we did not want to be responsible for the data. Bodhi is a wellbeing app. It holds how well you slept, how activated you feel, and whether you have a cardiac condition. That is health data, and the cheapest, most durable way to protect it is to never let it reach us.
Privacy policies are promises; architecture is a constraint
Most apps handle sensitive data by collecting it and then promising to behave. That promise is only as good as the company’s access controls, its staff, its vendors, its next funding round and its eventual acquirer. Every one of those can change without the user being asked.
An app with no backend makes a different kind of statement. We cannot sell what we do not have, we cannot leak what never left your phone, and we cannot change our minds later. The privacy policy becomes a description of the system rather than a commitment about our conduct.
What it removes
Everything Bodhi records goes into a SQLite database inside the app’s own storage. There is no account, so there is no sign-up, no password reset, no session handling and no identity to attach anything to. There is no server, so there is nothing to provision, patch, monitor or pay for.
That is not just a privacy win. A large share of what makes a small app expensive to run is infrastructure that exists only because data is being moved somewhere. Remove the somewhere and the work goes with it — along with the breach surface, which is the risk nobody budgets for until it happens.
What it costs
This is a real trade, and pretending otherwise would be dishonest.
- No analytics. We cannot see which exercises people finish or where they drop off. We rely on what users tell us directly.
- No sync. Your history lives on one device. Move phones and it does not follow you.
- No remote intervention. We cannot repair a bad record or migrate data server-side; a fix has to ship as an app update.
- Support is harder when you cannot look at the account, because there is no account.
We accepted all four because Bodhi is single-user and its data is sensitive. For anything collaborative, or where the data has to outlive the device, this would be the wrong call.
The question worth asking
Before building the account system, ask what the data is actually for. A surprising amount gets collected because the framework made it easy, not because a feature needed it — and every field you store is one you then have to secure, retain, honour deletion requests against and explain.
That is the same reasoning we bring to AI product engineering for clients, and it starts earlier than most people expect — usually at data readiness. If you are scoping something that touches sensitive data, book a free audit.
