What is a client-side-only tool?
Runs entirely in the browser, state in localStorage or IndexedDB, no server beyond static files. No account, no database, nothing transmitted.
Guide · Architecture
Tools with no backend, and the honest trade
A tool that never sends data anywhere cannot leak it, cannot lose it in someone else's breach, and cannot be repriced when the hosting bill arrives. It also cannot sync to your phone. Both halves are worth saying out loud.
The default is heavier than the problem
Most small utilities get built with an account system, a database, a session store, and a hosting bill — for a calculator. The reflex is so automatic that nobody asks whether the server is doing anything the browser could not.
For a large class of tools, it is not. A position sizer, a trade journal, a weight tracker, a habit checklist, a unit converter, a text formatter: all of these are pure functions plus a little state. The browser has a JavaScript engine and persistent storage. That is the entire requirement.
What you gain
No breach surface
The strongest security property available is not holding the data. No user table means no credential dump, no password reset flow to phish, no session tokens to steal, no compliance obligation around personal data you never received. You cannot be forced to hand over records that were never on your server, and an attacker who fully compromises the host gets a folder of static files.
Data stays where the user can see it
Browser storage is inspectable. A curious user can open DevTools and read exactly what the app kept. That is a much stronger claim than a privacy policy, because it is verifiable rather than promised — the network tab shows there are no outbound requests carrying their data.
It costs nothing to run
Static files on GitHub Pages, Netlify, or Cloudflare Pages cost nothing at realistic personal-project traffic. There is no database to back up, no dependency to patch at 2am, no bill that grows with users. A client-side tool that gets popular gets cheaper per user, not more expensive.
It keeps working
No server means no outage, no rate limit, no deprecation. Offline through a service worker, it works on a plane. A tool built this way in 2020 still runs today with no maintenance, which is not a claim most SaaS side projects can make.
What you give up
This is the part most local-first pitches skip, so here it is plainly.
| You lose | What that means in practice |
|---|---|
| Cross-device sync | Data logged on the laptop is not on the phone. Two devices means two separate datasets. |
| Backup | Clearing browser data deletes everything. On iOS, storage can be evicted after long non-use. |
| Server-side compute | No heavy jobs, no scheduled tasks, no calling a paid API without exposing the key. |
| Collaboration | No sharing, no multi-user, no permissions — there is nothing to share through. |
| Analytics on usage | You genuinely do not know how the tool is used, which makes it harder to improve. |
| Recovery | No support ticket can restore what a user deleted, because you never had a copy. |
The honest framing is not that these do not matter. It is that for single-user tools they usually matter less than the ongoing cost of an account system — for the builder and for the user, who has one more password and one more breach notification in their future.
Mitigations that keep the model intact
- Ship export and import. A JSON or CSV download turns 'no backup' into 'your backup, your file'. This is the single highest-value feature in a local-only tool.
- Warn before destructive actions and never auto-clear storage on version change.
- Make the storage key stable across deploys, and migrate schemas forward rather than resetting them.
- Say where the data lives, in the app, not only in the privacy policy. One line under the form does more than a page nobody opens.
- If sync is genuinely needed later, add it as an opt-in layer over the same local store rather than rewriting around a server.
Writing the privacy policy honestly
A local-only tool makes for a short, unusually credible privacy policy — but only if it is specific. Vague reassurance reads exactly like every policy that turned out to be false.
- Name the storage mechanism: 'stored in your browser's localStorage on this device'.
- State plainly that there is no account, no server-side database, and no transmission of entered data.
- Disclose what is collected, if anything — static hosting still produces server logs with IP addresses, and any embedded analytics or fonts are third-party requests. Do not claim zero collection while loading a tracker.
- Explain the eviction risk: clearing site data deletes it, and browsers may evict storage. Point at the export button in the same sentence.
- Skip the legal-sounding padding. A policy a user can read in 60 seconds is more protective than one they cannot.
The test I use: could a technically literate user verify every claim in the policy from the network tab in under a minute? If yes, it is honest. If a claim requires trusting me, it should be softened or removed. Mine is here →
When you actually do need a backend
Not every tool fits. You need a server when the data is genuinely shared between people, when compute exceeds what a phone browser can do, when an API key must stay secret, when the data must survive a lost device, or when a regulation requires audit trails you can produce. Those are real requirements — the point is to check whether you have one, not to assume you do.
Tools referenced in this guide
- Apps hub — three tools built this way — no accounts, no server, no analytics on your entries.
- Cut — weight tracker with local storage and an export path.
- Privacy policy — a short, verifiable version of the claims described here.
- My stack — what static hosting and tooling this runs on.
FAQ
Quick answers
Is no-account more secure?
For user data, yes — the strongest protection is not holding it. No user table, no tokens, no reset flow to phish. It does not protect a compromised device.
What do you give up?
Sync, backup, recovery, collaboration, server-side compute, secret API keys, and real usage analytics. Say so rather than hiding it.
What does it cost to run?
Effectively zero. Static hosting is free at personal traffic, nothing to back up or patch, and cost per user falls as usage grows.
How do users back up?
An export button that downloads JSON or CSV. Highest-value feature in a local-only tool — clearing site data wipes everything.
What goes in the privacy policy?
The exact storage mechanism, no account or database, whatever hosting logs still collect, the eviction risk, and the export path. Verifiable claims only.