Building Privacy-First Tools
How I approach building developer tools that respect user privacy — from architecture decisions to local-first data storage and zero-telemetry design.
Why Privacy Matters in Developer Tools
Every tool I build starts with a single constraint: user data stays on the user's device. This isn't just a feature — it's a foundational architecture decision that shapes everything from storage choices to network requests.
When I built Billion Bucks, the most common feedback was surprise that it didn't have a backend. No accounts. No syncing to a cloud database. No analytics pinging home every session. Just a React app that stores encrypted data in IndexedDB and does all computation client-side.
The Local-First Architecture
The pattern I follow for privacy-respecting tools:
- Zero network requests for user data — sensitive data never leaves the browser
- Offline-first by default — full functionality without connectivity
- No analytics or telemetry — I don't need to know what you do with the tool
- Export-first — users own their data and can export it anytime
// All computation happens client-side
// No API calls for user financial data
function calculateNetWorth(accounts: Account[]): number {
return accounts.reduce((sum, account) => {
return sum + (account.type === 'asset' ? account.balance : -account.balance);
}, 0);
}
Choosing the Right Storage Primitive
For simple tools, localStorage is fine. For larger datasets, I prefer IndexedDB via idb for structured queries and larger storage limits. Neither sends anything over the network.
The key insight: most "personal finance" or "productivity" features don't require a server. They require good client-side architecture.
What You Give Up
Local-first means no sync across devices — at least not out of the box. The tradeoff is explicit: privacy over convenience. For many users, that's the right call.
The browser's crypto.subtle API handles any cryptographic needs (hashing, key derivation) without third-party dependencies.
Tooling Patterns
Some patterns I've found useful when building these tools:
- State machines (
xstate) for complex form flows without global state leaks - Web Workers for heavy computation off the main thread
- Service Workers for offline support and update management
- Content Security Policy headers to prevent XSS — no inline scripts, strict
script-src
Building in Public
All Mukenshi tools are open-source. The privacy guarantee isn't a promise — it's verifiable. You can read the source, audit the network tab, and confirm nothing leaves your browser.
That transparency is itself a privacy primitive.