The spreadsheet that eliminated debt in five months — and what it taught me about system design

The spreadsheet had three columns: label, amount, balance. SUM formulas. No macros. No automation beyond basic arithmetic. It looked like a training exercise.

In 2023, this spreadsheet ran a monthly rhythm that eliminated credit debt in five months. Not because it was clever. Because the habit underneath it ran without willpower.

What followed is what I found.

The Setup

There was income and a credit balance. The standard developer response to debt: build a better tracker. Categorize everything, visualize the trajectory, optimize the payoff schedule.

I did not do that. I built a progressive allocation system instead.

Every income payment divided through three containers by fixed percentage: necessities, debt repayment, everything else. The percentages never changed. Month one: same as month two, month three, month five. Income arrives, percentages execute, debt receives its fixed share.

No optimization. No decisions after setup. The spreadsheet tracked what was happening. That was all it did.

How It Worked

The system required no daily attention. Income arrives, numbers go into the spreadsheet, allocation runs. Three steps. Same process every time.

The feedback loop was the shrinking debt balance. Not gamification, not notifications. Just a number moving in the right direction. Month by month the balance fell. Month five: zero.

The spreadsheet was the UI. The system was the behavior underneath.

What This Reveals About System Design

The gap between the tool and the system is the gap between what you see and what makes it work.

Most finance apps try to be better tools. Better categorization, smarter dashboards, fancier visualizations. They solve the wrong problem. The problem is not how to make money management more elegant. The problem is how to make it run without the user having to think about it.

The spreadsheet worked because it encoded a behavior I had already proven could run without supervision. An app would have failed in the same way most apps fail: it would have asked me to start something instead of amplifying something already running.

This is the same problem space as software architecture. You can build a system that requires constant intervention, or you can build one that runs. The difference is not the technology. It is the design decision about where the behavior lives.

The Principle

Build the habit first. Prove it runs without willpower. Then encode it.

If you productize before the habit exists, you are building infrastructure for a behavior that has not yet been proven. The spreadsheet worked because the allocation behavior was already functioning. The tool held a shape that had been filled with something real.

This applies to invoicing pipelines, deployment systems, content workflows. The principle is the same: products encode habits. When the habit comes first, the product amplifies it. When the product comes first, it holds a shape with nothing inside.

The behavior is the code. The tool is just where it runs.

Cross-posted from The System Builder blog. This is the first piece in a series on building systems that work without you.