Why we build local-first tools

September 4, 2026 Privacy Engineering

Every ToolClack product starts from the same rule: it works entirely in your browser, and your data stays there, unless a specific feature genuinely cannot exist without a server. FillKit runs without an account. The free tools on this site process everything client-side; your JSON, your text, your files never leave the tab. This is not a marketing angle we adopted, it is the constraint we design inside, and it is worth explaining why.

You cannot leak what you never collected

Most privacy promises are policies: words about how carefully a company will handle the data it holds. Policies change, companies get acquired, databases get breached. A local-first architecture makes a stronger promise because it is not a promise at all, it is an absence. If your snippets live in your browser and our servers never see them, then no breach of ours, no subpoena to us, no future management decision can expose them. The best place for your data to be safe is wherever we are not.

Honest incentives

A company that stores your data eventually faces the temptation to do something with it: analytics, “improving the product”, training something, selling something. We would rather not spend our willpower resisting that. When the architecture keeps the data out of our hands, the incentive problem disappears with it. It also keeps the business model honest: we can only charge for things that are actually worth paying for, like sync, instead of quietly monetizing what we know about you.

Speed and resilience come free

Local-first is also just better engineering for tools like ours. A text expander that round-trips to a server before expanding would add latency to every keystroke that matters. A JSON formatter that uploads your payload is slower than one that formats it in place, and it fails on the train, on hotel wifi, and on the day the server has a bad morning. Software that runs where the data is tends to be fast, and it keeps working when the internet does not.

Where a server does earn its place

Local-first does not mean server-never. Some things are impossible otherwise: syncing your library across devices, backing up somewhere your laptop cannot lose. Our rule for those features is that the server must be opt-in, additive, and removable: you choose to sign in, the product is complete without it, and walking away (export your data, delete your account) is always on the table. Sync is a feature you add to FillKit, not a condition for using it.

What this rules out

Being local-first has costs, and we accept them openly. No ambient “learning” from your typing, because that requires watching it. No engagement dashboards about you, because that requires tracking you. Some features competitors advertise will never appear here, not because we could not build them, but because they need data we have decided not to have.

If that trade sounds right to you, that is the audience we are building for. Start with FillKit or any of the free tools; neither will ask you who you are.

More articles