Most app ideas don't die in development. They die much earlier — in the gap between "I had an idea" and "I can tell you exactly what problem this solves and who has it." Stage 1 of the Wilde DataLabs Method is designed to close that gap as cheaply as possible, before a single line of code is written, before a single tool is opened, and before the idea earns any more of your time.
The job of Stage 1 is not to determine whether an idea is good. That comes later. The job is to get clear on what the idea actually is — which turns out to be harder than it sounds. In a world where AI tools can turn a rough concept into a working prototype in hours, the bottleneck is no longer execution. It's judgment. Building fast on the wrong idea isn't efficient — it's expensive at a pace you couldn't previously achieve.
The solution-first trap
When most people say they have an app idea, what they actually have is a solution looking for a problem. They've imagined a thing that exists — a UI, a feature, a name — before they've articulated the problem it solves. That mental sequence feels natural, but it's backwards. It produces the most expensive kind of failure in software: something that works exactly as designed and that nobody uses. The build was fine. The idea underneath it was never fully formed.
Stage 1 forces the sequence to reverse. You start with a brain dump — unfiltered, as long as it needs to be — where you write down everything you think you know about the idea. Who has the problem. Why they have it. What they're doing about it today. Why that's not good enough. What a better answer might look like. You're not editing at this point. You're externalizing.
Once it's out of your head and on paper, you do something that feels almost too simple to matter: you write one sentence that describes the problem without mentioning your solution.
If you can't describe the problem without describing your product, you don't understand the problem yet.
This single constraint eliminates a surprising number of ideas immediately — not because they're bad ideas, but because they were never fully formed in the first place. An idea that can't survive a one-sentence problem statement isn't ready for anything that comes next.
The problem statement test
A valid Stage 1 problem statement has three properties. It names a specific type of person. It names a specific friction they experience. And it contains no mention of your app, your approach, or any proposed solution.
Here's an example of a statement that fails the test: "Cyclists need a better way to find bikes that fit them using AI." That's a solution statement wearing a problem costume. The moment "AI" appears — or any reference to your approach — you've jumped ahead.
A statement that passes: "Cyclists shopping for used bikes have no reliable way to determine whether a specific frame will fit their body before purchasing, which causes transactions to stall or fail despite genuine buyer intent." No solution. No product. Just a person, a friction, and a cost.
The difference matters because the problem statement becomes the north star for everything that follows. If it's built around your solution, you'll spend every subsequent stage unconsciously protecting the solution rather than pressure-testing the problem. That's how you end up in Stage 4 with a fully built app solving a problem nobody actually has.
Defining the user — specifically
The second deliverable from Stage 1 is a user definition. Not a persona. Not a demographic. A description specific enough that you could locate real people who match it.
This distinction matters more than it might initially seem. A persona is a design artifact — useful later, but easy to make up. "Tech-savvy millennials who care about fitness" is a persona. It describes no one you could actually find. A user definition is different: it describes a real slice of real people with a real shared experience.
"ITAM analysts at mid-market companies who are responsible for documenting software asset workflows but have no dedicated backlog management support" — that's a user definition. You can find those people. You can contact them. You can ask whether the problem you've described matches their actual experience.
Stage 1 also asks you to list your assumptions explicitly. Every idea rests on things you believe to be true that you haven't verified. The sooner those are written down, the sooner they can be challenged — which is exactly what Stage 2 exists to do.
Stage 1 also assigns the idea to a portfolio category: B2B Niche, Consumer Utility, or Emotional/Sensitive. It sounds like a labeling exercise. It isn't. The category determines everything downstream — how you find users, what validation signals matter in Stage 2, how you price, and how carefully you handle the UX. An emotionally sensitive product touching grief, money disputes, or family conflict requires a fundamentally different build sequence and launch strategy than a B2B productivity tool. Naming the category now means making that decision consciously — not discovering it in Stage 5 when it's expensive to fix.
The stage gate: ten real people
Stage 1 has one exit criterion, and it's deliberately concrete: you must be able to name or locate ten specific real people who match your user definition and would have this problem today.
Not ten theoretical users. Not "there are millions of people who do X." Ten actual people — by name, by LinkedIn profile, by community membership, by whatever means — who you could reach out to right now and ask whether the problem is real.
Before advancing to Stage 2, you must be able to answer yes to all four of the following: (1) You have a one-sentence problem statement that names a specific user and a specific friction with no mention of a solution. (2) You have a written user definition specific enough to locate real people who match it. (3) You have named at least two existing tools or approaches that partially address this problem — and written down specifically why they fall short. (4) You can name or locate ten specific real people who fit your user definition and would have this problem today — not a demographic, not an estimate, ten actual people you could contact.
This gate exists because it's a proxy for something more important: whether you actually understand who you're building for. If you can't find ten people who match your user definition, one of two things is true. Either the user definition is too vague — which means you haven't done the Stage 1 work fully — or the user is so rare that market size becomes a Stage 2 concern immediately. Either way, the gate catches the problem before it costs you anything real.
What this looks like in practice
SomaVelo — one of the apps currently in the Wilde DataLabs pipeline — started as a feeling, not a problem statement. The feeling was: buying a used bike is harder than it should be because you can never be sure it'll fit you without an expensive professional fitting appointment. The idea that followed was predictable: build something that tells you whether a bike fits before you buy it.
That's a solution. Stage 1 demanded a problem.
When I did the brain dump, the actual friction came into focus: used bike transactions stall or fall through because buyers can't confidently answer the fit question from a couch, a driveway, or a Marketplace listing. Size charts are height-only and routinely wrong. Professional fits require hardware, an indoor trainer, and a $100+ appointment — useless in a driveway at 7pm on a Saturday. The result is that buyers either make a blind guess, drive two hours and back for a test ride that ends in regret, or simply walk away from a bike they might have loved.
The problem statement that came out of that dump: Cyclists shopping for used bikes have no reliable, hardware-free way to determine whether a specific frame will fit their body before purchasing, which causes transactions to stall or fail despite genuine buyer intent. No solution. No app. Just a person, a moment, and a cost.
The user definition got sharpened twice. "Cyclists" failed immediately — too broad, no one you could find. "Used bike buyers" was better but still a demographic. The version that passed: cyclists actively evaluating a specific used bike listing who have already decided they want the bike but haven't been able to confirm fit. That's a person in a specific moment with a specific problem. You can find hundreds of them on any given weekend in every Pinkbike or Facebook Marketplace thread where a buyer asks "does this size work for someone who is 5'11 with a long torso?"
Here's what made all of it real for me. Before any of the above was written down, I ran my own measurements through an early version of the logic. My torso and ape index — the ratio of arm span to height — came back longer than average for my height. The output recommended a Cervelo Aspero. Cervelo is a premium road and gravel brand — the Aspero is their purpose-built gravel frame — not the kind of bike you stumble into when you're browsing by size and budget. I'd never have considered it on my own. I found a gently used high-spec model, got a deal, and it became the best bike I've ever owned.
That outcome didn't come from a feature idea. It came from a problem statement that was specific enough to build a real solution against — and a user definition that matched an actual person in an actual moment. That's the whole job of Stage 1.
Discipline scales. Chaos doesn't.
Next in the series: Stage 2 — The question that kills most app ideas.