We tried Monarch for our household, and we got nothing out of it. It had every transaction, every category, every chart, and no help. It showed us where the money went and left the hard part, deciding what to do next, to us.
So I built Hearth for my household. I built it with Claude Code. I made the product decisions and reviewed everything; it wrote most of the code. Hearth's job isn't to display our finances. Its job is to recommend the next move.
Hearth pulls live bank data through SimpleFIN and turns it into a short list of actions. Each one has a "Why?" link that shows the reasoning. Move this much into savings. Raise this card's autopay. This bill went up, so look at it. It tells us what's safe to spend in each account before the next payday, and it forecasts the lowest our balance will get under a typical month and a lean one.
The most useful part is the payoff plan. It told us which cards to pay off first and by how much, then projected that out over a year. We're following it.
We run a yours, mine and ours setup: each of us has a personal checking account, and we share an account for bills and groceries. Most finance apps assume one person owns everything. That made the hardest design question one about people, not money: who gets to see what?
The answer became a privacy wall. Shared household accounts are visible to both of us, and personal spending stays private to its owner. Every query is scoped to whoever is asking. In the public demo, the "see it as Maya" link switches you to the other partner's view, and you can watch the wall move.
Hearth has its own connector, so either of us can ask Claude questions about our money directly. It exposes ten read-only tools. The important design decision was that Claude gets exactly the same wall as the screens. The login a person uses determines whose money Claude can ask about, and when the wall refuses, that refusal is final. Claude can't reword its way around it. The tools also can't move money or change anything. They answer questions and that's all.
Deciding what an AI agent is allowed to see, and making sure no clever phrasing gets around that limit, is the question I find most interesting in this project.
Hearth has more than 800 automated tests. They all passed while the numbers were wrong.
A bug doubled the interest on our debts, and it was in the payoff plan. The app was confidently telling us to pay the wrong amounts and projecting a year of payments off bad math. No test caught it. I caught it by reading the screen and thinking "that's not right." The same thing happened with a mortgage balance that drifted, an autopay counter that miscounted, and labels that said the wrong thing. Every bug that mattered came from someone who knew what the numbers should look like.
I wasn't always right about why something was off. Sometimes I guessed the wrong cause. But I was right that something was off every time. It went the other way too: when I audited the app, Claude Code pushed back on several of my findings with reasons, and some of those were deliberate design choices I had misread. Review only works if both sides can say "no, here's why."
The other lesson was drift. In one week, five fixes reached the app's screens but never reached the tools Claude uses. The screens and Claude were quietly giving different answers to the same question.
I'd make the screens and the AI tools use the same code from day one, so a fix in one place is a fix everywhere and they can't disagree. I'd write checks for what a person would notice, like "interest can't be more than this" or "a balance can't jump without a transaction," instead of relying only on tests that confirm the code does what it was told. And I'd build review into the process from the start, not treat it as something that happened to catch bugs.
An AI system can pass every test and still give confidently wrong advice. The only reliable safeguard I found was a person who knows what right looks like, with a clear way to say so. That's the part of building with AI I want to keep doing.