How to Get Your First 100 Customers as an Indie Developer

There is a gap between users and customers that most indie developer articles pretend doesn't exist. I spent an embarrassing amount of time living in that gap before I understood it.

Users are people who tried your product. Customers are people who paid for it. Those two groups have fundamentally different relationships with what you built. A user found it interesting enough to sign up. A customer made a decision that your product was worth their money, which means they had the problem badly enough to spend on fixing it, and they trusted that you had the solution. When a customer sticks around past the first billing cycle, that is the closest thing to validation that early-stage building produces.

This guide is specifically about that second group. The how to get your first 100 users guide covers the full tactical playbook for early distribution. This one is more personal and more specific: it's about the paying customer milestone, where those people actually are, and three mistakes I made along the way that I'd rather save you from making.

Why do users and customers require different tactics?

The tactics for attracting free users and converting paying customers overlap in some places and diverge sharply in others. Understanding where they diverge saves a lot of wasted effort.

Free users respond to friction reduction. Lower the barrier to trying something, and more people try it. A no-credit-card free tier, a Product Hunt launch, a Hacker News Show HN post: all of these are excellent at driving signups from people who are curious but not committed. They fill your user count. They don't necessarily tell you anything about whether you've built something people will pay for.

Paying customers respond to problem intensity. They need to feel the pain of the alternative badly enough that spending money on your solution feels like obvious relief. That means you have to reach people who are actively experiencing the problem, not just people who might find the solution marginally useful.

This distinction shapes every tactic in this guide. The question is not "how do I get more people to sign up?" It's "how do I find the people who need this badly enough to pay?"

Where do your paying customers actually hang out?

The honest answer is: not where most founders spend their marketing energy.

Product Hunt is full of indie developers, not buyers. Hacker News is dominated by engineers, many of whom are deeply skeptical of products trying to sell to them. The general startup subreddits are full of other founders, which is great for feedback but thin on customers. These channels have their place, but if you treat them as your primary acquisition strategy for paying customers, you'll wonder why signups don't convert.

The places where paying customers actually gather are smaller, more specific, and oriented around the problem rather than around products. A few examples of what this looks like in practice:

Competitor reviews with specific frustrations. Someone who left a two-star review of a competing product and wrote three paragraphs about what didn't work is more qualified than almost any other prospect you'll encounter. They have the problem, they've tried to solve it, and they're publicly frustrated. That review is a lead. Read G2, Capterra, the App Store, the Play Store, and Reddit threads where people complain about existing tools. Keep a running doc of the patterns.

Niche communities organized around the problem. Not the problem category, but the specific problem. "Budget management" is too broad. "Managing finances with a highly variable freelance income" is the right level of specificity. The subreddit or Slack group where people discuss that specific challenge is where your customers are talking, right now, about the exact thing you built to solve.

Posts from people who tried to solve it manually. Someone who built a spreadsheet to do what your app does automatically is a pre-qualified customer. They care enough about the problem to have spent time on a DIY solution, which means they're not waiting to be convinced the problem matters. Find these people by searching Reddit, Indie Hackers, and Twitter for phrases like "I built a spreadsheet that tracks" or "I've been manually doing X."

Direct conversations with people who asked the question. Anyone who has publicly asked "is there an app that does X?" is describing your product to you. Search for that question. Reach out to the person who asked it. That's about as warm an outreach target as you'll find.

Why does giving value first change the conversion rate?

The most consistent mistake I see pre-100 founders make in communities is showing up with a pitch before they've given anything. The pull to do this early is understandable: you've just shipped something, you're excited, and there's a community of people who look like exactly the right audience. So you post. You get a few polite reactions and zero customers. The community had no reason to trust you. You were a stranger asking for attention you hadn't earned.

The pattern that actually works is the inverse. Participate genuinely for long enough that you become a recognized, useful voice before you ever mention your product. Answer questions in enough depth that the person asking doesn't need to follow up. Share what you've tried and what worked without pushing anything. Point people toward better resources even when those resources aren't yours. Do that consistently and the community starts to have a reason to care when you eventually do mention what you built.

The ratio that I've found works is roughly 30:1: thirty genuine, useful contributions before a single product mention. Most founders have this inverted, which is why most community-based acquisition attempts fail.

What "giving value" actually looks like, at a specific level:

• Answering a question in a community with enough detail that the questioner doesn't need to ask again
• Sharing a framework or approach that makes the reader's problem easier to think about
• Writing up what you tried, what worked, and what didn't, in a space where people are trying the same things
• Pointing someone toward a better resource than you, when yours isn't the right fit

The last one is underrated. Recommending a competitor or an alternative honestly is one of the fastest ways to build credibility in a community, because it signals that your advice is not self-serving.

How do you frame your product as a solution rather than a pitch?

"I built this" is a pitch. "You mentioned struggling with X last week, and I've been working on something that might help" is the start of a conversation about a problem you have in common.

The framing matters because it determines who is doing the work of persuasion. A pitch asks the prospect to talk themselves into caring. A solution frame puts the focus on a problem they've already told you they have, which means you're starting from shared understanding rather than from zero.

The most effective outreach I've done for any of my products follows the same structure. I find someone who has publicly described the problem: a forum post, a tweet, a review, a question. I reach out with a direct reference to the specific thing they said, in their words where possible. Then I offer one of two things: a 15-minute call to understand how they're solving it today, or a link to try what I've built. The second option matters because it gives them an exit that doesn't require explaining themselves to a stranger.

A template that converts reliably:

Hi [Name],

I saw your post in [community] about [specific problem they described]. The part
about [a concrete detail from what they wrote] is the same thing I kept running
into before I built [product].

I'd love to understand how you're handling it today. Would you be up for a
15-minute call this week? Or I can send you a link to try what I have, and
you can just tell me where it falls short.

No pressure either way.

[Your name]

Three things that make this work: the reference to what they actually wrote (proves you read it), the honest framing that you have something and want to know where it falls short (low ego, high credibility), and the out-clause that means it. The follow-up, if they don't respond, should be one message, seven to ten days later, and nothing after that.

How do you recruit beta users who break things instead of testers who confirm them?

Most founders, including me early on, treat beta access like a QA pass. You give someone access, you wait for bug reports, you fix the bugs, and you move on. The result is a slightly more stable product and a group of people who feel like they did you a favor.

That is not how you build advocates.

The beta user who finds the bug in your core flow is valuable. But the beta user who says "I tried to do the thing your product is supposed to do, and I couldn't figure out how" is worth ten times that, because they've found a fundamental problem that technical testing never would. The distinction between a bug and a design failure is often the difference between a minor fix and a complete rethink of your onboarding.

Here's how to recruit beta users who will give you that level of honesty:

Recruit for intensity, not availability. The beta user you want is someone who has the problem so acutely that they've already tried to solve it themselves, and who cares enough about getting it right that they'll be honest when your solution doesn't work. Find them in the same places you find paying customers: competitor reviews, community posts, direct outreach to people who've described the problem publicly.

Set the expectation that breaking things is the job. Tell them explicitly: "I want you to find where this falls apart. If you get stuck, that's useful information for me. If something confuses you, tell me. The goal is not for you to succeed with it, it's for me to find out where it fails." This changes the psychological dynamic from "please try not to be too critical" to "your job is to be critical."

Get on a call, not a form. A written feedback form produces sanitized responses. A 30-minute call where you watch someone use the product and ask "what are you expecting to happen here?" in real time produces the insights that change products. Schedule calls with at least five beta users. Watch them use it. Don't coach. Just watch and take notes.

Follow up when you ship the thing they found. This is the step most founders skip, and it's the one that turns a beta user into an advocate. When you fix the issue they identified or ship the feature they asked for, tell them directly. "I shipped the thing you found. Want to try it again?" That message does something no onboarding sequence can: it proves you listened.

How do you turn early customers into a referral engine?

Referral programs with points and credits and leaderboards are a tool for scale. They start working somewhere around 500 to 1,000 engaged users, when there's enough density in the customer base to produce actual referrals without manufacturing them.

Before that threshold, the better approach is direct and personal: call it what it is, and ask.

Your first 10 paying customers know other people with the same problem. This is almost always true. If someone paid you to solve a problem they were having, there's a reasonable chance they've talked to colleagues, friends, or community members about that same problem. The ask is simple: "Is there anyone you know who deals with this same thing? If there is, I'd love an introduction."

Not "click this link to earn $10." Not an automated email with a referral code. A direct, personal message from you, the founder, asking a specific question about a specific person they might know.

The conversion rate on this kind of ask is much higher than any automated program, for two reasons. First, you're asking a person, not a segment, which means the response is personal rather than reflexive. Second, you're asking for an introduction, not a recommendation, which means the friction is lower because the referring customer isn't putting their reputation on the line with a hard sell.

A few mechanics that help this work:

Make it genuinely easy to refer. If you're asking for an introduction, have a one-sentence description of the product ready that the customer can copy and send. Don't make them write their own pitch. "Here's a quick sentence you can use if you want to forward this to them" removes the blank-page problem.

Ask when the customer is happiest. The right moment for the referral ask is right after they've gotten value from the product. Not on day one, when they're still figuring out the basics. Not after a billing cycle, when the relationship is administrative. After they've done the thing the product was built to help them do, and it worked.

Follow up on every introduction. If a customer introduces you to someone, close the loop with the customer when the introduction converts. "Your intro led to a new subscriber. Thank you, genuinely." This rewards the behavior and makes it more likely to happen again.

Three mistakes I made that cost me months

I am going to be specific here, because the generic version of these mistakes ("don't pitch too early," "talk to your customers") doesn't actually help anyone.

Mistake one: I assumed the App Store would do distribution for me. When I launched Balance Pro, I shipped it, posted a simple announcement, and waited for the App Store algorithm to deliver customers. It doesn't work that way, at least not without a substantial initial ranking push driven by early installs and reviews. I spent the first three months of Balance Pro's life wondering why downloads were flat, and the answer was that I had done zero pre-launch distribution work. No reviews, no community presence, no outreach to anyone who had publicly complained about competing apps. The lesson cost me a quarter that I could have used to build the early reputation the App Store responds to.

Mistake two: I pitched in communities before I had earned any trust. I've done this with more than one product. The pattern is the same each time: the community looked like exactly the right audience, I was too impatient to build credibility before posting, and the result was silence or polite dismissal. The cost that people don't talk about is what comes after: when you pitch too early and get ignored or rebuffed, you've also lost the ability to come back and try again in that community. The same people who saw your premature pitch are still there when you return. Rebuilding from a bad first impression takes three times as long as building a good one from the start.

Mistake three: I treated my beta users like contractors, not collaborators. This is the one I think about most. For an early product, I gave access to about 15 people and communicated with them almost entirely through a feedback form. I got bug reports. I fixed bugs. I never got on a call with a single one of them. When I launched publicly, I launched cold because I'd turned my 15 closest potential advocates into QA workers who felt no particular ownership over whether the product succeeded.

The fix for this mistake is simple and free: talk to your beta users like people, not like testers. Schedule calls. Ask what they hoped the product would do when they signed up. Follow up when you ship the things they asked for. The 15 people who tried your product early enough to be beta users are the seed of your customer community. Treat them accordingly.

What changes once you have 100 paying customers?

The milestone matters for a few specific reasons beyond the revenue.

At 100 paying customers, you have enough data to see real patterns. Which use case is converting. Which persona is churning. Where the product falls short for people who paid but didn't renew. This data doesn't exist at 10 customers and is murky at 50. At 100, the patterns become readable.

You also have enough advocates to start building genuine word of mouth. The referral conversations you've been having one-on-one start to produce their own threads: customers talking to peers, peers signing up without being prompted, new customers arriving who mention a friend sent them. Direct traffic climbs. Branded searches appear. These are the signals that distribution is starting to happen without you pushing it personally at every step.

The last thing that changes is your confidence in the product. There is something specific about having 100 people pay you voluntarily that tells you something no amount of positive feedback ever fully will. It says that the problem was real enough to spend on, and that your solution was good enough to earn the spend. That's a different kind of foundation to build on.

If you're at the start of this journey and want the broader tactical playbook, the first 100 users guide has every channel and template in detail. And when you're ready to understand which specific communities, newsletters, and audiences are most likely to contain your paying customers, GrowthMap does that research in about ten minutes instead of a week, so you know exactly where to show up before you invest months of community-building energy in the wrong room.

The 100-customer milestone is slow and personal. There's no shortcut to the conversations, the outreach, and the trust-building. But the information you collect along the way is the foundation that everything after it is built on.