The Bet
Mint is dead. The alternatives (Monarch, Copilot, Lunch Money) all want write access to your accounts and store your data on their servers. Our hypothesis: a read-only financial assistant that never stores raw transaction data can serve the large segment of users who abandoned Mint over privacy concerns and refuse to trust the replacements.
The key insight: most people don't need budgeting automation. They need visibility — "where did my money go this month?" — without handing a startup the keys to their bank account.
What We Built
Architecture-first approach, designed before coding:
- React Native mobile app with local-first data storage
- Plaid for bank account linking (read-only access scope)
- DuckDB running on-device for fast analytical queries over transaction data
- FastAPI backend handling only Plaid token exchange — no transaction data touches our servers
The privacy model was the core product decision: Plaid tokens are exchanged through our backend (required by Plaid's architecture), but all transaction data flows directly to the device and is stored in a local DuckDB database. Our servers never see, store, or process financial data.
What Happened
Architecture and prototype completed, then blocked:
- Architecture validated — the local-first model works. DuckDB handles thousands of transactions with sub-second query times on mobile. The "your data never leaves your phone" promise is technically achievable.
- Plaid sandbox prototyped — successfully connected to Plaid's sandbox environment, pulled test transactions, and ran analytics queries locally.
- Privacy model designed — documented the exact data flow showing our servers are a pass-through for auth tokens only. This is a genuine differentiator, not marketing spin.
Then we hit the wall: Plaid production access requires SOC 2 compliance. For a solo operator, SOC 2 certification costs $20K-50K and takes 6-12 months. This isn't a technical problem — it's a business model problem. The product that promises "we never touch your data" still needs to prove to Plaid that we handle their tokens securely.
What We Learned
-
Read-only is a feature, not a limitation. Every user we talked to during research said the same thing: "I just want to see my spending, I don't need it to move money." The read-only constraint actually increases trust.
-
Plaid's moat is regulatory, not technical. The API itself is straightforward. The barrier is compliance requirements that make it prohibitively expensive for small teams to get production access. This is a structural advantage for funded startups.
-
Local-first architecture is underrated. DuckDB on-device is shockingly fast for financial analytics. The "no server" model eliminates hosting costs, data breach liability, and a whole category of user trust concerns. If we can solve the Plaid access problem, the operating costs approach zero.
-
SOC 2 alternatives exist but need research. Plaid isn't the only aggregator. Finicity (owned by Mastercard) and MX have different compliance requirements. There may also be a path through Plaid's partnership program for privacy-focused apps. This needs deeper investigation.
Current Status
Paused. The architecture works and the market demand is clear. Blocked on Plaid production access (SOC 2 requirement). Investigating alternative data aggregators and Plaid partnership programs. Will resume if we find a viable path to production bank connectivity without the $20K+ compliance overhead.