From a useful conversation to a first completed task
You built an app. Where do the first users come from?
Find people already doing the task your app helps with. Four founder accounts show how to ask, recruit, watch a first attempt and separate interest from actual use.
Before looking for your first users, decide whose task you want to help complete.
You built an app with AI. The link opens and the features work. After showing friends, though, you are unsure what to do next. Where should you share it? Does “looks good” mean someone will use it?
These four sources follow four questions: what people already use, where to meet them, what to check before building a requested feature, and how to distinguish interest from use. Keep one task a newcomer should complete in your app in mind.
The Sungmoon Cho and NOGUEN sources are in Korean; Paul Graham and Joel Gascoigne write in English. Screenshots retain their original language. Korean excerpts below are translated; English-source arguments are paraphrased.
1. Whom should you show it to?
“People interested in AI apps” is too broad. Start with people who already do the task without your feature. Learning how they handle it today can make your introduction more specific.
Sungmoon Cho describes finding the first customers for music-data service Chartmetric. In short calls with people in the industry, he asked which tools they used, what they did with data, and what remained frustrating. He recalls using their specific language in the product description.
A customer-interview question, translatedWhat still feels frustrating or inconvenient when you use that tool?
Describe the problem in words the person already uses. This 2022 retrospective concerns a US music B2B business developed from 2015 onward. Reusing its wording does not guarantee search traffic for your app.
Write down the person’s current task
For an app that turns lecture notes into revision questions, “students who reread notes and write practice questions before an exam” is a more concrete starting point than “students interested in AI.”
- When did you last do this? Separate something they would like to try someday from work they already repeat.
- How do you do it now? Ask about the tools and steps.
- What is frustrating? Before presenting your app, ask what takes time or produces a disappointing result.
Then write one line that names the input and first result: “Turn a page of lecture notes into revision questions,” for example. Adapt it to what your app can actually do.
Opening sections on interviews, descriptions and short demosRead original Meet the creatorSungmoon ChoChartmetric’s founder writes about meeting customers and running the product.This account connects interview questions and customers’ own language with the product description.Read creator guide 2. Where can you meet them?
Before posting the same link on every network, find a place where people ask questions or share experience about the task you can help with. A channel’s reputation for promotion matters less than the relevant work you can see there.
Paul Graham’s essay describes Pinterest’s early interest among designers and recruitment at a design-blogger event. Stripe’s founders helped willing users get started immediately instead of simply sending a link. The point is to recruit and help people directly, rather than wait for them to arrive.
This 2013 essay offers advice and observations about early startups. It does not establish how a platform’s algorithm works today or predict your app’s growth.
Plan for the first attempt after the link
- Find a recent, real question. Read a study group or work community for the problem you address. Do not choose solely by membership count.
- Show one relevant task. Demonstrate notes turning into questions rather than listing features. Check the community’s promotion rules.
- Watch a willing person try. Help if they cannot find a button or choose an input. You do not need to take their account credentials or password.
Record assisted completion separately from independent completion. What you had to explain identifies something to improve before the next person tries.
Recruit and Experience sectionsRead original Meet the creatorPaul GrahamThe Y Combinator cofounder uses early-startup examples to explain recruiting users and helping them start.Photo credit: Dave Thomas, CC Attribution, as stated on the official biography.Read creator guide 3. Will building a requested feature bring users?
“Please make an app version” sounds specific enough to build. But a request and the situation in which someone would use it still need to be checked together.
NOGUEN reflects on developing and launching 1D1S, a habit and challenge service, with AI. People asked for an app after seeing the web version. He built a hybrid app, then a Flutter app, but writes that the people who had asked did not go on to install it.

The screen shows a way to start a record. Building a button and observing someone press it to do their own work are different facts.
Translated from the section on an unhelpful user guideThe people who had asked “Why isn’t there an app?” never installed it.
This Korean maker’s August 23, 2026 retrospective is a counterexample: shipping a requested feature left the task of explaining why to use it. Public app screenshots do not establish installation or retention results.
Ask what the request is trying to solve
- When did you need it? Ask about a recent task they could not complete.
- Can you try that task in the current version? Observe a willing person at the point where they get stuck.
- What one change would let you try again? Choose the next edit around the obstacle: installation, input or explanation.
Installation really can be a barrier; this is not an argument against building an app. Keep “said they needed it,” “tried it” and “used it again” separate so the reason for the next change remains clear.
Launch response, app development and the user-guide sectionRead original Meet the creatorNOGUENRecords the development and launch of personal projects.The 1D1S retrospective discusses AI-assisted development, app formats and participation that fell short of expectations.Read creator guide 4. What counts as actual use?
A person opens your link and leaves an email. That shows interest. Does it also show that the app helped?
Before completing a working version of Buffer, Joel Gascoigne tested a description page that collected emails, then added a pricing-choice screen. He observed which plans people selected and whether they continued to leave an email.

The English account distinguishes interest before the product worked from use and payment after launch. The meaning of a click depends on what the screen was designed to test.
Record the app’s first result
Separate these four actions:
- Visit: Did the person open the app page?
- Attempt: Did they enter their own material and start the core task?
- First result: Did they finish what they came to do, such as producing revision questions?
- Return: Did they use it again when the same need arose?
After a result, ask where they would actually use it. If they never started, observe the step where they stopped. Record payment separately when relevant; registrations cannot stand in for use or purchases.
These are starting points for observation, not universal success criteria. Define one behavior that matters to your app and record what you can actually observe or measure.
Prelaunch pricing choices and email responsesRead original Meet the creatorJoel GascoigneBuffer’s cofounder describes the screens and experiments used during the product’s early development.Useful for distinguishing page visits and registrations from use.Read creator guide Follow one person’s first task all the way through
Connect finding people with improving the product through a person using your app for a real problem. For a study app, your working notes might read:
- Person: a student revising lecture notes before an exam.
- Current method: reread notes and write practice questions manually.
- Result to show: revision questions from one page of notes.
- Action to observe: entering material and generating questions.
- Obstacle: whether the input format is understood.
- Next change: improve the relevant input instruction.
Show the same task to the next person to see whether the edit helps. If sharing a personal project still feels daunting, prepare one result screenshot and one question for the person.
The aim is to learn who tried to do what and where they stopped. For the next iteration, read what people still need to do when AI handles more of the work: defining a useful problem remains part of making the result useful.
Creators in this guide
- Sungmoon ChoChartmetric’s founder writes about meeting customers and running the product. This account connects interview questions and customers’ own language with the product description.
- Paul GrahamThe Y Combinator cofounder uses early-startup examples to explain recruiting users and helping them start. Photo credit: Dave Thomas, CC Attribution, as stated on the official biography.
- NOGUENRecords the development and launch of personal projects. The 1D1S retrospective discusses AI-assisted development, app formats and participation that fell short of expectations.
- Joel GascoigneBuffer’s cofounder describes the screens and experiments used during the product’s early development. Useful for distinguishing page visits and registrations from use.



