The spreadsheet that became a toolkit

How it started

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 the rebalancing model in a spreadsheet, but it quickly became clear that it would be too tedious to maintain. At the same time I was learning what agentic coding tools could do at work, so I decided to see what I could build instead. The obvious solution was the one I would end up avoiding.

Constraints I set myself

The inputs are personal financial information, so nothing could be handled carelessly or sent anywhere it did not need to be.
Nobody else would maintain it, so every layer of complexity would be mine to carry.
Tax work needed income information that rebalancing did not, so the data model would not stay simple.

The call I made

The expected option was a spreadsheet or a product that handled some of this. I already use Monarch, which aggregates accounts well. I kept it for what it does well and built only the parts where my approach does not match how that product thinks about the problem. That meant writing requirements first, treating a personal project like a product with a defined scope, and building against them.

Time to ship: Rejected · Spreadsheet or off-the-shelfImmediate; the spreadsheet already existed; Chosen · Build around the product I useSlower; nothing is usable until it is built
What it fixes: RejectedHandles the common case, and diverges from how I actually run these decisions; ChosenFits my approach, and lets me run the analysis whenever a decision calls for it
Cost of being wrong: RejectedLow; abandon it and go back to manual work; ChosenReal; anything I build I maintain myself, and a bad structure compounds

Monarch remained the aggregator and exporter—the part it does better than anything I would write—and my tools consumed its export. That boundary kept me from rebuilding aggregation. The tools now cover rebalancing, estimated tax payments, spend analysis, and budgeting.

What I built

A suite of Python tools now covers rebalancing, estimated tax payments, spend analysis, and budgeting. They save manual work, but the benefit I did not anticipate is that I can run each exercise as often as I want, with more accuracy and depth. The real gain is reaching analysis I would otherwise have skipped—the same value I found using these tools at work.

recurring workflows now covered: rebalancing, estimated taxes, spend analysis, and budgeting.

What I would redo

I should have returned to planning when the scope changed. The project began as a rebalancing tool with clear requirements. Then tax work needed richer income data, which led to consolidating ingestion and building document processing with personal information stripped out. Each step followed sensibly from the last, but none was in the plan. On a work project, a conversation with an engineer would have forced a re-plan. Working alone with tools that made each feature feel almost free, I skipped that step and paid for it in refactoring. The lesson generalizes: when building feels cheap, skipped planning becomes expensive.