Before You Add a Database, Ask Whether the Browser Is Enough
A guide to local-first design for small tools: what can stay in the browser, when a backend earns its complexity, and how to explain the boundary.
A database can make a prototype feel like a product before it has earned repeat use. It introduces accounts, retention, deletion, authorization, and a new class of failure. For a single-purpose browser tool, the strongest first architecture may be no server state at all.
Local-first is not a slogan and it is not suitable for every AI workflow. It is a default question: can the useful result be produced and kept on this device, and if not, which exact capability requires data to leave it?
Three kinds of state
We separate session state, personal continuity, and collaboration. Session state disappears when the tab closes. Personal continuity keeps a draft or settings on one device. Collaboration requires identity, permissions, and shared storage. Many small tools need only the first two.
Naming the state prevents an architecture from expanding by reflex. A poster generator may need a downloadable image and remembered palette, not an online gallery. A checklist may need local progress and copied text, not an account system.
| Need | Simplest home | Backend trigger |
|---|---|---|
| Current form | Component state | None |
| Remember settings | Local storage | Cross-device sync |
| Keep an artifact | Download | Shared library |
| Work with a team | Not local-only | Identity and permissions |
AI calls complicate the boundary
A tool may store nothing and still send text to a model service. The interface should distinguish processing from storage. Saying no account required does not tell the visitor whether their input leaves the browser.
A concise note near the action can do real work: your text is sent for this analysis and is not saved by oeeco. That claim must match the implementation and the service terms, but when it is true, placing it at the decision point is more useful than burying it.
What a backend must earn
Cross-device history, collaboration, paid usage, queued jobs, and server-only integrations are legitimate reasons. A dashboard nobody requested is not. Every backend feature should arrive with a retention decision, a deletion path, and authorization tests.
This is not an argument against Supabase or any other platform. It is an argument for using infrastructure when the product has a job for it. Simpler state makes a young tool easier to inspect, explain, and maintain.
Export is an underrated middle path
A text file, JSON export, PNG, or copied report gives the visitor continuity without requiring the creator to hold their data. It also lets the artifact move into workflows the small tool does not need to rebuild.
If users repeatedly import those files on another device or ask to collaborate, the need for a backend becomes evidence-based. Until then, the browser may be enough, and enough is a healthy architecture for a small work.