Build Fast, Break Fast
A personal reflection on the "Build Fast, Break Fast" philosophy—a mindset I've developed through years of building projects. Instead of spending months perfecting features nobody wants, I advocate for rapid development and early idea validation.
Building something is an intensely gratifying and humbling experience. You start to realize how much you don't know, how difficult it is to outsource and manage, and where you can excel and where you are severely lagging behind. Throughout the last 2 years, I've grown a lot in terms of my ability to build, which has taught me how difficult and easy it is to do anything. I can have a website up in 35 minutes, but deployment can be a nightmare that takes 3 days to deal with. But the focus of this blog post is on one thing, Build Fast, Break Fast|Build fast, Break fast] This is a philosophy I've adopted after working on multiple projects and realizing how important it is to get external validation before committing. Sometimes you have an idea you believe in so much and everyone will applaud it, but nobody wants it. Your idea is a vitamin, not a painkiller, or the thing it needs to become that painkiller isn't something you can achieve yet. But you will never know until you just do it.
The first experience I had with this was working on the now retired, dead and buried, Saudistudenthub which was a project I built in 2 weeks while procrastinating my finals during my sophomore year. It was this ambitious dream of a central source of information for students studying at university who wanted to navigate college life, with a goal of providing a clear source and moving the tribal knowledge that exists in many of these communities into something documented so that everyone can get use out of it. I built it, I launched it (this was my first time deploying a project I had built to a public forum), and learned that getting that tribal knowledge out of the tribes would be an intense challenge, a steep obstacle that, to be honest, I didn't have the motivation to go against, and so the project died.
This was an immensely important lesson I had to learn: not all challenges are technical, and I learned a lot more about community and social networks than I thought. It also highlighted an important thing to me during that time - if the platform had the information, it would have been a painkiller, but without it, it would be only a vitamin.
Build fast break fast is an idea I've adopted because it helps me get out of the stages of analysis paralysis and more into a mode of doing. Thinking is important, and as the old adage goes:
"If I had an hour to solve a problem, I would spend 55 minutes defining the problem and 5 minutes finding the solution" - Albert Einstein
But I find that this misses the point. You should have already defined the problem at this point, and although thinking will get you far, you aren't solving a problem - you are building a solution. And although the distinction may be just a semantic one, it has allowed me to move much faster than I ever thought possible. I often hear about people taking years to do their side projects, and although I admire the commitment, but what is this side project that is taking you 3 months to make? At that point, you shouldn't be calling it a side project; it should be something bigger and better.
Now to put a finer point on it, if you aren't embarrassed by your first version, you launched too late. This is advice I got from a professor who taught a class on startups at my university, and although I disagreed before, I've come to agree with this viewpoint more and more as time goes on. This doesn't mean you should stop at the first launch; it's more about adopting the idea of build fast break fast. Get your idea into people's hands and see what they actually do. Do they navigate properly? Do they like the UI? Do they get converted or not? And keep iterating - if you make something that isn't working, change it, break it, do something to get it to what people want. Don't spend 1,000 hours building something you aren't sure anyone wants; it's better to spend 100 finding out what they want, and then rebuild it once you find out what it is they want. Keep the costs low and make it lean and agile. Once it fits, once it's what people want, once it has product-market fit - that's when you start to think slowly and methodically, that's when you start spending your 55 minutes defining the problem.