What actually counts as validation

You have an idea. You probably already have a pretty good idea of what you want to build.

That’s where validation gets tricky.

When you can already imagine the solution, it’s easy to start filling in the gaps yourself. You can see how the product could work, explain why people would want it, and even build a first version before you’ve talked to anyone.

Because the idea makes sense to you, the next step can feel obvious: start building.

That’s exactly where you need to slow down.

I’ve spent more than a decade building products for other people. That experience makes this easier in some ways and harder in others.

You get good at making decisions with incomplete information. You also get comfortable trusting your own judgement.

When you’re building something of your own, there is no client pushing back. You’re the designer, the engineer, the sponsor, and the person who gets to say no.

That’s why validation matters, especially when you already have a strong opinion about what you’re building.

What changed

In 2023 I built a whistleblowing product with my team.

A change in the law had just made proper whistleblowing systems mandatory for companies above a certain size. It looked like a very clear market signal: a deadline, a defined market, and a legal requirement to buy something.

We researched the market, looked at existing solutions, talked to potential customers, and built the business case. Then we built the product.

We even sold a few multi-year subscriptions before the law came into effect.

Then nothing happened. The law was never really enforced. No company was fined for ignoring it. A few had already signed with someone else, and the rest simply weren’t worried enough to act.

We had spent more than €20,000, months of development time, and the work of a team before we knew what had happened.

Here’s the part that took me a while to admit: we had validated the demand. We had not validated the reason for it.

Those companies weren’t buying a better way to handle reports. They were buying protection from a penalty. When the penalty never arrived, the demand went with it.

That experience changed how I think about validation.

Today, the cost of building a first version is dramatically lower. I can solve a problem for 1 or 2 customers first, learn from them, and only turn it into a proper product when I have evidence that 10 or more need the same thing, for a reason that will still be there next year.

That doesn’t make validation less important. It changes what you validate before you build.

The test

Here’s the version I use now:

Validation is when someone gives up something they can’t get back.

Money is the clearest version. If someone pays you, you know they value the problem enough to spend money solving it.

But money isn’t the only signal.

Time, effort, access, reputation, or switching away from something they already use can also be real costs.

These are not validation:

• Email sign-ups
• “That sounds interesting”
• Likes, shares, followers, and waitlist numbers
• Friends and colleagues saying they’d definitely use it
• A survey where 80% said they’d pay

These are:

• Someone pays you
• Someone signs a letter of intent or a contract
• Someone gives you 2 hours of their working day and brings their real data
• Someone introduces you to their boss and puts their own credibility behind it
• Someone stops using the tool they use today

The important thing is not what they give you. It’s what it costs them to say yes.

If someone can reasonably pay you, ask for money. If they can’t, ask for a commitment that makes sense for the product.

“So why validate at all?”

This is the objection worth taking seriously.

If you can build a useful first version in a weekend, why not just build it and find out?

There are 2 reasons.

The build isn’t the expensive part

The weekend is cheap. What isn’t cheap is what happens after it.

Once the thing exists, you’re no longer neutral about it. You’ll show it to someone and read their politeness as interest. You’ll decide the onboarding is the problem. Then the pricing page. Then the missing feature.

A weekend build can easily become 6 months of trying to make something work because you’ve already made it.

The scarce resource moved

The constraint used to be money and engineering capacity. Now it is often your time and attention.

If you’re building alongside a job, you may have 10 to 15 hours a week. Those hours don’t scale with AI, and they don’t come back.

You might have time for only a handful of serious attempts in a year.

So yes, the cost of building has gone down. That doesn’t mean the cost of being wrong has disappeared.

What this looked like with DIY Wedding

I built the first version of DIY Wedding at a launch-day competition. It was a cost estimator and a landing page, built in about 6 hours.

124 people joined the waitlist that day.

That number felt good. It was also not validation. Joining a waitlist costs almost nothing.

The day after the competition, I emailed everyone. I asked what they were still struggling with and what was difficult about planning their wedding.

33 people replied.

They gave me a list of very specific problems. I grouped them and prioritised them.

That was already more useful than the waitlist. They had taken the time to think about the question and tell me what was actually difficult.

I then spent 2 days building a service CRM module based on my own Notion wedding planning system.

At that point, we hadn’t even had our own wedding. I was using the same system myself, so building it also helped me organise our own wedding.

But the real question was whether the beta users would take the product further than the budget estimator they had originally signed up for.

They did.

Of the 69 beta testers, 25 started using the product for things beyond the budget estimator.

Those 25 became the group I paid much more attention to. We exchanged emails. They told me what was missing. When I was deciding between 2 features, I asked them which one would be more useful. Their feedback shaped what I built next.

This was not the same signal as someone paying. But it was a real commitment.

They were spending their time on the product. They were sharing their actual wedding planning information. They were answering questions and helping me decide what to build.

That matters because not every product gives you a sensible way to ask for money at the beginning.

I still hadn’t proved that they would pay. I had proved something narrower: there was a group of people who cared enough about the problem to keep using what I was building and spend their own time helping me improve it.

That’s useful evidence. It’s just not the final piece of evidence.

3 tests you can run this week

Each of these costs the other person something. That’s what makes them useful.

Ask for money before it exists. A pre-order, a deposit, or a paid pilot at a price that makes you uncomfortable. It doesn’t have to be much. It has to be real.

Ask for a real commitment. A scheduled hour where they bring their own data. An introduction to the person who holds the budget. A signed letter of intent. Something where saying yes takes effort.

Ask them to stop doing what they do now. Switching is a strong signal because they have to give up something that already works, at least well enough.

If none of these gets a yes, you’ve learned something useful before spending a weekend building.

The question to answer first

Before your next build, answer this:

Who is already spending money or time to solve this badly?

If you can name them and explain what they are spending, you have a starting point.

If you can’t, you’re still guessing.

Guessing quickly is still guessing. It’s just harder to notice because it feels like progress.