How to get your first 100 users after you vibe code an app

Why your vibe coded app has no users yet

Building got cheap. Getting noticed did not. The number of new apps is climbing fast, and most of them never find enough people to matter. If you shipped on Friday and your analytics show you and your cousin, you are not doing it wrong. You are doing the normal thing, which is the hard part.

So the question builders ask in every forum is the right one: is there a playbook? And the second question usually follows right behind it: why does promoting this feel so awkward?

Here is the mental shift that helps: you are not promoting, you are looking for the few people who have the exact problem you solved, and telling them it is solved. That is a favor, not an ad. It only feels awkward when you are talking to people who don't have the problem, which is what a broad launch post does.

The playbook below has three rungs. Each one needs a different kind of work, and skipping a rung is the most common reason people get stuck.

Before you look for users: one person, one problem, one result

Write one sentence: "[Who] uses this to [get what result] in [how long]." For example: "Freelance bookkeepers use this to send overdue-invoice reminders from Xero in two minutes." If you can't fill it in, no channel will save you, because you won't know where to look or what to show.

• Who is a person with a job title, a hobby or a situation, not "anyone who wants to be productive". Builders who went narrow say niche apps are easier to market than apps with wide appeal.
• The result is the thing they'd tell a friend about: the invoice got paid, the recipe got cooked, the workout got logged. Not "an AI-powered dashboard".
• How long matters because your first users will give you about one session to prove it. If the result takes a week to show up, find a smaller result that shows up today.

Then make a demo of that result: a 30-second screen recording, or a before-and-after screenshot. You will use it on every rung.

Users 1 to 10: find them by hand

Your first ten users come from conversations, not from launches. Search for places where people already describe the problem in their own words: subreddits, Discord servers, Slack groups, forum threads, the comments under a popular video in your niche. Search the complaint, not your category. "Clients never pay on time" finds more buyers than "invoicing app".

When you find someone mid-complaint, help first. Answer the question in the thread as if your app didn't exist. If it's useful, and only if the community allows it, follow up with a short private message like this one:

Doing the work for them sounds slow. It is, and it's the point. You'll watch someone get the result (or not) and learn more in one call than from a hundred page views. Expect most messages to go nowhere. One founder in a thread about first users reports 15 beta users from 120 personal messages. That's roughly one in eight, and it's a fine start.

Two warnings. Friends and family give compliments, not usage; one builder describes friends using the app daily while the store page got almost no installs. And communities ban drive-by links for good reason. Another app maker reports about forty signups from one detailed answer that didn't include a link at all. People clicked through to the profile because the answer was good.

Users 10 to 50: pick one channel where buyers already are

By now you know who gets the result and how they describe the problem. Use that to pick one channel and stay in it for a few weeks. Spreading thin across seven channels is how you end up with three signups from each and no idea what worked.

The marketplace row is the one most vibe coders skip, and it's often the best. The founder of xonboard says their first 100 users came through the Xero App Store, and later more than 100 new users a month. Their buyers were already inside Xero looking for exactly that kind of add-on. That's a founder's self-report about users, not paid customers, but the lesson travels: go where the buyer is already shopping for a fix, rather than launching to a general tech crowd.

And the last row comes with a warning someone gives in nearly every launch thread: who actually reads Product Hunt and Hacker News, apart from people who build things? If your buyer is a nurse or a hairdresser, a big launch day there may bring you applause from other makers and no customers.

In whichever channel you choose, lead with the demo of the useful result. "I built X" asks for attention. "Here's last month's invoices turned into reminders in two minutes" earns it.

Check the leak before you pour in more users

Somewhere around 30 signups, open your data and ask one question: of the people who signed up last week, how many came back for a second session? If the answer is close to zero, stop looking for users 50 to 100. A growing signup count with no second session is a leak, and more traffic just makes a bigger puddle.

People leave because they never got a useful result, not because there was no streak or badge. Go back to your first ten users and watch where the result stops happening. We wrote a whole guide on finding that spot: why users don't come back after the first session.

Users 50 to 100: make sharing part of the app

Once people get the result and come back, you can stop doing all the finding yourself. The goal of this rung is that every happy user brings the next one. That only happens if sharing is built into the product, not bolted on as a "Tell your friends!" button.

1. 1

   Share the result, not the app

   Give people something worth sending: a score image for a puzzle, a public report page, a before-and-after card. One reply to a struggling game maker puts it plainly: if players can't make someone curious in one tap, growth stays manual. The share carries your link.

2. 2

   A waitlist people climb by inviting

   If you have a real reason to let people in slowly (your AI costs, a feature still in beta, or you onboard each user yourself), let them move up the line for every friend who joins. Only do this when the line is real. Fake scarcity gets noticed.

3. 3

   Make the first 100 feel first

   Give the first 100 users a numbered Founder badge and a small perk that never goes away. It costs you almost nothing, it rewards the people who took a chance on you, and "I'm #23" is a fun thing to tell someone.

4. 4

   An invite that pays off for both people

   When a friend joins and gets their own first result, give both people something they actually use, like extra credits. Reward the friend's first useful action, not the bare signup.

The famous examples are worth knowing, with their fine print. Harry's ran a one-week prelaunch page where referring 5, 10, 25 or 50 friends earned better free products. The co-founder reports over 85,000 valid emails, about 77% through referrals. But twelve staff seeded it through their own networks after months of preparation, and emails are not purchases.

Robinhood's waitlist let you move up the queue by referring friends, and the founder reports about 50,000 signups in the first week. The initial attention came from Reddit and Hacker News, the promise (free trades) was unusual, and the founder also says earlier products of his failed despite referral efforts. A waitlist amplifies a product people already want. It doesn't create the want.

Want the invite part done properly, with rewards that hold up? Read how to build a referral program that works.

What to skip until you have 100 users

Half of getting your first users is not doing the things that feel productive but aren't. These can all wait:

• Paid ads before you know who the buyer is. Builders report everything from a small ad test that paid for itself to a single install from a search ad. Without a clear buyer and a result that shows up in the first session, ads mostly buy you expensive signups who leave.
• A logo, a brand book and a polished landing page. One clear screenshot of the result does more work. A builder whose friends used the app daily got almost no installs, and the replies pointed at a cluttered store page, not a missing brand.
• Posting in ten places at once. You won't learn which one worked, and you'll get banned from the ones that don't allow promotion.
• Rewards for app store ratings or reviews. Apple forbids forcing a rating to use an app, and Google forbids rewarding reviews at all. Ask for an honest review after someone gets a good result, and leave it at that.
• Big features for every user who asks. Your first ten users will each want something different. Fix what stops them getting the result. Write down the rest.

What to track instead fits on a sticky note: how many people you talked to this week, how many got the result, and how many came back for a second session. If the middle number is low, work on the product. If the last number is low, work on the return. If all three are fine and growth is still slow, that's when sharing and a bigger channel pay off.

Set up the sharing rung in an evening

You built the app with an agent, so build this rung the same way. Lurk turns what your users do into rewards: events come in, rules decide, units change, and every change gets a receipt. You describe what you want in one sentence to your coding agent or to Lurky, and it drafts the rules.

• Founding members: numbered Founder badges for the first 100, plus a perk for life.
• Waitlist jump: move up the line for every friend who joins with your link.
• Referral: a bonus for both people, once per friend.
• Launch day quest: thanks early users who help on launch day.

Your agent works in Staging first, shows you who would have earned what on your real data, and can't take anything live without a person saying yes. See how agents set up Lurk.

None of this replaces the first two rungs. A badge won't find your first ten users, and a waitlist won't fix an app nobody comes back to. But once people get a useful result, it makes the next hundred much less work.