Stage 2 — The question that kills most app ideas.

Stage 1 produced a clear problem statement, a specific user, and ten real people you could find this week. That's not validation — that's preparation for it. Stage 2 is where the idea gets pressure-tested against reality: real search behavior, real competitors, real money, real technical dependencies. Most ideas that feel solid after Stage 1 are supposed to struggle here. The ones that don't are the ones worth building.

The central question of Stage 2 isn't "is this a good idea." It's sharper than that, and harder to answer honestly:

Who specifically pulls out their credit card for this — and what had to happen in their day to make them go looking?

That's the credit card question. It sounds simple. It eliminates ideas that couldn't survive it with brutal efficiency. If you can't answer it — if you can describe the user but not the exact trigger moment that sends them searching — you haven't confirmed demand. You've confirmed that a problem exists. Those are not the same thing.

Why ideas die here — and why that's the point

There's a version of the Wilde DataLabs Method where Stage 2 feels like a threat to an idea you've started to care about. That's the wrong frame. Stage 2 is designed to find the fastest possible signal that real people experience this problem urgently enough to act on it. If that signal doesn't exist, you want to know now — before Stage 3, before the technical spec, before a single line of code. The methodology treats a Stage 2 failure not as a loss but as the cheapest possible outcome. You spent a week on a validation pass and saved three months of build time. That's the system working.

The hard part is that most ideas don't fail cleanly. They produce ambiguous signals — some search volume but weak, a competitor that exists but barely, forum complaints that suggest pain but not urgency. Ambiguity at Stage 2 is information too. It tells you the idea needs more sharpening, or that the user definition is still too broad, or that you're looking for demand in the wrong places. A clean no is fast. An ambiguous signal sends you back one stage to tighten before returning.

The five validation signals

Stage 2 looks for five types of evidence, and they're not weighted equally. Search demand tells you people are actively looking for a solution — not just that they have the problem, but that they're in motion. Community pain tells you people are complaining loudly enough to post about it publicly, which is a higher signal than passive dissatisfaction. Competitor existence is often misread as a negative — it isn't. A competitor means someone already confirmed there's a market. Your job is to understand where they fall short, not to celebrate a clean field.

Signal	What it tells you	Where to find it
Search Demand	People are actively looking for a solution — not just aware of the problem	Google Keyword Planner, Ahrefs free tier, AnswerThePublic
Community Pain	People complain about this publicly — passive dissatisfaction becomes active frustration	Reddit, Facebook Groups, Quora, niche forums
Competitor Exists	Someone already confirmed the market — your job is to find the gap, not celebrate an empty field	App stores, ProductHunt, Google, G2
Willingness to Pay	People will exchange money for relief from this friction — the hardest signal to fake	Competitor pricing, direct outreach, survey
Your Advantage	You can solve this better, faster, or cheaper than what exists — and you can say exactly how	Honest gap analysis against every named competitor

Willingness to pay deserves its own paragraph because it's the one founders most often skip. It's uncomfortable to test directly — it requires asking real people a question that feels presumptuous. But it's the only signal that can't be manufactured. Search volume can be gamed. Forum posts can be outliers. Competitors can be surviving on fumes. The moment a real person says "I'd pay $X for that" or — better — is already paying $X for something adjacent, you have something concrete. That's the closest Stage 2 gets to certainty.

The dependency audit

The validation signals tell you whether demand exists. The dependency audit tells you whether you can actually build the thing. They're separate questions, and the dependency audit gets skipped more often — usually because founders assume they'll figure out the technical dependencies during the build. That assumption is expensive.

Every app has hidden dependencies that can kill it before launch. External APIs are the most common: does the data source you need actually exist, what does it cost at scale, and what does it actually expose versus what the documentation implies? Data licensing is a quieter version of the same problem — public data isn't always usable, and proprietary data often costs more than the app's first-year revenue. Platform requirements matter too: an app that needs native push notifications, camera access, or background processing has a different build cost and distribution path than a simple web tool.

The goal of the dependency audit isn't to resolve everything — it's to surface what needs resolving before Stage 3 locks in the technical decisions. Any dependency left unexamined here becomes a bad assumption made by your build tool AI during the build. Catching it in Stage 2 costs an afternoon. Catching it in Stage 4 costs a rebuild.

SomaVelo is a live example of this in practice. One of the core dependencies is bike geometry data — specifically, whether 99Spokes has an API that exposes the frame measurements the fit engine needs. That dependency is named and currently under validation. The app doesn't advance to Stage 3 until that question has a real answer. Not an assumption. An answer.

Monetization: decide now, not during the build

Stage 2 also forces a monetization decision — not a final one, but a committed one. The options are not complicated: ads, subscription, one-time purchase, affiliate revenue, or freemium with a paid tier. Each has different implications for how you build, how you distribute, and what the first 90 days look like after launch. Deferring the decision to Stage 4 means your build tool AI will make the decision for you by default — which usually means it makes no decision at all, and you ship something with no monetization path and have to retrofit one later.

The monetization question also connects directly back to the credit card question. If you can name who pays and when, you can usually name how. A B2B tool where the trigger is a workflow bottleneck probably converts on subscription. A consumer tool where the trigger is a one-time purchase decision probably converts on a one-time fee or affiliate. The trigger moment and the monetization model should be consistent with each other. If they aren't, that's a signal the credit card question hasn't been answered fully yet.

The gut-check no one wants to do

Stage 2 ends with one more question that belongs in the documentation even if it's uncomfortable to write down: if this app takes three months to build and earns $300 a month at maturity, is it still worth building?

For a traditional startup, the answer would almost always be no. For a solo founder building a portfolio of AI-assisted apps, the answer is genuinely situational. Some apps belong in the portfolio because they demonstrate a capability or address a niche with high strategic value even if the revenue ceiling is low. Some don't — and admitting that at Stage 2 is far less painful than admitting it after the build.

The gut-check isn't a financial model. It's a honesty prompt. Write the answer down. If you can't justify it in two sentences, the idea probably needs more validation before it earns a Stage 3 commitment.