Why I Got Fed Up With Every Finance App and Built My Own From Scratch

There are thousands of personal finance apps on the Google Play Store.

If you search for "expense tracker" or "money manager," you will find everything from minimalist weekend side-projects to massive venture-backed platforms with tens of millions of downloads.

So why sit down on an August evening in 2026 and start writing another one from scratch?

The answer comes down to a fundamental realization: almost every popular personal finance application compromises on either data privacy or basic accounting accuracy.

The Cloud Expense Tracker Bargain

For years, the standard bargain of consumer fintech has been convenience in exchange for surveillance.

When you install a mainstream personal finance app, the onboarding flow inevitably asks for broad permissions: phone storage, background location, contacts, and most importantly, full access to read incoming SMS messages.

On the surface, the value proposition is tempting. Every time you buy a coffee or pay an electricity bill, your bank sends an SMS alert. The app detects the transaction and logs it automatically. You never have to type in an expense manually.

flowchart TD
    subgraph CloudModel["The Commercial Tracker Model"]
        SMS["Incoming Bank SMS"] --> CloudApp["Tracker App"]
        CloudApp -->|"Uploads Full Message"| ExtServer["Remote Cloud Servers"]
        ExtServer --> NLP["Cloud NLP & Profiling"]
        ExtServer --> DataStore["Centralized DB (Breach Risk)"]
        NLP --> AdProfiles["Consumer Spending Analytics"]
    end

The catch is where that processing happens. In most commercial applications, incoming financial alerts are transmitted directly to central company servers. Cloud natural language models parse the merchant and amount, and the records are stored in centralized databases.

Financial records are not generic telemetry. They are an intimate diary of your personal life. When you upload your transaction history, you are uploading:

• Where you eat and shop.
• What medical clinics or pharmacies you visit.
• How much money you earn and when your paycheck arrives.
• Which banks and credit cards you use.

Even when companies claim they anonymize data, aggregation models frequently leak behavioral identities. And when those cloud databases suffer breaches, personal financial details become exposed to credential stuffing and identity theft.

The Accounting Problem: Double-Counting and Fuzzy Math

The second motivation was purely technical: most consumer finance apps butcher balance accounting.

They are designed as digital receipt checklists rather than relational financial ledgers. When you buy something with a credit card, they record an expense. When you pay off that credit card bill at the end of the month, they record another expense. By the end of the year, someone who relies heavily on credit cards will see their reported expenditure doubled.

Furthermore, almost all apps conflate Net Worth with spendable money. They display a giant, attractive balance that includes locked fixed deposits, retirement funds, and fluctuating equity investments, while ignoring upcoming credit card bills. Users open their app, see a high number, feel wealthy, and overspend their liquid cash.

I wanted an application that respected the mathematical reality of money:

• Assets are distinct from liabilities.
• Credit card purchases are expenses, but credit card bill payments are balance settlements.
• Spendable liquid cash must be strictly separated from long-term illiquid capital.

Starting FinLedger: The Initial Commit

On August 19, 2026, I committed the first lines of FinLedger.

flowchart LR
    subgraph CoreFoundation["FinLedger Architectural Pillars"]
        direction TB
        P1["1. Local-First Engine:
Zero Remote Server Requirements"]
        P2["2. Hardware Encryption:
SQLCipher 256-bit AES at Rest"]
        P3["3. Pure Kotlin Domain:
Single Source of Balance Truth"]
        P4["4. Zero Cloud Telemetry:
On-Device Machine Learning"]
    end

Rather than jumping directly into writing Jetpack Compose UI screens, the project began with a formal Software Requirements Specification (SRS) and architecture plan:

1. Local-First by Default: The app must function completely without network connectivity. No mandatory logins, no user accounts on remote servers, and zero telemetry SDKs.
2. Encrypted at Rest: The local database must be encrypted using SQLCipher with 256-bit AES-CBC, with encryption master keys anchored inside the hardware-backed Android KeyStore.
3. Clean Architecture Separation: The mathematical rules governing money must live in pure Kotlin domain engines (Posting.kt and LedgerEngine.kt), entirely decoupled from Android UI lifecycles.
4. On-Device Intelligence: Automated SMS transaction detection and merchant categorization must execute 100% on the device silicon using lightweight, local machine learning models.

The Journey Ahead

Building FinLedger has been an exercise in confronting real software engineering challenges: writing 24 consecutive SQLite Room schema migrations without breaking user data, tuning Kotlin Coroutine dispatchers to eliminate UI frame drops, and implementing client-side encrypted backup to Google Drive REST API v3 without third-party intermediate servers.

Software should respect the person using it. It should be fast, private, mathematically honest, and durable.

---

FinLedger is a privacy-first, offline-first personal finance application for Android that models bank accounts, credit cards, and cash without double-counting.

Explore FinLedger on Google Play: https://play.google.com/store/apps/details?id=com.devanshufinance.app