Every architectural decision I made building OvertimeIQ came from the same four constraints. Not preferences — constraints. Things that were non-negotiable before I wrote a line of code.
- Work data cannot leave the user's control. Hours, rates, employer names, project names — this is sensitive professional information. It cannot live on my server, my cloud provider, or anyone else's database.
- Zero cost at zero subscribers. A solo project that costs $40/month before it earns a rupee is a liability, not a product.
- Works with Indian payment infrastructure. UPI AutoPay, ₹149/month price points, T+1 settlement. Stripe is the wrong answer for a domestic Indian product.
- Offline-first. The app must work fully on a flight, in a basement, with no signal. Work happens everywhere. Those four constraints didn't just influence the architecture — they eliminated five of the six options I seriously considered. Here's each one, what it looked like, and exactly where it failed.
Option 1: Traditional backend + Postgres
The standard playbook. A Node/Express backend, a Postgres database, REST API, JWT auth.
What it solves: Everything. This architecture has solved every web application problem for fifteen years.
Where it fails my constraints: Immediately, and on two counts.
First, cost. Even a hobby-tier server — a $5 DigitalOcean droplet, a free-tier Railway deployment — has a running cost before subscriber one. More importantly, it has an operational cost: migrations, uptime, backups, security patches. A solo product cannot carry that surface area.
Second, and more importantly: data custody. Every log entry, every hourly rate, every employer name would live in my Postgres database. That's the opposite of what this product promises. The privacy proposition isn't "we secure your data" — it's "your data is never ours to secure."
Eliminated.
Option 2: Supabase for everything
Supabase gives you a managed Postgres, auth, realtime, and storage on a generous free tier. It's genuinely excellent infrastructure. I use it in the final architecture — just not for work data.
The temptation: Free tier covers 500 MB database, 50k MAU. Auth is built in. Row-level security means each user can only see their own data. Storage is cheap. What's the problem?
The problem: Supabase for everything means my work logs, hourly rates, overtime sessions, and project names live in Supabase's database — on AWS, behind their security posture, subject to their future business decisions, subpoena-able by parties I have no control over.
Users of a privacy-focused overtime tracker are, almost by definition, people who don't want their work data on someone else's server. Using Supabase for work data would hollow out the core value proposition.
Supabase is excellent infrastructure. The constraint isn't Supabase — it's that work data can't live there. This observation became the seed of the final architecture.
Eliminated for work data. Reserved for identity.
Option 3: Pure IndexedDB
If the constraint is "data stays in the browser," why not use the browser's native database? IndexedDB is built into every modern browser, stores arbitrary structured data, and requires zero infrastructure.
What works: Zero cost. Data is local. No backend required. Runs offline trivially.
What fails:
- No portability. IndexedDB data is browser-specific. Chrome on your laptop has different data than Chrome on your phone. There's no canonical copy.
- No cross-device sync. Every device is an island.
- No user control. Your data is in the browser's storage, not in a file you can see, back up, or migrate. The browser can evict it under storage pressure. There's no export path that doesn't require building one from scratch. A time tracking app that only works on one device, that can silently lose data when the browser decides to reclaim storage space, is not a serious tool.
Eliminated.
Option 4: Electron
Package the app as a desktop application. Store data in a local SQLite file. No browser storage limits. No sync problem.
The appeal: SQLite is genuinely the right database for this use case — a single-user, local-first, structured data store. Electron gets you there without browser sandboxing.
The reality: Distribution. Update mechanics. Platform-specific builds. An app that can't be installed from a URL without an OS-level prompt. No mobile. A 200MB download for something that should feel like opening a tab.
The web is the right distribution channel for a personal productivity tool. Electron is the right solution to a different problem.
Eliminated.
Option 5: Pure client-side SPA — v1
This is what I built first. React + Vite, sql.js (SQLite running as WASM in the browser), Google OAuth PKCE, Google Drive as the sync layer. No backend. No server. A static site deployed to Vercel that makes calls only to Google APIs.
What works, and works beautifully:
- sql.js gives you a real SQLite database running entirely in the browser as a WASM binary. Schema migrations, indexes, complex queries — the full database.
- The database is a single binary file, serialized to a
Uint8Array, stored inlocalStorage, and mirrored to the user's Google Drive asovertimeiq.db. The user owns the file. It's on their Drive. It's portable. - Drive sync is elegant: on login, compare
modifiedTimeagainst the last sync timestamp. Download if Drive is newer, upload if local is newer. Debounce writes 10 seconds after the last operation to batch rapid edits. - Earnings calculations, midnight-crossing rate logic, holiday detection — all of it runs in the browser, all of it offline-capable. This architecture validated the core privacy premise. It works. Users genuinely own their data.
Where it hits a ceiling — first:
Invite control. I wanted invite-only access during beta — a waitlist, admin-managed invites, unique token links. There is no way to implement this without a server. An invite token that's validated entirely client-side isn't validation — it's decoration. Anyone who finds the URL can skip it.
Where it hits a ceiling — second, and more fundamentally:
A pro_flag = 1 column in a SQLite file that lives on the user's own Google Drive is not a feature gate. It's a suggestion. Any user can open their overtimeiq.db file with the DB Browser for SQLite, flip the flag, and reload the app. The "security" evaporates.
I spent some time convincing myself this was acceptable. It isn't — not for a product that charges ₹149/month for Pro features. A gate that can be bypassed by anyone with 10 minutes and a free SQLite browser is not a gate.
These two limitations forced a rebuild.
Option 6: The hybrid — v2 (what I actually shipped)
The insight that unlocked v2 was this: draw a hard line between data that is yours and data that is about access.
Work data — logs, hours, rates, jobs, earnings — is yours. It has strong privacy requirements. It should live on your own Google Drive and never touch my infrastructure.
Access data — identity, subscription status, invite records — is about the relationship between you and the product. It has strong security requirements. It needs a real server with real auth.
These are fundamentally different things. They need different architectures.
The v2 architecture:
- SQLite on Google Drive — unchanged. All work data. Privacy preserved.
- Supabase — identity, invites, waitlist, subscriptions only. No log data. No earnings. No work records.
- Next.js API routes — invite validation (server-side, unforgeable), payment webhooks, pro token issuance.
- ECDSA ES256 signed JWT — the pro token. Server holds the private key, mints a 3-day token on every online load. Public key is hardcoded in the JS bundle. Verified client-side via the WebCrypto API. Editing the SQLite file no longer does anything — gates read from the verified token payload, not the raw database column. What this fixed:
Invite control: /join/[token] validates the token server-side before showing any Google login. Unforgeable.
Feature gating: The SQLite file can be edited freely. It doesn't matter. The pro_plan value in memory comes from a cryptographically signed JWT that cannot be forged without the server's private key and cannot be extended without server re-issuance.
What it cost:
Three weeks of rework. The SPA became a Next.js app. A Supabase project was provisioned. The auth flow became more complex (Google OAuth PKCE → supabase.signInWithIdToken() — two independent lifecycles). The file structure doubled.
Was it worth it? Yes — because the alternative was shipping a product with a feature gate that a free GUI tool can bypass in 30 seconds.
The transferable pattern
The split this architecture enforces — work data on Drive, identity on Supabase — is a pattern that applies to any app with sensitive personal data and a subscription model.
The question to ask: "Could someone be harmed if this data were leaked or subpoenaed?" If yes, it belongs on infrastructure the user controls. If the data is about the user's relationship to the product (did they pay? are they invited?), it belongs on infrastructure you control with proper security.
Treating these as the same problem leads to either a privacy compromise (everything on Supabase) or a security hole (everything client-side). Treating them separately solves both.
The three weeks of rework to land on v2 was the most valuable time I spent on this project.
Series note
This article is part of the Privacy by Architecture series documenting the build of OvertimeIQ — a personal overtime tracker that stores work data on your own Google Drive. If any of the implementation details are interesting, there are deeper dives on sql.js + Drive sync, Google OAuth PKCE and upcoming next (ECDSA feature gating and the invite system).