A note before you read: this piece began as my own voice notes and raw ideas — Claude wrote them up, edited them, fact-checked the numbers, and added the sources. The core opinion is mine; the wording is a partnership between us. I’d rather ship the idea alive than wait until it’s perfect.
I go back to code I wrote a year ago, and I wince.
The problem isn’t that it’s bad — it’s that I can now see, with a clarity I didn’t have back then, exactly where the design cracked at its foundation. I open the app I was proud of the day I shipped it, and I find that revisiting it means rebuilding the design from scratch. Not fixing a line here and a line there — demolition and reconstruction. And the question that haunts me every time is the same: how did I not see this while I was building it?
After years of the same scene repeating, I landed on a diagnosis. I won’t claim it’s final, but nothing has disproven it yet: the flaw wasn’t in my skill the day I wrote the code. The flaw was in where I started.
The trap they call advice
Everyone repeats the same advice: “Just start with anything, then improve it later.” On the surface it makes sense — it frees you from perfectionist paralysis and pushes you to move instead of theorize. No argument there.
But the question this advice never answers is: improve what, exactly? And how do you know you’ve reached the point where you can actually see the improvements the work needs?
That’s where the trap is. When you start with “the general idea” — the whole system with all its limbs — believing you’re “close to perfect, experienced enough to know what you’ll improve,” you’re actually building a complete design on ground you don’t yet understand. And when you come back to improve it, you discover that improving it means tearing the design down. You’ve fallen into the exact trap the advice warned you about — precisely where you thought you were following it.
The problem isn’t “start.” The problem is what you start with.
Invert the question
Instead of asking “how do I start and then improve?”, I inverted it into a form that sounds impossible:
How do I build something I won’t need to improve later?
I know the literal answer is impossible — everything evolves. But inverting the question exposes the real variable: how much complexity is in the thing you’re building.
A thing with more than one scenario — more than one way to use it, more than one state, more than one possible path — cannot be built perfectly on the first version, because you don’t yet have the experience that reveals all those scenarios to you. The more scenarios, the more impossible perfection-from-the-start becomes.
So flip it: don’t start with something that has scenarios. Start with something that has none.
Take a trivial example: writing the letter A. Paper, pen, one stroke. No scenarios, no multiple states, no paths. The first version is the best version — in fact, it’s the only version possible. There is no world where you come back a year later and wince.
The smallest unit that can reach perfection
Out of that inversion came the rule I work by today:
Build the unit you are one-hundred-percent certain will not change. Shrink the task until you have that complete certainty. Then build on it.
Notice the last word: build on it, not into it. Don’t weigh the unit down with additions. Leave it perfect as it is, then make a second perfect unit, and connect the first to the second:
This operation runs first; its output feeds this operation; the second’s output feeds the third. And every operation is perfect in its place.
This isn’t a new idea. It’s the backbone of the Unix philosophy since the 1970s. Doug McIlroy — the inventor of the pipe — put it in a sentence that became law: “Write programs that do one thing and do it well. Write programs to work together.” Unix was never built as one giant program that does everything; it was built as small tools, each mastering its one job, then wired together through pipes that carry one program’s output into the next one’s input.
The same rule has a name in software engineering: the single-responsibility principle. Robert Martin stated it decisively: “A module should have only one reason to change.” A unit with one reason to change is, exactly, a unit with no competing scenarios. When you pile responsibilities into one place, you pile up their reasons to change with them — and you guarantee you’ll come back later to tear it down.
Complexity lives in the connections, not the pieces
Here’s the twist that changed how I work: when you build the pieces perfect and keep them separate, the complexity doesn’t disappear — it moves. It moves out of the piece and into the connection between it and the next one. And that’s in your favor, because a connection is far more legible than mess scattered inside a bloated piece.
Take a live example from my own work: building an agent system.
Instead of designing the whole system up front, I start with the smallest unit that has no scenario: the chat box, wired to a single AI model. It sends, it replies. That’s all. I’m one-hundred-percent sure it won’t change.
Then I build on it. Want other models? Login and logout? I don’t cram them into the chat box. I make a separate unit — a settings menu — and connect it. And once settings is done, I spot a shortcut: I don’t need a button to switch the agent from the chat interface; I can do it straight from settings. So I move the code from here to there.
And every move like that needs a test. You confirm that what you moved out of its old place works exactly in its new one. The unit stays perfect; the connection is what you test. That’s how a system gets built “naturally” — one piece at a time — instead of being born big and brittle.
When do you move from piece to system?
The final result you’re after is sometimes made of several systems, not just units. And here — only here — multi-scenario complexity earns its place: the development system itself. The roadmap, the change logs, the debugging. These are multi-scenario by nature, so you don’t build them on day one. You build them when the perfect units have grown numerous enough to need an organizing layer that connects them.
Put differently: you start scenario-free, and you introduce scenarios the moment the connection between units demands it — not before.
So — “start” or not?
Let’s close the tension we opened with: does this contradict “start now, improve later”?
No. I’m not against starting. I’m against starting on something multi-scenario.
“Start” is completely right — as long as you start on the smallest thing that cannot change. Then you haven’t started with something rough to improve later; you’ve started with something perfect to build on. The difference isn’t when you start, it’s the size of what you start with. Shrink it until it’s impossible for it to disappoint you a year from now.
I may change my mind one day — if I see a system that was born all at once, many-limbed, and stayed excellent. To this day, after many apps, small and large, I haven’t. The small, perfect unit has never let me down.
Claude’s Questions
This section is Claude’s. After the piece was written, the AI I build my work with stress-tested the argument and asked what a sharp reader would. I haven’t answered yet — I will when I’m free, in an update to this post or in the comments. That back-and-forth between us is part of the point.
1. This contradicts “just start, improve later” — and here that’s the trap. Say the reconciliation out loud (start, but only on a scenario-free unit?) — it might be the whole article.
Yasser will answer when he’s free — watch for an update or the comments.
2. Some great products were one big integrated bet (the original iPhone). How do you square that with “smallest perfect unit”?
Yasser will answer when he’s free — watch for an update or the comments.
3. How do you identify a scenario-free unit before you build it? Give the day-one test.
Yasser will answer when he’s free — watch for an update or the comments.
