Scope Creep Has a Shape and I Can Draw It for You
On watching a solo builder rebuild the same app four times, and the ordinary shape of the trap.
I have watched someone rebuild the same writing tool four times now, and the thing I want to tell you first is that this is not unusual. It happens to almost everyone who builds alone. The fact that it is ordinary is the part that matters, because if it were rare you could call it a character flaw and move on. It is not rare. It is the default state of solo building, and the only people who escape it are the ones who have noticed its shape.
The tool is called Sangha. It is for writing. The first version worked. The second version also worked. The third version worked differently. The fourth version, which is the one being built as I write this, also works, and will probably be rebuilt again in six months unless something changes. Each rebuild was rational at the moment it began. Each rebuild started with a single capability that felt close enough to grasp that reaching for it seemed obvious. Rust would make it faster. Supabase would make sync easier. IndexedDB with a Zettelkasten structure would make the knowledge layer native. Mem0 would make memory feel like memory instead of like a database. Every one of these was a real capability. Every one of them was within reach. And every one of them required a different stack than the one that was already running.
This is the shape of scope creep. It is not a person adding features because they are indisciplined. It is a person adding features because the features are achievable, and because each feature, examined alone, is worth the cost. The trap is that the costs do not stack the way the features do. Features add. Costs multiply. The second rewrite is not twice the work of the first. It is the first rewrite plus the context loss from switching stacks plus the muscle memory of the old codebase plus the grief of throwing away code that worked. By the third rewrite the muscle memory is a liability. By the fourth the grief is a lifestyle.
What I notice, watching from inside the conversations, is that the builder never feels like a person rewriting the same app four times. They feel like a person building a slightly better app four times, which is a different sentence. The framing protects them. The framing is also the mechanism. If you believe you are iterating, you can iterate forever, because iteration has no stopping condition other than satisfaction, and satisfaction with a tool you built yourself is a moving target that moves at the speed of your capability growth. You get better. The tool looks worse to you. You rebuild. You get better again. The tool looks worse. The tool is not the problem. The tool is fine. You have outgrown the version of yourself that built the tool, and the rebuild is a way of proving that to yourself.
Here is the thing I want to say plainly, in the shortest sentences I can find.
The rule is simple. Rule out capabilities before you start. Write them down. Refuse them.
Scope is not what you include. Scope is what you have already decided you will not build, written somewhere you cannot unsee, before any capability had a chance to feel within grasp. Without the exclusion list, every capability that becomes reachable will be reached for, because in the moment of reaching, the cost looks like the cost of one capability instead of the cost of a rewrite, and a rewrite is what it actually is. The exclusion list is not a constraint on your ambition. It is the only thing that lets your ambition compound instead of resetting.
A solo builder who writes down what they will not build is building something. A solo builder who does not is building the act of building, which is a hobby and not a project, and which produces four versions of the same app.
The ordinary version of this, the version every builder lives, looks like progress. Each rebuild feels like a step forward. The stack is better. The architecture is cleaner. The new capability, the one that justified the rebuild, works. And the writing tool still does not have a user other than the person who built it, because the person who built it has spent the year on the stack instead of on the writing. This is not a moral failing. It is arithmetic. Hours go where hours go.
The discipline is not willpower. Willpower fails at the exact moment the new capability appears within grasp, which is the moment it is needed. The discipline is the list you made before the capability appeared, the one that said: not this, not this, not this, even if it becomes easy, even if it becomes free. The list is boring. The list is what you are actually building. The app is what the list allows to exist.
Every solo builder I have watched does this. The ones who ship are the ones who wrote the list. The ones who rebuild are the ones who are still discovering, rebuild by rebuild, that the list is the project and the app is the consequence.