Software Engineering2 min read

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:

  1. Zero network requests for user data — sensitive data never leaves the browser
  2. Offline-first by default — full functionality without connectivity
  3. No analytics or telemetry — I don't need to know what you do with the tool
  4. 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.