Domdhi logoDOMDHI.OS
FINANCE

Why I Don't Use Mint, YNAB, or Personal Capital

Mint shut down. Users had migration and download options, but keeping Mint wasn't one of them. That's the dependency I won't build my finances around. Keep the data. Know what the export leaves behind. Make sure your numbers can outlive the app.

DDominic BacaSOLO ENGINEER · DOMDHI.OS2026.10.095 MIN READ
FINANCE// FIG.01

Mint shut down. Intuit offered migration to Credit Karma and data downloads. Users had a way out with their data. Keeping Mint wasn't an option.

The lesson I took: never let the only view of my own money live somewhere I don't control.

That's the dependency that bothers me... somebody else gets to decide when the tool I'm building my routines around is done.

Who Pays For The Dashboard?

Running a service that connects to banks and keeps transaction history costs money. A free dashboard still has a business behind it.

I want to know what that business needs from me. A subscription? A referral? An advisory relationship? Those are different arrangements. "Free" alone doesn't tell me which one I'm agreeing to, and it doesn't prove somebody's selling my transaction history.

The question I care about is whether helping me understand my finances pays the bills... or whether getting me into another product does.

That doesn't make the tool useless. A dashboard can do real work for me and still serve a business goal I don't share. I want to understand the arrangement before I build around it.

That applies to Personal Capital, YNAB, or whatever replaces the last app. Paying for a tool is an arrangement I prefer. It still doesn't buy control of its roadmap.

Either way... the export matters more than the sales pitch.

An Export Isn't The Whole System

Categorizing transactions is real work. Splitting purchases. Correcting the auto-classifier that thinks a hardware store run was "Home Improvement" when it was a business expense.

The bank feed gives me transactions. The categories help me answer "what did I actually spend on food last year."

YNAB exports categories, category groups, and transaction history. That work survives. Targets and category notes don't make it into the export. If those notes explain why I set something up a particular way, I need to preserve them separately.

So... what can I actually rebuild from the files?

Can I calculate my burn? Keep my category definitions? Figure out what I left behind? I want those answers before I'm staring at an import screen because the service shut down or I decided to leave.

A CSV can preserve years of work. Open it. Check what's there. Make sure you can use it.

The Connection Is Another Dependency

A bank connection can break. Authentication changes. A feed stops updating. Whatever the cause, I need to see when the numbers were last refreshed.

Picture an account that hasn't synced for three weeks. The dashboard still shows a balance... does it make the age of that balance obvious?

That's the failure mode that scares me. A stale number presented like a current one. How the fuck am I supposed to make a useful decision if I don't know when the inputs stopped moving?

Building my own dashboard doesn't magically fix that. Manual entry gets stale too. The requirement follows me: show the freshness, flag the gap, and don't confuse a number on a screen with a number I can trust.

So I Built It

The glass cockpit is my answer. My own tables, my own categories, my own definitions of burn and runway.

The honest accounting on that choice:

What it costs. Real build time, up front. Manual entry or a self-managed import for anything that doesn't have a clean feed. Maintenance forever. Backups I have to check. Recovery I have to figure out.

I am now the vendor. Apparently I needed another job lol.

What it buys.

  • I control the data model. I can change a category or revise how I calculate historical spending.
  • I control the definitions. "Runway" means what I need it to mean.
  • I can maintain and move my own code and data. Hosting providers can still change prices or shut things down. Keeping a usable copy and a way to restore it is my responsibility.
  • I can make freshness part of the view instead of treating it as somebody else's problem.
  • The categorization work stays usable outside any one interface.

That last one connects to never creating value you can't capture. Years of categorizing transactions is labor. Leave it trapped in someone else's system and it's rent. Keep it usable outside that system and it's equity.

And yeah... an export you can actually use counts. You don't have to build the whole damn app to keep your work.

When You Should Absolutely Just Use The App

I'm not going to pretend my choice generalizes. It mostly doesn't.

If you don't write software, building this is a bad trade and I'd tell you so directly. Use the tool that helps you do the work. If that's YNAB, use YNAB. Export your data quarterly and keep the files somewhere you control. Save targets and category notes separately.

Then open the files. "I downloaded something" isn't the same as "I know I can use this."

The rules I care about:

  1. Know how the tool gets paid. I prefer paying directly. I still want to understand the incentives and the exit.
  2. Export on a schedule. Put it on the calendar. Check what's included and save what's missing.
  3. Know your burn without the app. Keep the calculation somewhere you can inspect. If the dashboard vanished tomorrow, I want to know what it costs to keep my life running.

That third one is the real test. A dashboard can substitute for understanding right up until it's gone.

Own The View

Money is the one domain where I refuse to rent the only instruments.

Some commercial tools are excellent. I still want the picture of my own finances to survive somebody else's roadmap, pricing committee, or acquisition.

Run the numbers yourself. Keep the exports. Know your burn cold.

Mint offered a way to take the data. It still got to decide when the tool died.

I want my numbers to outlive the app.

GET_TRANSMISSIONS

Raw signal on finance, freedom, fitness, and tech. No spam. Unsubscribe anytime.

D
Dominic Baca

One engineer building Domdhi.OS in public — money, freedom, and the occasional 2am migration. Every number live, every commit public.

FOLLOW THE LOGS →
// NEXT IN THE LOGS