Joy Foroughi
Executive Assistant
Founders: Validate Your App Idea and Decide in 30 Days
The three things you must test before building an MVP are the single riskiest hypothesis behind your idea, real customer behavior rather than opinions, and a clear kill criterion with a deadline attached. Skip any one of these and you risk building a polished product nobody pays for. Run them in that order, and you can usually tell within 30 days whether your idea deserves engineering resources at all.
The three things you must test before building an MVP are the single riskiest hypothesis behind your idea, real customer behavior rather than opinions, and a clear kill criterion with a deadline attached. Skip any one of these and you risk building a polished product nobody pays for. Run them in that order, and you can usually tell within 30 days whether your idea deserves engineering resources at all.
TL;DR:
Focus on testing the riskiest hypothesis by converting your idea into a specific, measurable statement before engaging in product development.
Conduct founder-led customer discovery and Jobs-to-be-Done interviews to uncover genuine behaviors and emotional urgency, not just opinions.
Use demand tests like landing pages or preorder flows to measure real intent against thresholds chosen for your audience, acquisition channel, price, and level of commitment.
Run behavioral experiments such as concierge MVPs or prototypes to verify whether users will change their behavior and find the solution valuable enough to retain.
Set clear kill criteria based on predetermined metrics and deadlines to decide whether to build, pivot, or stop, avoiding decision bias and wasted effort.
1. Convert your idea into one testable hypothesis
Most app ideas fail validation because they're never actually stated as something you can test. Before you write a single line of code, convert your idea into a specific sentence that names who the customer is, what problem they have, and what outcome you expect. A workable template: "[Customer archetype] will pay [$X]/month to [solve problem] because [current workaround is broken]." For example: "Remote fitness coaches will pay $29/month to automate client scheduling because current tools require manual coordination."
Shawn Carolan's MVP Tree, published on Steve Blank's blog gives you a useful way to narrow down which hypothesis to test first. It breaks your idea down in stages:
Start with a one-sentence mission statement for your product.
Identify the customer archetypes who might buy it.
List the jobs to be done for each archetype.
Branch out execution options and candidate MVPs for each job.
Score each candidate hypothesis on impact and uncertainty. The one with the highest combination, the assumption that would hurt most if wrong and that you know least about, is the one you test first.
2. Run founder-led customer discovery and JTBD interviews
Lead the first round of interviews yourself, even if a researcher or contractor helps with preparation and analysis. Direct involvement lets you hear the hesitations, tangents, and emotional cues that can reveal whether a problem is actually painful. Relying only on secondhand notes can make it easier to miss those details or reinforce assumptions you already hold.
Structure your interviews to surface behavior, not hypothetical enthusiasm:
Ask "When was the last time you ran into this problem?" to anchor the conversation in a real event.
Ask "How do you solve this today?" to expose existing workarounds and switching costs.
Avoid "Would you use this?" entirely. It invites polite agreement, not evidence.
Listen for emotional urgency: frustration, workarounds cobbled together from spreadsheets, or money already spent on a partial fix.
Plan for 10 to 15 interviews per customer archetype before drawing conclusions, and prioritize whichever archetype showed the highest impact and uncertainty score in step one.
Pro Tip: Record interviews (with permission) and review them for patterns rather than relying on memory. The strongest signals often show up on the second listen, not the first.
3. Set up demand tests that measure intent
Once you have a hypothesis and some interview signal, you need evidence that strangers, not just people you talked to, will act on it. Three tactical setups work well here, and each produces a different strength of evidence.
A landing page with a clear value proposition and a single call to action (usually an email signup) is the fastest way to gauge interest at volume. A fake-door test adds a feature or button inside an existing product or ad that leads to a "coming soon" page, measuring click intent for a specific feature. A preorder or deposit flow asks for money or a real commitment before the product exists, which is the strongest of the three because it forces an actual decision rather than a click.
Build your landing page around three elements:
A headline that states the specific outcome, not the mechanism ("Fill your coaching calendar automatically" beats "AI scheduling platform").
A sense of scarcity or timing ("limited beta spots" or "launching Q1") to prompt action instead of passive browsing.
One clear next step: join the waitlist, reserve a spot, or preorder, never multiple competing buttons.
Strategyzer's evidence-strength framework distinguishes what people say from what they do and considers the investment they make: an email signup shows interest, while a deposit provides stronger evidence of commitment. Set your conversion threshold before the test based on your target audience, acquisition channel, price, and requested commitment. There is no universal signup or preorder rate that validates an app idea. If results fall below your threshold, investigate the audience, message, offer, and traffic quality before concluding that the problem lacks urgency.
4. Run behavioral experiments (concierge MVPs, prototypes, manual delivery)
A landing page tells you people are curious. A behavioral experiment tells you whether they'll actually change what they do, and that's a much higher bar.
A concierge MVP delivers the end result manually, by hand, before you build any automation. If your hypothesis is about scheduling, you personally coordinate a handful of clients' calendars by email and track how often they come back without being prompted. This is slow by design and that's the point: it isolates whether the outcome matters, not whether the interface is polished. If users won't spend time or money on a manual version, investigate whether the problem lacks urgency or whether the manual delivery adds friction that automation could remove.
A clickable prototype built in Figma or a no-code funnel built in Bubble or Glide lets you test flow and onboarding friction without writing production code. Run five to eight real users through it and watch where they hesitate.
Concierge MVPs measure whether the outcome is valuable enough to retain users.
Clickable prototypes measure whether your proposed flow is understandable.
No-code funnels measure both usability and early conversion, in one pass.
Compare repeat usage and paid conversion against your interview answers. Strategyzer is clear that behavioral experiments like these produce far stronger evidence than any survey or hypothetical interest question ever will.
Pro Tip: If a concierge MVP takes more than a week of manual effort per user to deliver, that's useful data too. It tells you where your real technical and operational risk sits.
5. Choose metrics, set kill criteria, and decide sample size
The biggest trap in validation isn't bad data. It's bad judgment applied to good data, after the fact, to justify a decision you already wanted to make. The fix is deciding your numbers before you run the test.
Strategyzer's evidence framework weighs what people actually do more heavily than what they say, and considers both their investment and the number of data points. Use verbal interest, email signups, deposits or preorders, and actual purchases as progressively more demanding tests of commitment, while considering the context of each experiment. Never treat a signup list the same way you'd treat a list of paying customers.
Pick metrics that match the hypothesis, not metrics that are easy to collect:
Conversion rate from visitor to signup or preorder.
Activation, meaning time to the one-screen "aha" moment that proves the core value.
Retention at day 7 for users with a full week of access; schedule day-30 retention as a follow-up once each user cohort has had 30 days to use the product.
Willingness to pay, measured by actual preorder or deposit, not a survey question.
Set a success threshold and a kill criterion, each with a number and a deadline, before you start. This converts a vague "let's see how it goes" into a decision rule. Meet the success threshold with enough relevant evidence, and move forward. Trigger the kill criterion, and revisit the hypothesis, pivot, or stop. If the evidence is too limited to support either decision, treat the result as inconclusive rather than forcing a verdict.
Choose the sample size around the decision you need to make: the expected conversion rate, the smallest difference that would change your choice, and the uncertainty you can tolerate. Count both participants and outcomes, and use comparable recruitment conditions. For example, one signup from 20 visitors is too little evidence to establish a reliable conversion rate. Interviews and small usability studies can reveal patterns, but should not be treated as statistical proof of demand.
6. Scope the MVP: one job, one screen, fast time-to-value
Once your evidence clears the bar, resist the urge to build everything the interviews surfaced. Your MVP should prove or disprove the hypothesis as fast as possible, nothing more.
Identify the single screen or flow that delivers your "aha" moment, the moment a user experiences the actual value you promised. The MVP Tree described by Shawn Carolan on Steve Blank's blog emphasizes solving one meaningful job for one customer group with a focused product and a rapid time-to-value. Everything else is scope creep dressed up as thoroughness.
Map every proposed feature back to the hypothesis: if it doesn't test or support the core assumption, cut it from version one.
Design the first screen to deliver value within seconds of opening the app, following mobile UX design best practices for startups, not after a multi-step setup flow.
Choose a single platform, iOS or Android, rather than building both simultaneously; a one-platform MVP can reduce platform-specific development and testing work and let you redirect saved budget into more experiments. The savings depend on your architecture, shared code, integrations, and release requirements.
Treat any feature request from interviews as a data point, not a requirement, until it's tied to behavior you've actually observed.
7. Quick technical spikes to validate core integrations and performance risk
A validated hypothesis means nothing if the product can't actually be built within your budget and timeline. Before committing engineering weeks, run short technical spikes on anything you're unsure about.
Spike the riskiest technical assumptions first:
Third-party API reliability and documented uptime, especially for payments, calendars, or location data.
Latency under realistic load, not just a clean demo environment.
True cost of third-party providers at your expected usage volume, since many pricing tiers look cheap until scale hits.
Authentication flows, particularly if you're integrating with enterprise or healthcare systems with stricter requirements.
A good spike takes two to five days and ends with a working proof-of-concept, even an ugly one, that proves the integration is possible at the cost and speed you assumed. If a spike reveals that an integration is fragile or far more expensive than expected, that changes your validation path entirely: you may need a different technical approach before the behavioral experiments in step four are even worth running.
8. Recruit beta users and run short trials; read the signals
Your concierge and prototype experiments proved the concept works on a handful of people. A short beta trial checks whether it holds up with strangers who have no personal relationship with you.
Recruit from founder networks first, then niche forums and communities where your target archetype already spends time, and finally narrow, targeted ads if organic reach is too slow.
Write outreach that leads with the specific outcome, not the product category: "early access to automate your client scheduling," not "try our new app."
Build a beta onboarding checklist: one clear value statement on first open, no more than three setup steps, and an obvious way to send feedback, whether that's a chat widget or a direct email to you.
Track repeat usage over a one- or two-week window, since a single open-and-close session tells you nothing.
Watch for referral intent: users who ask if they can invite a colleague are showing you stronger signal than any survey response.
Paid conversion, even at a small scale, remains your clearest evidence. Qualitative praise is encouraging, but Strategyzer's evidence hierarchy still ranks it well below money changing hands.
A practical framework for a 30-day validation sprint
This checklist provides a framework for organizing early-stage validation around one hypothesis and real behavioral evidence. Testing the highest-risk assumptions before engineering starts can help founders narrow MVP scope and reduce avoidable rework during development.
One possible 30-day schedule is to run discovery interviews in week one, a clickable prototype and demand test in week two, behavioral experiments in week three, and an evidence review in week four, naming what to build, what to cut, and what to watch post-launch. Adapt the timing to recruitment, technical dependencies, and the amount of evidence available; some questions will require a longer follow-up period.
Competitive analysis: evaluating existing solutions and market gaps
Every validation checklist eventually runs into the same question: does something like this already exist, and if so, why hasn't it won? Skipping competitive analysis is one of the fastest ways to build a confident MVP nobody switches to.
Start by identifying who already solves this problem, even imperfectly. That includes direct competitors in your category and indirect ones, spreadsheets, manual processes, or adjacent apps people have bent to fit the job. SBA guidance on market research and competitive analysis recommends mapping this landscape early, since understanding who else serves your target customer helps you size real demand rather than assumed demand.
For each existing option, note three things: what it does well enough that people tolerate its flaws, where users complain loudest (check app store reviews and forum threads), and what price they already pay, if any. That last point matters more than most founders expect. If no one pays for anything in this category, your monetization hypothesis needs extra scrutiny.
The gap you're looking for isn't "nothing like this exists." It's "existing solutions ignore this specific job, this specific archetype, or this specific moment of friction." That gap, not the absence of competitors, is what your MVP should be built to fill. If your interviews and demand tests keep surfacing the same workaround, that workaround is your real competitor, not the other app in the store.
Market sizing and opportunity assessment
A validated hypothesis and strong interview signal can still sit inside a market too small to support a sustainable business. Before scoping your MVP, get a rough sense of how many people actually have this problem and how often.
Start narrow and bottom-up rather than quoting broad industry figures that rarely apply to your specific archetype. Count the realistic number of people in your target customer segment you can reach through the channels you actually have access to: a niche community, a professional network, a geographic region. SBA's market research guidance frames this as a core planning step precisely because it keeps founders from confusing a broad category's size with their actual addressable segment.
Then layer in frequency. A problem that happens once a year supports a different kind of product, and a different price, than one that happens weekly. Your demand tests from step three should already be giving you a rough read: if 200 targeted visitors produce almost no signups, investigate the audience, message, offer, and acquisition channel. That result alone does not establish the size of the market.
Resist the urge to inflate the opportunity to justify the build. A smaller, well-defined market with a clear willingness to pay beats a vague, oversized total addressable market with no one actually reaching for their wallet. The goal at this stage isn't a polished market-sizing slide, it's enough confidence that there are enough of the right people, reachable at reasonable cost, to make the MVP worth building.
Monetization model validation (pricing, willingness to pay)
Interest doesn't pay invoices. Before you finalize MVP scope, test whether anyone will actually hand over money, and at what price.
The clearest way to validate pricing is to ask for it directly, through a preorder or deposit, rather than asking people hypothetically what they'd pay. Strategyzer's evidence framework draws a sharp line here: a deposit is strong evidence, a survey answer about hypothetical price tolerance is weak. If your landing page or concierge test included a price, the resulting conversion rate is your most honest signal yet.
Test more than one price point if your sample size allows it. A 50/50 split test between two price tiers on your landing page can help compare demand when each group produces enough conversions to support the comparison. With a small sample, treat differences as directional signals rather than reliable proof that demand holds at a higher price or collapses. Also test the billing model itself, not just the amount: a one-time fee, a monthly subscription, and a usage-based fee often produce different willingness-to-pay signals even at the same effective price.
Pay attention to who hesitates and why. If prospects balk at the price but not the concept, your monetization model may need adjusting before the underlying hypothesis is thrown out entirely. Conflating a pricing problem with a product problem is a common reason founders kill good ideas for the wrong reason.
If you want help: Product strategy support from TouchZen
Running this checklist alone takes real founder time, and not every team has four weeks to spare before a fundraising deadline or a competitor's head start. If speed and senior expertise matter more than doing it solo, that's where we come in.
Our Product Strategy & Consulting services help founders clarify their goals, research users and the market, prioritize features, and develop an actionable product roadmap. Discuss the validation work your idea needs and agree on the scope, deliverables, and timeline for your engagement. When the evidence supports moving forward, explore our MVP Development for Start Ups services to turn that direction into a focused first release. Schedule a discovery call to discuss the next steps for your idea.
FAQ
How do you validate an app idea before building it?
Write one specific, testable hypothesis naming your customer, their problem, and the expected outcome, then run founder-led interviews followed by a demand test like a landing page or preorder flow. Set a kill criterion, a specific number and deadline, before you start, so the result decides the next step instead of your gut.
How do you validate an MVP?
Validate an MVP by comparing behavioral evidence, actual signups, deposits, or repeat usage, against the success threshold and kill criterion you set in advance, rather than relying on opinions or survey answers. Strategyzer's evidence framework ranks what people do far above what people say when judging whether an MVP is working.
What three things do you consider when creating your MVP?
Focus on the single riskiest hypothesis you need to test, the one screen or flow that delivers your core "aha" moment, and the minimum feature set required to prove the hypothesis without extra scope. Cutting anything that doesn't directly test the hypothesis keeps the build fast and the signal clean.
What are the steps in validating an idea?
The core sequence is: define one testable hypothesis, run founder-led customer discovery interviews, set up a demand test to measure real intent, run a behavioral experiment like a concierge MVP, and compare results against a predefined kill criterion. Technical spikes and competitive analysis typically run in parallel once the hypothesis is set.
Sources
Shawn Carolan, on Steve Blank’s blog — A Path to the Minimum Viable Product
Strategyzer — Business testing: Is your hypothesis really validated?
U.S. Small Business Administration — Market research and competitive analysis
30-day founder action plan
Spend day one writing your hypothesis and sketching the experiments that will test it. Spend days two through ten running interviews and building your landing page. Spend days eleven through twenty-five running demand tests and a concierge experiment to capture real behavior. On day thirty, line up the evidence against your success threshold and kill criterion and decide: build, pivot, or stop. If the evidence is inconclusive, define a focused follow-up test; review day-30 retention only after users have had a full 30 days of access. No one else can make that call with the context you have.
