How to test your mobile app idea before you build it: 2026 guide

Most ideas die of vagueness before they get a chance to die of anything real. So before any interview, landing page or prototype, compress the idea into five lines we call a sharp bet:

Who — a specific person, not a segment. "Freelance UX designers with three or more retainer clients," not "creatives." If you cannot picture one actual human, you are not ready to test.

Pain / job — what they struggle with, and when. A concrete moment with observable behaviour, not a theme. "Every Friday they reconcile feedback from four email threads" beats "feedback is fragmented."

Current hack — what they use today. Excel plus Notion plus screenshots plus some creaky incumbent. The hack is the best validation signal that exists before you talk to anyone: people only build workarounds for problems that genuinely hurt.

Promise — what changes when your thing works. One sentence, their outcome, not your features.

Risks — three honest bullets of what might be wrong. "Maybe nobody cares enough to switch." "Maybe it's only painful in my bubble." "Maybe they'd never pay." Writing the risks down is what turns the next steps from theatre into tests — each step exists to attack one of these bullets.

Everything that follows tests the bet, line by line. If you cannot write the five lines, that is not a formatting problem; the idea is not yet specific enough to test, and no landing page will fix that.

Before talking to anyone, spend an evening on evidence that is already lying around.

Search the App Store and Google Play for your concept. Competitors existing is good news — it confirms the problem is worth money to someone. Read their one-star reviews for raw frustration and their three-star reviews for specific, fixable gaps. If "I wish it could do X" keeps appearing and X is your promise, that is validation written in your future users' own words — words you will reuse in your screens and your listing.

Read the graveyards too. Dead and abandoned apps in your category are underrated evidence: someone believed in this problem enough to build, and something killed it. Work out what — no demand, wrong audience, a business model that could not carry it — because whatever killed them is one of your risk bullets.

Check where ideas actually come from while you are at it. The best ones are rarely shower moments: your own recurring frustration, Reddit threads that start "I wish there was an app that…", a big app's pattern applied to a tiny audience that pays more and churns less — Strava, but for sailors — or an app that is huge in Japan or Brazil and simply does not exist in your market yet. Borrowing across borders is not cheating; it is research.

Google Trends, briefly. Type the problem, not your solution. Stable or rising over twelve months is fine; declining is worth pausing on. Do not over-read this — head-term trends are a blunt instrument, and plenty of excellent niches are invisible in them.

Ten short conversations with people who match the who line of your bet. Fifteen to twenty minutes each. Your job is to collect pain and quotes, not to pitch — the moment you describe your solution, the interview is over, because polite people validate whatever you show them.

Three questions do most of the work. "Walk me through how you handle this today" — surfaces the current hack and how much effort they already spend. "What have you already tried?" — surfaces the competitors and why they lost. "How often does this happen?" — a daily problem is testable in a week; an annual one is a much harder product.

Listen for two things above everything else. Do they describe the problem in their own words, unprompted? And do they already have a workaround? A workaround is effort, and effort is the only pre-purchase currency that does not lie.

And ask the uncomfortable question: what they currently pay — for the workaround, the incumbent, the freelancer who patches it. Interest is cheap; budgets are real. We learned this the direct way at Modaal: interviews showed our own early price sat above what the people we were building for would actually pay, we cut it, and conversions improved. Willingness to pay is not a step-seven refinement — it is a fact about the problem, and you can start collecting it in conversation one.

Here is the mobile-specific move most validation guides skip entirely, and in the workshop it is the exercise that changes the most minds.

Write down the full vision — everything the app could someday be. Then work backwards to the absolute minimum promise: the smallest version that still keeps the promise line of your bet. The instrument for that is brutal and concrete: design the three App Store screenshots first. Screen one: the problem, in the user's words. Screen two: your solution, on one screen. Screen three: the impact — what is different in their life.

Then build only what those three screens promise. Nothing else earns a place in version one.

This works because the App Store listing is the one artefact that cannot be vague. A PRD can hide ambiguity in prose; three screenshots cannot. If you cannot show the problem, the solution and the impact in three images, the concept is not ready to build — and you have discovered that for the price of an afternoon in a design tool rather than a month of development.

The same logic runs your plan. When you do build, write the spec before the code — define the data model and the foundations early, and build the foundational layer before features. Validation and planning are not enemies; skipping the plan is just deferred validation debt with interest.

Ten years ago this step meant a clickable Figma mockup, and the standard advice still says so. The advice is out of date. AI builders made working prototypes nearly as fast as fake ones, and a working prototype answers a question a mockup cannot: not "do they understand it?" but "do they come back?"

The shape we teach is fake-big, real-tiny: an app that looks like a complete product but genuinely does exactly one thing — the tiny happy path from your bet's promise. One workflow, real data saving, everything else absent or decorative.

The stack we use in the workshop, and the honest tool split:

Web prototype and landing page → Lovable. For a marketing page, a waitlist, or a web-shaped concept test, it is excellent, live in an afternoon, and shareable as a link — which matters, because a link needs no install to test.

Mobile app prototype → Modaal. When the idea is genuinely an app — it lives on the home screen, uses the phone's capabilities, belongs in the store — prototype it as one. Modaal's agent writes real Swift, compiles it, and fixes its own build errors; the free plan is one project with unlimited prompts, which is precisely a validation budget. You end up with a native prototype on your own phone, and on your testers' phones via TestFlight, in days. Full disclosure: Modaal is our product, and this guide exists because validation is what we watch founders skip.

One warning from watching many of these: do not wait for production-level design. A decent AI-generated interface is enough to validate almost every idea. The exceptions are products whose entire promise is the design — and if that is you, you already know. For everyone else, polishing the prototype is procrastination wearing a design hat.

Now the part that separates validation from reassurance: measuring what people do, because what people do disagrees, constantly, with what they say.

Run small paid traffic within the first week. A modest ad budget against your landing page or TestFlight link buys you strangers — and strangers are the only honest audience. Friends sign up out of love; Reddit acquaintances out of politeness. The funnel from a cold click to a completed core action is the closest thing to truth this process produces.

Run ten to twenty real user sessions. Give each person the core task — "you've just downloaded this; show me how you'd log a workout" — and watch in silence. Where they hesitate is where the design is wrong; what they ask is what the concept failed to say. Five people surface most problems; by twenty you are seeing repeats. Ship rough versions to testers over TestFlight and collect reactions where your community already talks.

Wire in analytics from day one — we use Amplitude. The prototype-to-analytics loop is the workshop's core move: prototype in days, traffic in week one, behaviour on a dashboard by week two. Three numbers carry the verdict. Activation — did they complete the core action once? Return — did they come back unprompted? Return is the strongest signal validation can produce, and no interview can fake it. Inbound requests — are strangers asking for features? Amplitude's AI tooling has made this notably cheaper to operate: you can ask questions about your funnel in plain English and watch session replays to see exactly where people stall, which used to be an analyst's week and is now an evening.

The final test, and the one founders avoid longest because it is the one that can actually fail: ask for a commitment. A pre-order at a real price. A pilot with a start date. A letter of intent. A "founding member" tier bought before launch.

Feedback is a gift people give to be kind. Money is a decision people make about their own interests. One paid commitment from a stranger outweighs fifty enthusiastic interviews, and asking early does a second job the interviews began: it prices the promise. If nobody bites at your price and three people bite at half of it, you have just learned your unit economics before writing the business plan — from experience, better to learn it now than after launch.

You are not trying to get rich in week two. You are trying to make one person cross the line from audience to customer, because that line is where every failed product actually died.