Vibe-Coded an App? How to Get Your First 100 Users
A launch spike isn't a user base. How to get the first 100 users for an app you built with AI: a narrow audience, manual outreach and compounding channels.
Andrew Nady
· 5 min read
You built the app in a weekend. You posted it on launch day, got a few dozen signups, and by Thursday the dashboard was flat.
That isn't bad luck. It's what happens when the build is the only plan. AI tools made shipping easy for everyone, which means more apps than ever are competing for the same attention, and none of those people owe yours a look.
The good news: the first 100 users don't come from scale. They come from a short list of unglamorous, manual moves that almost nobody bothers to do. Here's the process I'd follow.
Why vibe-coded apps stall after launch
Most apps that stall share three problems, and none of them are technical:
- The app was built before the audience was chosen. "Freelancers" or "small businesses" isn't an audience. You can't find them, so you can't reach them.
- The launch was the whole marketing plan. A launch is one day of attention. Users are a habit you build every week.
- Signups were the goal. A signup who never gets value from the product isn't a user. They're a cost.
Fix those three and the first 100 becomes a to-do list instead of a hope.
Step 1: Pick one audience narrow enough to find
Narrow your audience until you could name ten of them, or point to the exact place they hang out online.
Compare:
- "Freelancers" → impossible to reach.
- "Freelance video editors who bill international clients in more than one currency" → you know which subreddits, Discord servers and Facebook groups to look in, and what they complain about.
A narrow audience feels like it shrinks your market. It actually makes the first 100 possible. You can widen later, once you know who loves the product and why.
Step 2: Go where they already complain about the problem
Your future users are already describing the problem in public. Search for the complaint, not your category:
- Reddit: search the problem in plain words ("hate tracking invoices in spreadsheets"), sort by new, and read the threads.
- Communities: Slack and Discord groups, Facebook groups, LinkedIn comments, niche forums.
- Review sites: one-star reviews of the tools your users currently tolerate are a list of unmet needs.
Then be useful first. Answer the question properly. Mention your app only when it actually solves what the person asked, and say that you built it. Drive-by links get removed and remembered.
Step 3: Do things that don't scale
Paul Graham's essay Do Things That Don't Scale is more relevant now than when he wrote it, because building is no longer the hard part.
For your first 100 users, that means:
- Message people one by one. Fifty thoughtful messages to people who clearly have the problem beat any launch post.
- Onboard the first 20 yourself. Get on a short call, watch them use the app, and keep quiet while they struggle. You'll learn more in one session than in a month of analytics.
- Fix what they hit the same day. Fast fixes turn early users into people who tell others. This is where vibe coding genuinely shines: you can ship the fix before the call ends.
Step 4: Use launch platforms as a spike, not a strategy
Product Hunt, Hacker News (a Show HN post), Indie Hackers and relevant subreddits can send a burst of traffic. Treat them as one-off events, and prepare:
- A one-line description of who it's for and what it does. If it takes a paragraph, you haven't chosen an audience yet.
- A short demo video or GIF of the core action, not a tour of every screen.
- A way to capture people who aren't ready yet, like an email list or a waitlist for the next feature.
- A plan to message everyone who signs up within 24 hours.
The spike fades. The people you talk to during it are what you keep.
Step 5: Start a channel that compounds on day one
Outreach gets your first users. It doesn't scale, so start something that does, alongside it:
- Search and AI answers. Write pages that answer the exact questions your audience types into Google and ChatGPT: comparisons, how-tos, "how do I…" problems your app solves. These keep sending people months after you write them. (It's the same bet I'm making with this blog.)
- Build in public. Share what you're learning, the numbers, and the decisions. People follow a story before they follow a product.
- Integrations and directories. If your users live inside another tool, being listed where they already look is distribution you don't have to rebuy.
Pick one and do it every week. Consistency beats channel choice.
Step 6: Measure activation, not signups
Decide on the one action that means a user got value. For a dating app, it might be a first conversation. For an invoicing tool, the first invoice sent. That's your activation event.
Then track:
- Of the people who signed up, what percentage reached activation?
- Of those, how many came back the following week?
If activation is low, more traffic just fills a leaky bucket. Fix onboarding before you push for more users. I go deeper on this in why your vibe-coded app isn't making money.
Step 7: Ask every early user two questions
- "Where did you first hear about us?" This tells you which channel to double down on.
- "What almost stopped you from signing up?" This tells you what to fix on the landing page and in onboarding.
Write the answers down. After 30 users you'll see patterns you can act on.
A simple weekly routine for the first 100
| Day | Focus |
|---|---|
| Monday | Find 10 new conversations about the problem and reply helpfully. |
| Tuesday | Send 10 personal messages to people who match your audience. |
| Wednesday | Onboard or interview 2–3 users. |
| Thursday | Ship the fixes they asked for. |
| Friday | Publish one useful piece of content for search or social. |
It's not exciting. It works because almost nobody does it for more than two weeks.
Before you push for more users
Make sure the basics hold up. More users means more people finding the holes AI-generated code tends to leave, especially around data access and payments. Run through the production-readiness checklist first. And if you're still not sure the problem is real, go back a step and validate the idea before spending more on distribution.