Every startup has a moment where they look at their codebase and realize: what got us here won't get us there. For Simple Money Tracker, that moment came in February 2026. Our user base was growing fast. Our feature set was expanding. But our security architecture was still built on the assumption we could trust the server.
We couldn't. Not anymore. Not with people's financial data.
The Three-Pillar Architecture
Version 3.0.0 wasn't one feature. It was a three-pillar architectural overhaul, each pillar mandatory for the others to work.
Pillar 1: End-to-End Encryption. Every piece of user data — expenses, messages, groups, investments, goals, lending, contacts, moods, subscriptions — encrypted before storage. Decrypted only on client devices. The server becomes a dumb storage layer with zero visibility into content.
Pillar 2: Single Session Login. One user, one active session. Log in from a new device, and the old session is invalidated immediately. This eliminated the class of bugs where stale sessions could cause data conflicts, and it set the foundation for secure DEK management.
Pillar 3: Smart Caching & Metadata. We moved from 'fetch all data every time' to metadata-based incremental fetching. The app stores lightweight metadata locally and only fetches records that changed since the last sync. Firestore reads plummeted. App responsiveness soared.
This was not an update. This was a rewrite.
Every data access path in the application was touched. Every module got a new encryption layer. Every cache was rebuilt. The result: a completely different security posture with no visible change to the end user.
Single Session: Why It's Harder Than It Sounds
Single-session enforcement sounds simple: track the active session ID, reject any request with a different ID. But that interacts poorly with Firebase's token lifecycle. Firebase Auth tokens expire every hour. When the app refreshes a token, the session ID shouldn't change — that would log users out every 60 minutes.
Our solution: bind the session to the Firebase refresh token, not the access token. Refresh tokens have longer lifetimes and don't rotate on access token refresh. The session ID rotates only on explicit login events, not on automatic token refreshes. It took four iterations to get this right, but the final implementation is seamless — users never notice the session management happening in the background.
The Smart Caching Revolution
Before v3.0.0, loading the Expenses page would fetch every expense the user had ever recorded. For power users with years of data, that meant hundreds of Firestore reads per page load, multi-second wait times, and inflated cloud bills.
The new metadata system changed everything. On first load, the app fetches only metadata (IDs + timestamps) and stores them locally. Subsequent loads compare local metadata timestamps against server timestamps, fetching only the subset of records that changed. A page that needed 500 reads now needs 5. A 3-second load becomes instant. And our Firestore bill dropped dramatically.
We applied this pattern to Expenses and Messages in v3.0.0, and extended it to every remaining module in v3.1.0 with the Delta Sync engine.
The Payoff: A Platform Ready for the Future
Version 3.0.0 was painful to build. Every developer on the project had to learn new encryption primitives, new caching patterns, and new session management flows. But it was necessary. Because the v3.0.0 architecture is what made v4.0.0's Zero-Knowledge Vault possible. It's what made the Telegram bot's end-to-end encryption possible. It's what makes Simple Money Tracker fundamentally different from every mainstream finance app.
Sometimes you have to tear down the house to build a fortress. That's what v3.0.0 was. And looking back, it was the best decision we ever made.
