The spreadsheet that became a toolkit

The situation

Early in 2026 I spent a while researching investment and tax strategy to revamp our portfolios, then hired a financial planner for a short engagement to pressure-test what I had come up with. That left me with several jobs that would recur indefinitely, the most tedious being portfolio rebalancing and estimated tax payments. Both are the kind of work that is straightforward in principle and miserable in practice, because doing them properly means holding a lot of interacting rules in your head at once.

I started building the rebalancing model in a spreadsheet. Fairly early on it became clear that it would be too tedious and time consuming to maintain. This was the same period I was learning what agentic coding tools could actually do at work, so I decided to find out what I could build instead. The tension was mundane and familiar: the obvious solution was the one I would end up avoiding.

Constraints I was handed

The inputs are personal financial information, so nothing could be handled carelessly and no real figures could go anywhere they did not need to be.
Nobody else was going to maintain this, so complexity I added was complexity I would carry myself.
The tax work depended on income information that the rebalancing work did not need, so the data the tools required was not going to stay simple.

The call I made

The expected option was a spreadsheet, or paying for a product that does some of this. I already subscribe to Monarch, which aggregates accounts well. The call I made was to keep it for what it does well and build only the parts where my approach does not match how that product thinks about the problem. That meant writing a short requirements document first, treating a personal project like a product with a defined scope, and then building against it.

Dimension	Spreadsheet or off-the-shelf	Build around the product I use (chosen)
Time to ship	Immediate; the spreadsheet already existed	Slower; nothing is usable until it is built
What it fixes	Handles the common case, and diverges from how I actually run these decisions	Fits my approach, and lets me run the analysis whenever a decision calls for it
Cost of being wrong	Low; abandon it and go back to manual work	Real; anything I build I maintain myself, and a bad structure compounds

I kept Monarch for aggregating and exporting the data, which is the part it does better than anything I would write, and built tools that consume that export. That boundary meant I never had to rebuild aggregation. The tools now cover rebalancing, estimated tax payments, spend analysis, and budgeting.

What shipped

A suite of Python tools covering rebalancing, estimated tax payments, spend analysis, and budgeting. The obvious benefit is that they save me the manual work. The one I did not anticipate is that they let me run each exercise as often as I want, more accurately and in more depth than I otherwise would. That turned out to be the actual value, and it matches what I found using the same tools at work. The real gain was reaching analysis I would otherwise have skipped.

What I would redo

I would have gone back to planning when the scope changed, and I did not. The project started as a rebalancing tool with a clear requirements document. Then the tax work needed richer income data, which made me want to consolidate how all the tools ingested data, which led to building document processing with personal information stripped out. Each step followed sensibly from the last and none of them were in the original plan. I would never have let that happen on a work project, because a conversation with an engineer would have forced a re-plan. Building alone with tools that make the next feature feel almost free, I skipped that step, and I paid for it in refactoring that cost more than the planning would have. The lesson generalizes past this project: when building feels cheap, the discipline that usually protects you is the one you stop noticing you have dropped.