--- slug: validate-an-app-idea title: "How to Validate an App Idea Before You Build It" excerpt: "You can validate an app idea in 48 hours, no code, no waitlist tricks. Five conversations, one fake landing page, and an honest read." primaryKeyword: "validate an app idea" publishedAt: 2026-05-06 readingTimeMin: 7 author: "Robert Boylan" tags: - app-planning - validation - indie-dev - non-technical-founder - mvp --- A friend of mine spent three weekends in a row shipping three different apps. A budgeting tool. A workout planner. A small AI writing helper. Each one ended the same way: a tweet, a couple of polite likes, zero people who used it past day one. The code was fine. He just never asked anyone if they wanted the thing before he built it. Three weekends of shipping into a void. This post is about how to validate an app idea in roughly 48 hours, before you write a line of code. Five conversations, one fake landing page, and an honest read of the result. We'll use one running example: a meal-prep tracker for shift workers (nurses, paramedics, factory crews). Specific enough to feel real, vague enough that it could easily flop. ## Why "build it and they will come" still wastes weekends The temptation, especially with AI coding tools getting good, is to skip validation entirely. Lovable can stand up a working app in an afternoon. Cursor and Claude Code make it tempting to just start. So why not? Because shipping is the easy part now. It used to be that building was the bottleneck, and "do people want this?" got answered by accident, after months of work. With AI tools, building has collapsed from months to days. Which means the bottleneck moved. The expensive question is no longer "can I build it?" It's "is anyone going to care?" Building first and asking later is how you end up with my friend's three weekend ghosts. Each one technically worked. Each one was a stranger to its supposed users until launch day, when it turned out the supposed users didn't exist or didn't care. **Validation isn't a phase. It's a question you answer before you spend the time.** And the answer is cheap to find if you're willing to do something slightly awkward for two days. ## The five-conversation rule Here's the rule: before you start building, talk to five real people who fit the target audience. Not five friends. Not your Twitter followers. Five people who, if the app existed today, would plausibly use it. For the meal-prep tracker, that means five shift workers. Not five "people interested in fitness." A nurse who works rotating nights. A paramedic on 12-hour shifts. A warehouse supervisor whose schedule flips every two weeks. People whose actual problem you're claiming to solve. You can find them through old colleagues, LinkedIn searches, niche subreddits, Slack groups, or just asking your network "do you know anyone who works shifts?" Five is a small number on purpose. It's enough to spot patterns and small enough that you can't talk yourself out of it. Now the part most people get wrong: what you ask. **Never ask "would you use this?"** People are polite. They'll say yes. The yes is worthless because it costs them nothing. By the time the app exists, they've forgotten the conversation. Ask about the past instead. The past is concrete and unfakeable. - "Walk me through the last time you tried to plan meals for a week of night shifts. What did you actually do?" - "When was the last time you ate badly at work because you didn't have time to prep? What happened?" - "Have you ever paid for an app or tool to help with this? Which one? Are you still using it?" You're listening for two things. First, does the problem actually exist in their life, or are they shrugging? Second, have they ever spent money or real effort on it? Someone who's tried four meal-prep apps and a paid macro tracker is a much stronger signal than someone who says "yeah, that sounds useful." If three out of five describe the problem unprompted, in their own words, with real detail about a recent moment of pain: you have a signal. If everyone is vaguely supportive but nobody can name the last time it actually mattered: you don't. ## The fake-landing-page test Conversations are step one. Step two is a tiny landing page that pretends the app already exists, and seeing whether anyone reaches for it. This used to be a half-day project. Now it's an hour, maybe less. Spin up a single page in Lovable or v0 if you want it to feel app-shaped, or use Carrd if you'd rather just get a clean one-pager up without touching code. Pick whichever feels less friction. The point is to get something live on a real URL today, not to ship a design portfolio. What goes on the page: - A clear name and a one-line promise. ("PrepShift: meal planning that actually fits a rotating shift schedule.") - Three or four concrete features, written like the app exists. No "coming soon" energy. - Two or three specific user stories, ideally lifted directly from your five conversations. Real wording beats marketing copy. - One CTA button. "Get early access" or "Start your first plan." When clicked, it asks for an email and shows a friendly "you're on the list" message. That CTA button is the test. It looks real. It's not. It's a fake-door (a button that promises action but only logs intent). Behind it is a form, and behind the form is you, watching who clicks. Then drive a small amount of targeted traffic. Post in two or three subreddits where shift workers actually hang out (r/nursing, r/ems, r/Paramedics, r/shiftworkers). Don't spam. Frame it like you're working on it and want feedback. Maybe spend $20 on a tiny Reddit ad targeted at the same audience. You're looking for a few hundred relevant visitors, not viral traffic. Then watch the funnel. How many people land. How many click the CTA. How many give an email. ## What counts as a real signal vs a polite signal This is where most validation goes off the rails. You get some numbers, you squint at them, and you tell yourself the squint is a green light. Resist. Rough thresholds for the meal-prep tracker example, after maybe 200 targeted visitors: - **Polite signal (don't trust it):** waitlist signups under 5%. People sign up for free things easily. Email-on-a-fake-button is the lowest-cost commitment a user can make. If only 3% of visitors will even do that, the message isn't landing. - **Decent signal:** 8–15% of relevant visitors hand over an email, and at least a couple of them reply to a follow-up message with real detail about their situation. That second part matters more than the first. - **Strong signal:** people email you unprompted asking when it's launching. Or someone asks if they can pay now to lock it in. Or your conversations from step one start asking when they can try it. Real demand leaks out the sides. - **The gold standard:** a paid pre-order. Even $5. Even $1. Money changing hands is the only signal that fully cuts through politeness. If you're not ready to take pre-orders, that's fine, but know that everything else has a politeness discount baked in. A reply that says "this looks really cool!" with no follow-up is a polite signal. An email that says "I tried [competitor] and it didn't handle 12-hour overnight shifts, does yours?" is a real signal. You're learning what the actual job-to-be-done is, in the user's own language, often before you've even built anything. If after 48 hours you have five conversations, a live page, a couple hundred visitors, and basically nothing happening: that's also a real signal. It's the one nobody wants. But it's saved you a weekend of building. ## When validation is misleading Validation isn't a magic box. There are a few situations where the test will lie to you. **You are the only target user.** If the meal-prep tracker is really "a tool I personally need because I work nights and nothing else fits," that's a totally fine reason to build something. But don't dress it up as a startup with a market. The validation will be murky because you'll unconsciously seek out people like you, and "people like you" is not always a market. Ship it for yourself. If others find it later, great. **The niche is real but unreachable cheaply.** Some audiences exist but you can't get to them in 48 hours. Hospital procurement officers. Long-haul truckers. People in regulated industries. The fake-landing-page test relies on cheap, targeted distribution, which works for hobbies and consumer apps but breaks for B2B or enterprise. If your target audience isn't on the open internet in concentrated places, the lack of signups might mean "no demand," or it might mean "your channel is wrong." Be honest about which. **The idea is too fuzzy to test.** "An AI productivity tool" doesn't validate. There's nothing concrete enough on the landing page to react to. If your one-line promise reads more like a vibe than a thing, you don't have an idea yet, you have a direction. The fix is to make it specific (a meal-prep tracker for shift workers, a meeting-notes summariser for therapists, a podcast clip generator for solo creators) and then validate the specific version. Vague ideas can't be validated; only specific ones can. **You're getting feedback from the wrong people.** If you posted the meal-prep tracker page in a generic productivity subreddit, you'll get notes from people who like productivity tools, not from shift workers. Polite engagement from the wrong audience is the most expensive kind of false positive. The five conversations and the landing-page traffic both have to come from people who fit the target user, not just people who happen to be online. If any of these apply, validation gives you noise. Recognise that, and either fix the conditions of the test or move on with eyes open. ## From validated idea to a buildable spec Say the 48 hours go well. Five conversations confirmed real pain. The landing page got 12% conversion and three unprompted "when can I try this?" emails. You have a validated idea. The next mistake is to immediately open Cursor or Lovable and start prompting. The validated idea is a paragraph in your head. The thing you need to feed to an AI coding tool is a structured spec: what it is, who it's for, what features ship in v1, what's deferred, what the constraints are. Skip that step and you're back in vibe-coding territory, just with a slightly better starting point. This is the natural moment for [scoping the MVP once the idea is validated](/blog/mvp-scope-ships-in-a-weekend), where the conversation about what to actually build first happens. And once you start thinking about the longer arc, the question of [turning an app idea into a real side hustle](/blog/app-idea-to-profitable-side-hustle) is where the validation work pays off the most. Most people skip the structured-spec step because writing one is boring and easy to do badly. You forget the data model. You forget which features are v1 vs v2. You forget the personas you literally just interviewed. That's the gap [how Draftlytic turns the validated idea into a spec](/blog/how-to-use-draftlytic) was built to close. You describe what you learned in the 48 hours, and it hands back a structured plan ready to drop into your tool of choice. The next time you have a weekend free and an itch to build, spend the first 48 hours not building. Talk to five people. Put up a fake page. Read the signal honestly. The weekend after that, you'll know whether you're shipping into a real audience or another quiet void.