Why building first is the expensive bet
The default failure mode for new products is building something well that nobody needed. Code feels like progress, so founders reach for it to avoid the harder, more honest work of asking strangers whether they care. By the time the product is done, you have spent the one resource you cannot get back. Validating first is not about being timid, it is about spending your months on the right thing.
What 'validate first' actually means
It does not mean a long research phase. It means confirming three things before you write real code: the pain is real and frequent, your target buyer is reachable, and people will take an action, not just nod along. You get there with customer conversations and a small demand test like a landing page or a pre-sale. A week or two of this is usually enough to decide.
The honest exceptions
Sometimes building is the fastest way to learn. If you can ship a rough version in a weekend, the build itself is the test, and overthinking validation wastes time. The same is true if you are your own first customer and feel the pain daily, since you already have one validated user. These exceptions are narrow. If the build is weeks of work or the buyer is not you, validate first.
How to tell which camp you are in
Ask one question: is building cheaper than asking? If a usable version takes a weekend, build it and watch what happens. If it takes a month or more, or the buyer is hard to reach, the math flips hard toward validating first. Founders who skip this step almost never save time. They just find out later, after the expensive part.