How to research your app audience before you build features
· Early AF
You can find a real problem and still build the wrong product — for the wrong person, in the wrong place, with the wrong first feature.
This post is the companion to how to find app ideas people actually need. That one is about spotting problems. This one is about naming who has them before you invent a persona or ship a feature list.
Written for solo app builders, not agencies or general marketers.
Audience is not a demographic slide
“Busy professionals 25–45” is not research. Audience research answers:
- Who already feels this problem often enough to act?
- Where do they already talk about it?
- What have they tried, paid for, or duct-taped?
- What would make a first experiment worth their time?
If you cannot point to real people (posts, reviews, calls), you do not have an audience yet — you have a hope.
Start from evidence you already collected
If you followed the idea-discovery method, you should have dated observations: App Store complaints, Reddit threads, workarounds. Re-read them for who is speaking, not only what they hate.
Mark:
- Role / situation (indie founder, ops person, teacher, freelance designer…)
- Context (shipping alone, tiny team, side project, day job)
- Constraint (time, money, skills, distribution)
- Language they use for the problem (their words beat your jargon)
Patterns across speakers beat one eloquent rant.
Three places to learn audience without a survey
1. Reviews and support-shaped complaints
1–2 star reviews often name the user’s job-to-be-done in the first sentence. Collect who they thought the app was for — and who it failed.
2. Communities where they already gather
Subreddits, Discords, Indie Hackers threads, niche Slacks. Lurk first. Note which questions recur and which answers get trusted. You are mapping rooms, not blasting pitches.
3. Competitor customers (lightly)
Public pricing pages, case-study titles, and “built for X” claims tell you who vendors think they serve. Treat that as a hypothesis to check against firsthand complaints — not as truth.
What to write down (a one-page audience note)
Keep it short enough to use:
- Who — one sentence, specific.
- Where they hang out — 2–3 concrete places.
- Trigger — what makes the problem urgent this week.
- Current workaround — spreadsheet, agency, ignore it, another tool.
- First experiment — smallest way to test reach or willingness (landing page, reply thread, waitlist with a specific promise).
If the note needs a second page of invented psychographics, delete it and go collect more evidence.
Soft product bridge (honest wedge)
earlyaf. helps solo app builders research markets from dated evidence and decide how to reach customers — including a free reviewed daily idea as a public starting point. Reply Radar is a separate surface that queues Reddit/X posts that may be worth a manual reply; it does not auto-reply or run outreach.
Soft next step: Find ideas for my audience, or start from the free daily idea when you want a concrete prompt instead of a blank page.
FAQ
Do I need interviews before I write any code?
Not always. You need evidence. Interviews help when your written trail is thin or contradictory. Ten polite “would you use this?” chats are weaker than a few intense conversations with people already paying in time or money.
Is “solo founders” specific enough?
Only if your evidence is actually from solo founders with the same constraint. If your complaints come from agency ops folks, say that. Specific beats flattering.
How is this different from “ICP worksheets”?
Worksheets invent. This method attaches audience claims to dated sources — then picks a first experiment. No invented volumes, no hub marketing suite claims.
Companion to the idea-discovery post. Soft product bridge only.