How to Validate a Startup Idea Before You Build an MVP

Building is the most expensive way to learn, but founders still treat "start coding" as step one. They ship something polished, show friends, get polite nods, and wonder why nobody pays.

Validation isn't a buzzword. It's a few small bets that answer one question: will strangers do something costly because of this problem?

Costly means paying, booking a call, sharing real data, or changing how they work. Likes and "cool idea" don't count.

What you're actually trying to learn

You're not proving the idea is genius. You're trying to find out if nobody cares before you burn time and money.

A rough ladder, cheapest first:

Problem interviews. Is the pain real and frequent? Mostly costs time.

Landing page + waitlist. Will people give you an email? Domain and basic tooling might run you $0-$200.

Concierge delivery. Will they use a rough version you run by hand? Still cheap, but the signal is strong.

Paid pilot. Will they pay before the product exists? Time plus a simple payment link.

Skip straight to a full MVP and you learn all of this after the invoice hits.

Talk to people who already have the problem

Not your roommate. Not random founders at a meetup unless they're your user. Find ten people who already spend money or time on this today, even if their solution is ugly.

Ask things like:

• What did you do the last time this happened?
• What did that cost you in money, hours, or stress?
• What would you try if a tool fixed just that one step?

Listen for specifics. "Yeah I could see using that" is weak. Stories about spreadsheets, hacks, and workarounds are what you want.

Test demand without code

Landing page: One headline, one subhead, one CTA (waitlist or book a call). Post where your users already hang out before you blast ads everywhere. Five percent signup from the right visitors beats ten thousand random clicks.

Manual delivery: Describe the outcome ("weekly AI summary of your support tickets") and offer to do it by hand for three customers. If nobody pays for manual, they won't pay for automation.

Slides or Figma: Enough to walk the happy path on Zoom. Watch where they get lost. Confusion at step two usually means bad scope, not missing features.

Validation works when people do something expensive, not when they say they would.

Track behavior, not vanity

Worth watching:

• Waitlist: signup rate, where traffic came from, do people reply to your follow-up
• Calls: show-up rate, objections, questions they ask
• Pilot: do they come back after week one, refer anyone, renew

Ignore for now: Twitter impressions, Product Hunt rank, feature matrices.

Pick a kill line upfront. Something like: if fewer than three of ten interviewed people book a follow-up after the landing page, we change the positioning. Stops you from moving goalposts when the numbers suck.

When you have enough to build

You're in good shape when:

1. You can name a narrow user and one job-to-be-done
2. A handful of people did something costly (paid pilot, serious call, kept using the manual version)
3. You know the main objections and which ones v1 has to handle
4. v1 is two or three features, not a platform

You're not ready if the only proof is "people said they'd use it" or "competitors exist so the market must be huge."

What to build after validation

Demand is real but the manual process is breaking. Ship the smallest thing that replaces your concierge workflow:

• Auth only if people need to come back
• One core automation or workflow
• A feedback path from day one (in-app or email)

That's the shape of a Build Sprint with us: five to seven days, full stack, deployed, built to extend. Not a throwaway prototype.

Mistakes we see a lot

Building for investors. Decks look great. Users pay for relief.

Surveys over observation. People are bad at predicting their own behavior. Watch what they do today.

Too broad. "Tools for remote teams" teaches you nothing. "Async standup summaries for eng managers at 20-100 person startups" can.

Waiting for perfect data. Ten real conversations beat a hundred form responses.

Run the cheap tests. Cut the scope. Then build something that proves you can ship, not just pitch.

When the signal is there and the scope fits on one page, that's when a sprint makes sense.