Validate Before You Build: Check Your Idea Before Writing a Line of Code
Validate Before You Build
There's a special kind of heartbreak in shipping something nobody wanted. You spent three weeks. It works. It's even kind of nice. And the world responds with total silence.
The fix isn't building faster. It's checking — before you build — whether the idea has a pulse. With AI making the building cheap, validation is now the part that actually decides whether you succeed.
What validation is not
It's not asking your friends if they'd use it. They'll say yes because they love you. "Would you use this?" is a question that gets a polite lie every time.
It's not building the whole thing "to see if it sticks." That's not validation — that's gambling with three weeks of your life.
Validation is finding evidence that a real person, who isn't your mom, has the problem you think they have — and already tries to solve it somehow today.
The core test: do they already pay (in time or money)?
The strongest signal is that people are already spending something to solve this problem. Time, money, or an ugly workaround.
- Someone keeping a messy spreadsheet means the problem is real enough to do manual work.
- Someone paying for a clunky tool they complain about means there's money and dissatisfaction.
- Someone asking "how do I do X" in forums every week means demand without a good answer.
No workaround at all usually means no problem. People route around things that actually hurt.
Three checks you can do this weekend
1. Go where they complain
Find the place your user already hangs out — a subreddit, a Discord, a Facebook group, a niche forum. Search for the problem in their words, not yours.
You're looking for repeated complaints. One person is an anecdote. Ten people saying the same thing in different threads is a market.
2. Talk to five of them
Not a survey. A conversation. Message five people who complained and ask about the past, not the future:
"You mentioned X is a pain — what did you do about it last time?"
Past behaviour is real. Future intentions ("yeah I'd totally pay") are fiction. Listen for what they actually did, what they tried, and where they gave up.
3. Make a fake front door
Put up a one-page site describing the product as if it exists. One clear promise, one button: "Get early access." Share it where your users hang out.
If people click and leave an email, you have interest. If nobody clicks, you just saved yourself three weeks. The email list is a bonus — those are your first users.
Reading the signal
You're not looking for a stampede. Early validation is quiet. What you want is specific interest:
- People describe the problem back to you in more detail than you gave them.
- Someone asks "when can I use it?" unprompted.
- A stranger shares your fake door with someone else.
Lukewarm politeness is a no. Specific, slightly impatient interest is a yes.
When validation fails — that's a win
If you do these checks and the idea is hollow, you didn't fail. You just learned something for the price of a weekend instead of a month. Most ideas don't survive contact with real people, and that's normal — the skill is killing the weak ones fast so you have time for a strong one.
The goal of a vibe coder isn't to build a lot of apps. It's to build the right one — and validation is how you find out which one that is before you fall in love with the wrong idea.

Editor · Solo founder · KODIQ
Kodiq Team
Building KODIQ in the open — an AI mentor for people launching software alone. Writing about what I learn the hard way.
More by this author →Newsletter
New issues in your inbox. No spam, unsubscribe anytime.
One email per issue (~once a month). Field notes from launching software solo.
Related articles