Four Rebuilds: What Finally Made BudgetFox Stick

On the 4th of July, 2026, I started BudgetFox again.

By the end of that single day I had a working application: bank accounts, contacts, a first pass at importing bank statements, an admin area. More working software than the previous nine months of attempts had produced put together.

I want to be precise about why, because the answer is not “I finally picked the right tools.”

More attempts than I care to count

Four attempts got as far as real code. October 2025. December 2025. May 2026. And the one in July that stuck.

Before those there were others that never reached a keyboard. A spreadsheet that grew until it collapsed under itself. An evening of notes. A weekend of sketches. A couple of false starts I did not bother keeping. I had stopped counting long before I started writing anything down.

The uncomfortable part is what I wrote at the very beginning. Before a single line of application code existed, I had already written a document describing exactly what BudgetFox does today: every transaction recorded as a movement between two accounts, so the books can never quietly disagree with the bank. Beside it sat a database design with the accounts, budgets, and reconciliation tables the finished product now uses.

The idea was right on day one. It then took three abandoned attempts to build it.

What actually stalled each one

The first drowned in plumbing. It opened well. Careful thinking about how entries should be recorded and how a bank statement should be matched against them. Then I chose a way to store the data, spent weeks wiring it in, decided against it, and spent more weeks tearing it out. The last work I ever did in that codebase was deleting the thing I had spent the month adding.

The choice, for anyone who wants the specifics, was between a managed data platform and a conventional database layer of my own. Both would have worked. Neither of them was the product. The ledger, which is the product, was never built.

The second never left the front door. Two days of work: a login page, a database running locally, sign-in, redirects. Every piece of it was scaffolding. The app had a perfect entrance and no rooms. By the time the interesting work came into view, the energy was gone.

The third had the right instinct in the wrong order. It started with a chart of accounts, ten numbered requirements each tied to a named test, and a test-coverage report configured before there was anything to cover. That is genuinely good practice and I still work that way. But the last two things I did in it were simplify the interface, and then simplify it again. I was polishing the surface of a system that could not yet do anything. Two days, and it stopped.

Three failures with one shape: I kept rebuilding the shell and never reached the core.

The two reasons underneath

Neither of them was technical.

The first was time. These attempts were made in the gaps. An hour on a weeknight, half a Saturday if it went well. Work that fits in an hour is decorating the shell; the ledger needs a proper run at it. And the gaps between sessions were long enough that I would come back to a codebase I no longer remembered. A codebase you no longer remember feels easier to restart than to resume. That is the entire loop, and I went around it many times.

The second was hyperfocus on detail. I can lose a full evening to which validation library is marginally the better choice, or to the spacing on a screen nobody has ever used. It feels like progress because it is work, and it is careful work. It is just not the work. Three of those attempts died with real craftsmanship in them and no product.

What got me past that was not more discipline. It was removing the opportunities.

What was different in July

The tooling decision was made once, and written down. The project’s setup is a single command that recreates the entire foundation: the framework, the language, the formatting, the tests, the database layer, sign-in, all configured together. Not a list of choices to revisit. One line, reproducible.

The point is not that this set of tools is better than the previous three. It is that the question was closed. The earlier attempts spent most of their lifespan relitigating it. This database or that one. This validation library or that one. Every one of those is a defensible choice, and none of them were the project.

The design existed before the code. I mocked up the whole application first, then handed the prototypes over as a single bundle: the import wizard, reconciliation, the budget grid, member roles, invitations. When I sat down on the 4th of July, I was not deciding what to build. I was building.

Design is not a delay before development. It is development, done in a cheaper medium. It is also the one place where hyperfocus is harmless. An evening lost to layout in a mockup costs an evening. The same evening lost in a codebase costs a rebuild.

AI made the spare hour worth something. The parts I used to lose weeks to, the wiring and the boilerplate and the fourth version of the same form, now take minutes. That changes what an hour is for. An hour can reach the ledger instead of the shell.

It also defuses the detail trap. When I want to see two versions of something, I can look at both and throw one away the same evening, rather than picking one, building it out, and then defending the choice for a month.

The guardrails were explicit, and enforced. Working quickly produces volume. Volume without a gate produces a codebase you stop trusting, and a codebase you stop trusting is a codebase you abandon and restart. Which is, of course, exactly what I had done three times.

So the project carries its rules in writing. Simplicity first. Small, surgical changes. Respect the structure that is already there. Define each shape of data once and derive everything else from it. And a gate that has to be green before anything counts as finished: type checking clean, linting clean, the full test suite passing, every line and branch covered. Nothing goes in around it.

I built the ledger, not the login. The accounting engine went in during the first fortnight: entries, the balance check that refuses anything that does not add up, split transactions, opening balances, reconciliation. Sign-in came from a library and I barely thought about it. In the second attempt, sign-in was the project.

The honest accounting

BudgetFox is deployed on its own domain, with 234 tests and that coverage gate still holding. It reconciles a bank statement against the ledger, imports statements and catches duplicates before they land, and renders an annual budget grid with variance against plan.

None of the earlier attempts could do any of that. Two of them had more hours in them than the fourth did, and less to show for it.

What I would tell myself in October 2025: your document is right, your schema is right, and you are about to spend nine months not building either of them. Pick your tools in an afternoon, close the question, protect one proper run at the hard part, and write the piece only you can write.

The framework was never the problem. The framework was where I went to avoid the problem.