# What founders should validate before building
Most early products don't fail because the code was wrong. They fail because the founder validated the wrong thing, or nothing at all.
- Author: Radwan Altaf (https://radwanaltaf.com)
- Published: 2026-04-18
- Topics: Startups, Product
- Canonical URL: https://radwanaltaf.com/writing/what-founders-should-validate-before-building
---
"Validation" has become a ritual, a few interviews, some encouraging nods,
then straight into building. But nods aren't evidence. Before committing months
of engineering, three specific claims are worth testing.

## 1. The problem is expensive enough to pay to remove

People will agree a problem is annoying. Far fewer will pay to make it go away.
The test isn't "would you use this?", everyone says yes to be polite. It's
"what do you do about this today, and what does that cost you?" If the honest
answer is "nothing, it's fine," there's no product yet.

## 2. You can reach the buyer repeatably

A product with no path to its customer is a hobby. Before building, find one
channel you can use again and again. If the only way you can imagine getting
customers is "go viral" or "we'll figure out sales later," that's the risk to
test first, not the feature set.

## 3. The first version is small enough to actually ship

Founders routinely validate a vision and then build the vision. The thing to
validate is the *smallest* version that delivers real value to one type of user.
If you can't describe that version in a sentence, you're not ready to build it.

## What this looks like in practice

- Replace "would you use this?" with "show me how you do this now."
- Try to *sell* the thing before it exists, a pre-order, a paid pilot, a
  deposit. Money is the only honest signal.
- Write down the one metric that would tell you the MVP worked, before you build
  the MVP.

## The counterargument

"Some things can't be validated without building them." Occasionally true, deep
technical bets, genuinely new categories. But even then you can usually validate
the *problem* and the *reachability* cheaply, and reserve the expensive,
unvalidatable part for last. The goal isn't to eliminate risk. It's to spend
your build budget on the risk that's actually worth taking.