Moolah Diaries - Going All In

Three weeks of vibe coding the new native Moolah and I’ve gone all-in. All my data has been converted over to its iCloud backend. moolah-server is still running but I haven’t been updating the data there so its getting more and more out of date. At this point, I’m all in.

As I write this Claude is happily deleting all the moolah-server backend support. Apart from being a big milestone in terms of being committed to the new native implementation, it also marks the first time that I can honestly say that you can use Moolah and I won’t have any access to your data. Previously, data was stored on the server. While I only ever stored a user ID from login, never any name or other personal information, theoretically I could access the data in the database. So while I expect I will remain the only actual user of Moolah, it’s nice to know people could use it without putting their privacy at risk.

The bugs that were once so prevalent are now much more under control. In fact, generally I’d say there aren’t many bugs, but there is a lot of UI that lacks polish or is just downright weird. UI tests are helping to get some of the UI quirks under control, but UI design is definitely not AI’s strength.

The more functional bugs on the other hand have been brought under control through writing a series of guides and review agents - each focussed on a specific area. There’s an iCloud sync reviewer, concurrency reviewer, UI reviewer (good at ensuring everything has accessibility labels, not solving the design problem) and a general code reviewer. Along with an insistence that it fixes every issue raised by those reviewers, the codebase seems to be improving.

Of course, I don’t actually write those guides - I just tell Claude to do deep research on best practices and have it write the guide. Seems to work surprisingly well…

The high level of test coverage also means that once I get it to fix a bug, it generally stays fixed so quality is ratcheting up over time.

The other technique that has been helpful for improving quality is to tell the agent to step back and review the design to come up with a way to really simplify it rather than just keep patching problems. The components that I’ve gone through that process for have tended to stabilise pretty quickly.

That said, progress has slowed down a lot. From the initial report on day 8 it looked like multicurrency support was done. In practice, it’s only become actually usable fairly recently with lots of details missing, particularly with things just not being exposed through the UI. There’s a lot of rework happening too - the data storage has moved from the most automatically managed storage and sync system Apple provides, to doing sync manually and using SwiftData for storage to now working through using SQLite manually (though the first external dependency - GRDB). Nice improvements and nice that such large pieces can be rewritten pretty quickly but it is showing the cost of not having understood everything properly the first time around. Flip side, is we know a lot more about requirements and performance trade offs now that I did at the start which affects many of the choices anyway. It’s a pretty good sign that I feel comfortable doing big migrations and architectural changes though. That’s partly the relative ease with which it can be done - just through the AI at it rather than spending time learning the new framework. Just as much though its a legacy of having multiple backends and spending a lot of time ironing out bugs in the initial iCloud backend - now there is a really great suite of tests that will ensure this rewrite actually works.

All an adventure, all a good learning experience and still a lot of fun.