Written by Simon, founder who shipped 4 products nobody wanted.

How to Validate Your Startup Idea Without Building (Yet): A Practical Pre-MVP Validation Framework

Most founders spend six months and $50,000 building something before they talk to a single paying customer. Then they wonder why nobody shows up. Startup idea validation isn't a box you check after you build. It's the work you do instead of building, at least for the first two to three weeks.

The uncomfortable truth is that 90% of startup failures trace back to one root cause: the founder assumed the problem was real and the market was ready. They didn't test it. They built it. There's a version of you that could skip that mistake entirely, and this framework is how you do it. Validate your idea before you write a single line of code.

Why Building First Is a Trap

Building feels productive. You're shipping code, designing screens, setting up infrastructure. But if you haven't confirmed that real people have the problem you're solving, and that they'd actually pay to solve it, you're just burning time on an expensive guess. The founders who get this right treat the pre-MVP phase as seriously as the build phase. They set hypotheses, run experiments and collect evidence. They do this in weeks, not months.

The framework in this article gives you a structured sprint you can execute in three weeks. By the end, you'll know whether your startup idea deserves a build or a pivot.

Section 1: Start With Your Assumptions

Every startup is built on a stack of assumptions. Most founders don't write them down, which means they can't test them. The first thing you need to do is get explicit about what you believe to be true.

There are three core assumptions that every startup must validate before building. The problem assumption asks whether the problem you're solving actually exists and matters enough for someone to act on it. The solution assumption asks whether your proposed approach is actually the right way to solve it. The market assumption asks whether there's a real customer segment willing to pay for that solution. All three matter, but they don't all kill your startup equally fast. Rank them by risk. If the problem doesn't exist, nothing else matters. Start there.

Write your hypotheses in plain language using a simple template: "We believe [target customer] has [problem] because [evidence]." Be specific. "Remote engineering managers spend 3+ hours a week chasing status updates across five tools" is testable. "Teams struggle with collaboration" is not. The more precise your hypothesis, the cleaner your test.

Section 2: Customer Interviews as Your Core Tool

Customer interviews are the highest-value activity in early startup idea validation. Done well, they surface what customers actually experience versus what you assume they experience. Done badly, they just confirm your existing biases.

Find your first 20 interview candidates in places where your target customer already gathers. LinkedIn searches filtered by job title and company size work well for B2B. Industry Slack groups, subreddits and niche forums work for both B2B and B2C. The critical rule is to avoid interviewing primarily friends, family and warm contacts. They want to support you. That's not useful. You need honest strangers.

The best interview framework for this stage is Jobs-to-be-Done. You're not asking customers what they want. You're asking what they're trying to accomplish, what they've already tried and why those solutions fell short. Focus your questions on past behavior, not hypothetical future behavior. "Tell me about the last time you dealt with this problem" will give you more signal than "Would you use an app that did X?" People lie about hypotheticals without knowing they're lying.

Target 15 to 20 conversations in your first two weeks. You're listening for patterns, not validation. If you go into interviews hoping to hear that your idea is great, you'll find a way to hear that even when the data doesn't support it. The red flag to watch for is customers who can't remember the last time they faced the problem you're describing. If the problem isn't memorable, it probably isn't painful enough to pay to solve.

Section 3: Landing Page and Digital Signal Testing

A landing page isn't a product. It's an experiment. You're testing whether your framing of the problem and your proposed solution generates enough interest that strangers will give you their email address. That's a meaningful signal, because unlike a verbal "sounds interesting," an email signup has a small but real cost.

Keep the page simple. One clear problem statement, one solution framing and one call-to-action: an email signup. Don't include fake product screenshots or features you haven't built. Don't tell people to "check back later." Either get the email now or don't. Use no-code tools like Carrd or Webflow and get it live in a day.

Test without paid ads first. Post in the communities where your target customer hangs out: relevant subreddits, Hacker News's "Show HN," Indie Hackers, Product Hunt and niche Slack groups. The rule for doing this without getting banned or ignored is to provide value before you ask for attention. Engage in the community genuinely before you drop your link. A cold post with no context gets ignored or flagged. A post from someone who's been contributing gets read.

On conversion benchmarks: a 2-5% conversion rate from low-intent cold traffic is a weak signal but not meaningless. A 15% or higher conversion rate from warm, targeted communities where your customer actually lives is a strong signal worth acting on. For B2B products, even 8-10% from a relevant community is worth noting alongside your interview data. The First Round Review covers Gagan Biyani's minimum viable testing approach in detail if you want to go deeper on experiment design.

Section 4: Market Sizing and Search Intent

Market sizing at this stage isn't about impressing investors. It's about asking whether the problem is big enough to build a business around. A bottom-up estimate beats a top-down one at this stage. Take your target customer segment, estimate how many of them exist, multiply by what they'd realistically pay and check whether that number is large enough to matter. For VC-scale ambitions, you need a path to $10M+ TAM. For a bootstrapped business, $100K+ in reachable annual revenue is a viable starting point.

Search volume data gives you a useful proxy for problem awareness. Google Trends and Keyword Planner show you whether people are actively searching for solutions to the problem you're targeting. Look at adjacent queries too, the language customers use when they don't know a product like yours exists. High search volume with commercial intent is a strong signal. High search volume with no clear purchase intent (think informational content only) is weaker. HBS Online has a solid breakdown of market validation steps that covers this alongside customer research.

Map your competitive landscape while you're at it. Look at reviews of existing tools in your space on G2, Capterra or the App Store. The one-star and three-star reviews are your product spec. They tell you exactly what the real pain point is, in the customer's own words, which is far more useful than analyst reports.

Section 5: The Decision Framework

After three weeks of interviews, landing page tests and market research, you need a clear decision threshold. Here's what counts as meaningful validation: 70% or more of your interview subjects independently identify the same problem without prompting. At least half of them signal genuine willingness to pay (not "that's cool" but "yes I'd pay for that, here's roughly what"). Your landing page converts at 10% or better from a targeted organic audience. Your market size math shows a viable business. And you can articulate a clear gap between what you offer and what existing solutions provide.

If you hit those thresholds, move to building a minimum viable product. If you fall short in one area, run another round of targeted tests before committing to a build. If the problem validation fails entirely, meaning customers don't recognize the issue or wouldn't pay to solve it, kill it and start over. That's not failure. That's the framework working exactly as intended.

The case study version of this: a founder testing a B2B SaaS idea in the project management space ran 12 interviews with remote engineering managers in week one. The problem was real but different than hypothesized. The pain wasn't async communication, it was tool fragmentation. Their landing page pulled an 8% conversion rate from Indie Hackers and Dev.to. Market sizing showed a focused $50K annual opportunity in one segment, not the broad market they'd imagined. The decision: pivot the positioning before building, not after. That pivot cost two days. Building wrong and then pivoting would have cost six months.

Section 6: Common Validation Mistakes That Waste Your Sprint

The most common mistake is interviewing only warm leads. Friends and family will be kind. Kindness is not signal. A stranger who pulls out their credit card during an interview is signal.

The second mistake is validating your solution before validating whether the problem exists. Founders love talking about their idea. Customers need to confirm the problem first. Keep your solution out of interviews until you've confirmed the problem is real and painful.

The third mistake is treating interest as commitment. "I'd use that" means almost nothing. "Here's my email and I'd pay $50 a month for that" means something. Design your tests to require a small commitment, even just an email address, so you're measuring behavior not sentiment.

Tools to Run This in Three Weeks

For interviews: Google Forms or Typeform for post-interview surveys, Descript for recording and transcription, Google Sheets for synthesizing patterns across conversations. For landing pages: Carrd is fast and free, Webflow gives you more control. Google Analytics tracks source and conversion data. Mailchimp or ConvertKit captures emails. For market research: Crunchbase for competitive intelligence, SEMrush or Google Trends for search volume, G2 and Reddit for raw customer voice.

The whole stack costs under $100 per month. The validation sprint costs you three weeks of focus. That's the trade you're making: three weeks now versus six months of building something nobody wanted later.

Start This Week

Startup idea validation is not a one-time gate. It's the first iteration of a loop you'll run repeatedly as a founder. Your first round won't be perfect. You'll ask some bad interview questions. Your landing page copy will miss. That's fine. The point is to collect real evidence and update your beliefs based on what you find, not what you hoped to find.

Write down your three core assumptions today. Recruit your first five interview candidates tomorrow. Get a landing page live by day ten. Get started and run your first validation sprint before you touch a single line of code. The founders who build things people actually want didn't get lucky. They just did this work first.

For more on building a validation-first approach to your startup, read more on the Validate & Launch blog.