Imperfection Is the New Lean

I grew up as a waterfall guy. Actually, I was, and to be honest I still am a little bit. Very long Gantt charts, the idea that everything can be estimated at the beginning, even in our world, why not? You define the contract, you respect the contract, and everybody pretends this is how software works.

It was a long time ago, I know. Then came lean, Scrum, sprints, and a lot of other acronyms. We moved from “plan everything” to “iterate,” but somehow we still wanted the clean version of iteration: perfect board, perfect sprint, perfect release. Now I am realizing that I develop every day on the other side of the coin: I accept imperfection.

From perfect plans to imperfect shipping

I remember when ChatGPT came out and I was using it to write something. I copy-pasted the text, then I changed commas, removed hyphens, moved words around because otherwise it sounded AI-ish. I wanted the help, but I also wanted to hide the help. Very human, very stupid, but also very normal.

Now I am all in. Claude Code writes my emails, and to be honest, I don’t care. Or maybe I care every day less. It is not that quality does not matter anymore; I just stopped pretending the first version must look like it came out of a museum. The work is not to protect the first draft; the work is to make the next version better.

And this is how I write software too. If you are vibe coding every day without a team, you cannot behave like you have a big team and six months of ceremony behind you. You move, see what breaks, fix it, move again.

The phone number in production

Last week I shipped something to a customer. Real customer, real software, real usage. They came back and said, “Alex, my personal phone is in the software.” We had agreed to provide another phone number, and there it was, the wrong one, inside the product.

Old me would have suffered more. How did I miss this? Why did I ship it? What does this say about the process? New me fixed it immediately, pushed the fix, and we were done. This is the point: accept imperfection, but never accept sleeping on it.

Because imperfection is not an excuse to be sloppy. If you ship crap and disappear, that is just crap. But if you ship, listen, fix, and ship again, the customer is inside the loop. They use the thing instead of waiting for the perfect version.

Release every day, or every two days

My current rule is simple. Release every day. If not every day, every two days. No more than this one. Especially now, because software moves so fast that waiting too much is almost another kind of bug.

Customers need to use it. They need to test it, touch it, complain about it, ask for the small thing you did not see because you are too inside the product. That feedback is not an interruption; it is the product becoming real. The only way to survive is to keep iterating and keep releasing.

For a solo developer like me, this is not a philosophy written on a wall. It is survival. I have the customer, the code, the feedback, and the next release. This is why releasing in rocket-ship mode is not a slogan. It is how I avoid dying under my own process.

Big companies should try this too

I strongly hope big companies accept this one too. They have more budget, more people, more structure, more reasons to say “we need to be careful.” And yes, they do, but sometimes careful becomes slow, and slow becomes nobody cares anymore. Imperfection is not the opposite of quality; it is where quality starts when you iterate fast enough.