The app works. You built it over a few weekends with an AI coding assistant, it does the one thing you wanted, and you've posted the link in a couple of places. Forty people visit on the first day. Two sign up. By Thursday the visits have stopped.
That story is common enough now to feel ordinary. Tools like Cursor, Lovable, Bolt and Replit have made it far quicker to get from an idea to something people can use. What they haven't changed is the slow part: finding the specific people who have the problem, at the moment they're trying to solve it, and helping them understand in a few seconds that your app is the answer.
When building gets cheaper, being understood by the right person becomes the scarce part. The first users rarely arrive from a single launch. They come from going where the problem is already being discussed and talking to people, one at a time, until a pattern shows you who the app is really for.
Here's a practical way to do that in the first few weeks.
Can a stranger explain your app back to you?
Before you look for users, write one sentence that names the problem, the person who has it and what changes for them. "A budgeting app" is a category. "Splits shared household bills between flatmates and sends each person a payment link on the 1st" is something a stranger can picture, and either recognise or rule out.
Show that sentence and your homepage to five people who might plausibly use the app, and ask them what they think it does. If their answers don't match yours, fix the words before you spend time on distribution. Every channel that follows depends on this sentence being clear.
Where is the problem already being discussed?
Your first users are probably already describing their problem somewhere, in their own words. Useful places to look:
- Communities built around the problem, such as subreddits, forums, Discord servers and Slack groups where people ask for help with it.
- Issue trackers and forums of the tools your users already rely on, where people ask for the feature you've built.
- Search and AI assistants, where people type the problem rather than your product's name. (Our guide on getting your software recommended by ChatGPT covers that side.)
- Your own network, which is less glamorous and often the fastest way to the first ten conversations.
On Reddit, read each community's rules before posting anything about your product. Reddit's content policy asks people to post authentic content in communities where they have a personal interest, and many subreddits ban self-promotion outright. The approach that holds up is the simple one: answer the question that was asked, say that you built the tool if it's genuinely relevant, and make it easy to ignore.
Why talk to users one by one?
Because at this stage you are learning, not scaling. Paul Graham's essay Do Things That Don't Scale is from 2013, and its central advice still applies: early users are often recruited by hand, by founders willing to do work that would make no sense at a thousand users.
In practice that can mean offering to set the app up for someone on a short call, importing their data for them, or watching them use it for the first time without helping. You'll see where they hesitate, which words confuse them and which feature they ignore. That's information no analytics dashboard gives you as clearly.
It also gives you something better than a visit. A person who tried your app with you watching, and told you what they'd change, is far more likely to come back next week than someone who clicked a link from a launch board.
What are launch platforms good for?
They're good for a specific job, done at the right time. Product Hunt suits a usable product ready for public feedback. BetaList is built for early-stage products looking for their first testers. Peerlist Launchpad reaches people who build software themselves. We compared four of them in Where Should You Launch Your Product?.
The mistake is treating a launch as the plan rather than one step in it. A launch can bring a burst of attention from curious people. The people who need your app may turn up three months later, searching for a fix to the problem, long after the launch page has gone quiet.
How do people find your app after the launch?
Mostly by describing their need, not by typing your name. They search for the problem, ask an AI assistant, browse a category or follow a recommendation from someone who uses the app.
So the page people land on should do the work the launch post did. It should explain the problem, who the app is for, what it connects to, what it costs and what someone can do in the first five minutes. A short demo video or a few honest screenshots of the real app help more than polished illustrations of things it doesn't do yet.
Changes are worth sharing too. A new integration or a fix for something users complained about gives people a reason to look again. Announcing for the third time that the app exists gives them very little.
What should you measure in the first weeks?
Visits are the easiest number to watch and the least useful. With small numbers, three signals tell you far more:
- Activation: did the person complete the core action, such as splitting their first bill or creating their first project?
- Return: did they come back in the second week without being reminded?
- Conversation: did they reply, ask a question or tell you what they'd pay for?
Twenty people who activate and five who return are a stronger start than two thousand visitors who leave. Track where each of those people came from, even in a spreadsheet, and put more of your time into the sources that bring them.
A two-week plan
- Day 1: write the one-sentence description and test it on five people.
- Days 2 to 3: list ten places where your problem is discussed, and read their rules.
- Days 4 to 7: answer real questions in two or three of them, and offer a short setup call to anyone who seems interested.
- Week 2: run five to ten of those calls, watch people use the app, and fix the biggest point of confusion.
- End of week 2: rewrite your homepage using the words your users used, then decide whether a launch platform suits the stage you're at.
When should you change direction?
If you've had honest conversations with fifteen or twenty people who match your description and none of them would use the app again, the problem may not be painful enough, or you may be describing it for the wrong people. That's useful to learn early. Try narrowing the audience, or the job the app does, before adding features.
It's also fair to say that some apps grow from a single viral post or a well-timed launch. That does happen, but it's hard to plan for. The steady approach above works whether or not you get lucky, and if you do, you'll have a clearer page and better onboarding ready for the people who arrive.
A place to be found by need
AGMAN is a discovery network built around being found by need. Visitors describe what they need in their own words with Find by Need and see pages that fit, with the reason each one matches. Publishers can share Updates when something changes, and the dashboard shows views, site visits and enquiries separately, so you can see what's actually happening rather than one blended number.
It won't replace the conversations above, and it doesn't guarantee users, traffic or rankings. If a clear, findable page would help, you can publish one from your app's link and review every detail before it goes live.