Building Before You Understand Is Expensive

There is a certain kind of advice that has become almost impossible to avoid in technology. Build quickly. Ship early. Learn from the market. At first glance, it makes perfect sense. A product that never leaves the drawing board can never improve, and waiting for perfection is often another way of avoiding the difficult work of putting an idea into the world.

I have found myself agreeing with that advice less than I used to, not because speed has become less important, but because I have started to notice that many of the problems we blame on slow execution actually begin much earlier. They begin with building something we never fully understood in the first place.

The difference is subtle. Two teams can move at exactly the same pace, yet one spends the following months refining an increasingly coherent product while the other becomes trapped in an endless cycle of revisions. From the outside, both appear equally productive. From the inside, one is building on understanding and the other is building on assumptions.

That distinction has become more obvious to me with every project I have worked on. There is always a moment when an idea feels complete enough to implement, and it is remarkably tempting to treat that feeling as evidence that the thinking is finished. More often than not, it simply means the idea has become familiar. Familiarity creates confidence, but confidence is not always the same thing as clarity.

One of the most useful habits I've developed is learning to pause just before implementation and ask a simple question: Do I understand this well enough to explain why every part of it exists? The answer is surprisingly often "not yet." What follows is rarely a dramatic redesign. It might be a small adjustment to the structure, a clearer definition of the problem, or the removal of a feature that looked useful until it had to justify its place. None of those decisions feels particularly significant on its own, yet together they change the direction of the entire project.

Looking back, I've realised that planning is often misunderstood. People imagine it as something that delays progress, when in reality it simply changes when you discover your mistakes. Without planning, those mistakes still exist. They just remain hidden until they have become part of the product, where changing them requires considerably more time, effort and compromise than it would have at the beginning.

That is why I have become cautious whenever someone celebrates speed as though it were a goal in itself. Speed is valuable, but only when it is taking you in the right direction. Moving quickly towards an idea you have not fully understood is not momentum; it is simply shortening the distance between today's assumptions and tomorrow's problems.

Perhaps that is the real value of understanding. It does not slow the work down. It gives the work direction. Once the destination becomes clearer, progress stops feeling like a race to finish and starts becoming a process of building with greater confidence, knowing that each decision rests on a foundation that has already survived careful thought.

When I think about the projects that have taught me the most, I rarely remember how quickly they were built. What stays with me is the time spent asking better questions before building began, because those questions quietly shaped everything that followed.