Family Financial Planner

My finances are complicated and they shift month to month, and I'd been running the whole thing on a spreadsheet that had grown convoluted enough that only I could read it.

What I wanted wasn't sophisticated modelling. I wanted to be able to plug in a real situation and see what it did to us: if the kids go to nursery an extra day a week, and then one of them starts school so the cost drops because there's only one of them in there, what does that do to our cash flow and our savings over the next few years? And then the other category, the dream scenarios, where the question is if I could do this thing, what do our finances look like in five years as a result? Underneath both was something simpler, which is that I wanted a view of where we are and where we're heading that I could adjust on the fly, and that my wife and I could both look at and come away understanding the implications of a decision the same way.

This was my first build with Claude Code, and it came straight off the back of MyOS, so the method changed as much as the tooling did.

Instead of starting to build, I got Claude to interview me first: what's the problem, what am I trying to solve, how would I use it, what should it look like. That went into a proper requirements document. Then I went and found visual references, screenshots of interfaces I liked, and handed those over alongside the brief so there was no guessing about the look. It was more work before anything existed, and it took a three-week build down to about two days.

The moment worth recording is when I went to connect it to my actual banking APIs so the numbers would be live, and stopped. I didn't properly understand the security model around what I'd be plugging in, and I wasn't prepared to connect my bank to something on the strength of it feeling fine, so I left the data manual and it's stayed that way.

I use it much the way I used the spreadsheet, which is to say I open it when something changes and I need to think. The bank integration would have made it a live daily product, but the honest position is that I don't need it to be one. It looks considerably more professional than what it replaced, it answers the questions I built it to answer, and that's enough.

The lesson I've carried forward is to spend the time on the brief before anything gets built: run the interview, get the requirements document out of it, go and find visuals (Dribbble is fine for this), and hand both over together. After that you're tweaking rather than building, and the time saving is dramatic enough that I've never gone back to the old way.

The other thing is that this is all simpler than it looks from the outside, largely because someone has already built a version of whatever you're attempting, and most of the work is knowing what you want rather than knowing how to make it.

If you don't understand how something works, or how secure it is, then you're potentially accepting unknown and unmitigated risk. The ease and speed with which these tools produce a decent output papers over the difference and tempts you into moving well before you've given the required foundations any real attention. The trap is assuming that something which looks polished is the same as something that has been rigorously tested. Governance around every stage, from ideation and scoping through building, testing, monitoring and decommissioning, is needed, otherwise we're taking a stance on risk in which not yet means the same as never.