Engineers love a job well done. We want to design things that make sense, age well, and feel solid. Shipping something incomplete feels wrong — like bad craftsmanship. It triggers every instinct we have about quality.
So when I discuss milestones and scoping a first iteration with developers, the same pushback appears: “Why don’t we take a bit more time and do it right from the start, instead of releasing something half-baked?”
My answer is simple: I tried that before. Here’s how it went.
About fifteen years ago, I was leading a small but passionate team of engineers at a startup. After spending over a year building what we believed was a revolutionary realtime multiplayer social gaming platform for the web, we were readying for our big release. It was beautifully engineered — scalable, polished, everything built with pride. It was sure to be a success.
Then Farmville launched on Facebook.
They didn’t just beat us to market; they brought a value proposition we never even considered. Microtransactions, addictive loops, a completely different monetization model. While we were perfecting our solution in the void for a year, they were validating their product with millions of players — after just 5 weeks of development. Overnight, our “right” became irrelevant.
That experience etched a lesson in stone: better is the enemy of good, and the market won’t wait for perfect.
The longer you build in isolation, the more expensive your mistakes become — whether it’s because you built the wrong thing, or because someone else built the right thing faster.
This is why we build iteratively. Ship something small and usable. Put it in front of real people. Watch how they behave. Then evolve the solution based on what you learn. Don’t marry your hypothesis — let reality teach you what “right” actually looks like.
And yes, it takes more time and effort than “doing it right” from the start. It’s not the fastest way to build a solution.
But it’s the best way to build the right one.