Throughliner is a method for driving an AI through a build. What it is not is a method for building software specifically — that's just where people expect it to be used, because it runs inside a coding tool.
The thing a coding tool actually gives you has very little to do with code. It gives you files you own, sitting on your own machine. It gives you a record of every change and why it was made. It gives you an assistant that can read all of it back. Plenty of work wants exactly those three things and produces no software at all.
Here are five of mine. They're all projects where I'm the only person involved, which is deliberate — I'll come back to why at the end.
1. A tax setup
What it was
Getting my tax affairs in order: working out what applied to me, what I needed to have, what I'd been putting off, and in what order any of it could actually happen.
Why a coding tool suited it
Tax is a dependency problem wearing a paperwork costume. You can't do step four until step two lands, step two is waiting on a document, and the document needs an identity check you haven't passed. That's a queue with blockers in it, which is precisely the shape a work queue handles and a to-do list doesn't. And every time I picked it up after weeks away, the record told me where I'd got to and why I'd stopped — which is the whole reason it kept stalling before.
What it produced
Not a program. A tracked sequence of real-world steps, each carrying the reason it was needed, and a written account of the routes that had already failed so I'd stop retrying them.
2. A Google Drive clean-up
What it was
Years of accumulated files, in folders that made sense at the time, with no way to tell what was safe to delete.
Why a coding tool suited it
Two reasons. The obvious one is that an assistant with access to the filesystem can actually look — at what's there, what's duplicated, what hasn't been opened in years — instead of asking me to describe it. The less obvious one is that a clean-up is a series of irreversible decisions, and irreversible decisions want a record. Six months later, "why isn't that folder here any more?" has an answer.
What it produced
A structure I chose on purpose rather than one that accreted, and a written trail of what was moved, merged or removed and on what grounds.
3. Managing an AI's own instruction layers
What it was
The instructions that shape how Claude works with me — the standing rules, the per-project ones, the things it should remember across sessions. This is the most recursive project on the list: a project whose subject is how the assistant behaves, run using the assistant.
Why a coding tool suited it
Because those instructions are files. They're text on disk, they contradict each other in ways you only discover by reading them together, and they change meaning as the tooling underneath them changes. Treating them as a project — with a spec saying what the layers are for, a queue of changes, and a log of why each rule was added — is the difference between a rule set you maintain and one that quietly rots.
What it produced
A maintained set of instruction files, each rule carrying the reason it exists, so a rule that stops earning its place can be found and removed rather than surviving by inertia.
4. A clothing-marketplace business plan
What it was
Thinking through a business idea properly: what it would be, who it would serve, what would have to be true for it to work.
Why a coding tool suited it
A business plan is mostly a stack of decisions with reasons attached, and the reasons matter more than the decisions. What kills a plan written in a document is that you revisit an option three months later, feel clever about it, and can't remember that you already rejected it and why. A method that carries the rejected alternative with its reason for losing is worth more here than in most software projects.
What it produced
A plan where every settled question shows its working, and where going round in circles is at least visible when it happens.
5. A transit-data tool
What it was
The one on this list that genuinely is software — included precisely because it shows the range. Working with public-transport data to produce something usable by colleagues who are not technical at all.
Why a coding tool suited it
For the ordinary reasons. But it's worth noting what it has in common with the other four: the hard part was never the code. It was knowing what the thing needed to do, for whom, and being able to reconstruct that months later when someone asked for a change.
What it produced
Working tools, used by people who'd never open a terminal.
The pattern, and the one rule I kept
Four of those five produced no software. What they had in common was a body of decisions that mattered, taken over months rather than in one sitting, by someone who would forget the reasoning long before the work was finished.
That's the actual test for whether a project belongs in something like this. Not "is it code?" but: will I need to know why, later?
And the rule I mentioned at the top. Every project here involves nobody but me. I have other projects that would make more striking examples — one of them considerably more striking than anything above — and they involve other people, whose situations are not mine to put on a website. A project's details can identify someone even when their name is nowhere in the text. So the striking example stays unwritten, and these five do the job.
If the pattern is familiar and you want the structure that holds it together, that's Throughliner.