As a serial builder and entrepreneur, I have had more than my fair share of failed launches. Products I was sure about, features I thought were genius, things I spent months on only to realise that nobody cared (or at least not as much as I did). I still build a lot, now more than ever with the increasing aid of AI, but without guardrails that just means I’ll fail more times in the same timeframe. And that’s exactly the point — the speed at which we can now build things has made it even more important to know what to build.
The build trap
There’s a very common misconception among builders (specially technical ones, which includes me) that if you build something great, people will naturally want it. “Build it and they will come” sounds nice, but it’s dangerously misleading. It’s not because you made something that your clients will enjoy it, use it, or pay for it. The gap between what you think is valuable and what people actually need is almost always larger than you’d expect, and closing that gap is the real job.
The temptation is to go heads-down, build the full vision, and launch it to the world. I’ve done this. More than once. And more than once I’ve had to sit with the realisation that I should have talked to people first.
Start small, iterate fast
The antidote is painfully simple and yet most of us (again, myself included) resist it: start small. Find your unique selling points, test them in the smallest possible way, gather feedback, and iterate fast. A/B testing, user conversations, even just showing a prototype to five people before writing a single line of production code — all of these things feel like they’re slowing you down, but they’re actually saving you from building the wrong thing faster.
The keyword here is “fast.” Not fast as in rushing, but fast as in short feedback loops. The quicker you can go from idea to validation (or invalidation), the less you waste and the more you learn.
Small picture, big picture
This is something I’ve had to learn the hard way. While the picture is small, one can iterate fast — change direction, throw things away, start over. The big picture can remain the same, but it can also change completely, and that’s fine as long as you’re still in a position to change. If one is not able to adapt even the small picture, it will be impossible to change the big one when the time comes.
Some of the best companies in the world started as something entirely different. Airbnb started as a way to rent air mattresses to conference attendees. The big picture changed completely, but because they stayed small and adaptable long enough, they were able to find what actually worked. Most of us are not building the next Airbnb, but the principle is the same — stay flexible while you figure out the real value.
The technical cost of pivoting
This is something that doesn’t get talked about enough, specially in the startup world. Adapting or pivoting has a very real impact on the technical side of things. It’s easy to make things complicated, it’s incredibly hard to make things simpler. And one can always add complexity as things move forward, but once you’ve found “the spot,” going back to simple is brutal (and expensive, and slow).
This is where balancing between future-proofing and being reasonable becomes critical. Over-engineer too early and you’ve wasted time on infrastructure for a product that might not survive. Under-engineer and you’ll pay for it when things need to scale. The answer, as boring as it sounds, is to stay as simple as possible without compromising the core value proposition. Complexity should be earned, not assumed.
Time to market
At the end of the day, none of this matters if you never launch. Time to market is real, and specially in competitive spaces, being first (or at least early) with a validated solution beats being late with a perfect one. The balance between getting it right and getting it out there is one of the hardest things to calibrate, and honestly, I’m still calibrating it myself.
The difference now, with AI accelerating everything, is that the cycle can be much shorter. Build, test, learn, repeat — and do it in days instead of months. But the fundamentals haven’t changed. You still need to talk to people, you still need to validate, and you still need to be honest with yourself when something isn’t working. Speed without direction is just expensive failure on fast-forward.