How to Get Your First 100 Users for a Bootstrapped Product

To get your first 100 users for a bootstrapped product, define what a user is, recruit the first ten by hand from people who already have the problem, onboard them personally, fix what their behaviour reveals, and only then widen the net through one community, one launch venue, your own writing and a permission-based email list. Count people who did the useful thing, not signups, and give each channel a fair test before judging it.

This guide is a method, not a list of places to post. The free marketing channels guide is the list, and the launch checklist covers what to prepare before any of this. Numbers in this guide are targets you set for yourself, not benchmarks, because no source this article could verify publishes a reliable benchmark for a product like yours.

Disclosure: ZeroRaised is a live launch and discovery site for solo and bootstrapped makers. This article makes no claim about its audience or results.

Why 100, and why it is hard#

One hundred is small enough to reach by hand and large enough to show a pattern. With ten users, every opinion is an anecdote. With a hundred, you can see which kind of person comes back, which step loses people and whether anyone pays.

It is hard for a reason that Paul Graham described in 2013: startups take off because the founders make them take off, and the most common unscalable thing founders have to do at the start is recruit users manually. He wrote that founders resist this partly because the absolute numbers seem so small at first (Paul Graham, Do Things that Don't Scale, last checked 14 Oct 2026). That essay was written about venture-backed startups, but the mechanism is the same for a bootstrapped product, and the constraint is tighter: nobody is paying you to spend the time.

The method below is a sequence. Each stage should produce users and information, and the information decides whether the next stage is worth doing.

Stage 0: define "user" before you count anything#

A signup is not a user. A user is a person who did the thing the product exists to do, at least once, with their own data. Write the definition down before you recruit anyone, because it is the number that every later decision depends on.

• Activation event. The one action that shows the person got value. For a note-taking tool it might be a second session with a note saved. For an invoicing tool it might be the first invoice sent to a real client.
• Return event. Did they come back without being prompted? Pick a window that matches the product's natural rhythm: a day for a tool used each day, a month for a monthly one.
• Payment event. If the product is paid, record who paid and when, separately from activation.

Then record the source of every visitor and every signup. Without that, you will not know which of the later stages worked, and the post-launch note you write in a month will be a guess.

Stage 1: find ten people who already have the problem#

The first ten users should be people you can talk to. Not an audience. Not a launch. Ten individuals who have the problem this week.

Where they are depends on the product, but the search is the same:

• People you already know who fit the user profile. Not friends being kind; people with the problem.
• People who have described the problem in public. Forums, issue trackers, reviews of competing products and question sites are full of people explaining exactly what they need. Reply only when you can be useful.
• People who signed up for something adjacent. A waitlist, a newsletter, a tool you built earlier.

Ask them for a conversation, not a signup. The point of the first ten is what you learn. Rob Fitzpatrick's short book on customer conversations, The Mom Test, is the standard reference for asking questions that do not lead the witness; its own description says it covers how to avoid biased feedback and how to figure out whether someone is really going to buy (The Mom Test, last checked 14 Oct 2026). The core of it fits in a sentence: ask about their life and their past behaviour, not about your idea and their future intentions.

Five questions carry most of a first conversation, and none of them mentions your product:

• When did this problem last come up, and what did you do about it?
• What have you tried already, and what happened?
• How much time or money does the current workaround cost you?
• Who else is involved when this goes wrong?
• If the problem went away tomorrow, what would you do with the time?

Write down answers, not impressions. A person who says they would "definitely use" something has told you nothing; a person who describes the spreadsheet they built last month to work around the problem has told you they have it, that it matters, and roughly what a solution is worth to them. Three conversations like that are worth more than thirty signups.

Do not buy a list and do not message strangers in bulk. Apart from being ineffective, in the United Kingdom unsolicited marketing to individuals by email, text or social direct message requires consent, and the soft opt-in exception does not apply to prospective customers or bought-in lists (ICO guide to PECR, last checked 14 Oct 2026).

Stage 2: onboard the first ten personally#

Graham's essay describes what Y Combinator calls the Collison installation: when someone agreed to try Stripe, the founders set it up on the person's laptop on the spot rather than sending a link (Paul Graham, Do Things that Don't Scale, last checked 14 Oct 2026). The lesson is not about Stripe. It is that the first users should not be left to find their own way through a product you have not yet watched anyone use.

• Sit with them, in person or on a call, while they do the first useful thing.
• Say nothing while they are stuck. Write down where they got stuck.
• Import their data for them if the product needs data.
• Follow up within a day with a note of what you fixed because of them.

This is slow by design. Ten personal onboardings will show you the three places where every later user will get lost, and fixing those is cheaper than any marketing.

Stage 3: turn conversations into fixes before widening the net#

After ten users you will have a list of complaints, confusions and requests. Sort it into three piles and treat each differently.

The confusion pile matters most at this stage. If three of ten people expected the product to do something it does not, the positioning is wrong, and widening the net will bring thirty more people with the same misunderstanding.

Go back to the positioning sentence from the launch checklist: the audience, the problem and the result, in the audience's words. Rewrite it with what you now know, then rewrite the homepage to match.

Stage 4: users 10 to 30 through one community#

Now widen the net, but only to one place, and only one that your first ten users told you they use.

Communities are the channel with the most rules, and the rules are consistent across platforms even when the wording differs. Hacker News states it plainly: it is ok to post your own stuff part of the time, but the primary use of the site should be for curiosity, and you should not solicit upvotes, comments or submissions (HN guidelines, last checked 14 Oct 2026). Hacker News also asks people not to post generated text, and to write their own posts (HN guidelines, last checked 14 Oct 2026).

A method that respects those rules:

1. Join weeks before you need anything, and answer questions about the problem without mentioning the product.
2. When you post the product, write it as the maker: what it does, who it is for, what you learned, what feedback you want. Disclose that you built it.
3. Post it once, in the place it belongs. Do not paste the same post into five communities.
4. Reply to every response within the day. The replies are where the users come from.

Read the community's current rules page before posting. They change, and this article cannot summarise them for every community.

Stage 5: users 30 to 60 through one launch venue#

A launch venue, or a side project showcase such as SideProjectors, puts the product in front of people who came to look at new products. That is useful once, and it is useful only if the product can be tried and the venue's audience overlaps with the people you defined in stage 0.

Choose by fit, not by size:

• Show HN is for something people can try now, built by the person posting, who is around to discuss it. Blog posts, sign-up pages and landing pages are off topic, and asking friends to upvote or comment is not ok (Show HN guidelines, last checked 14 Oct 2026). It fits technical users and detailed feedback.
• Product Hunt is free to use, requires a personal account, and lets makers share a launch but not ask people directly to upvote. Not every submission is featured on the homepage (Product Hunt Launch Guide and featuring guidelines, last checked 14 Oct 2026). It fits products whose buyers overlap with makers, product people and early adopters.
• DevHunt accepts only developer tools and offers a free listing with a nofollow link, or a $19 launch for a chosen week (DevHunt FAQ, last checked 14 Oct 2026).
• Boards for bootstrapped makers such as Wonderlaunch, which says it is built for solo developers, bootstrapped founders and indie hackers rather than funded startups (Wonderlaunch About, last checked 14 Oct 2026), and BootstrapArena, which says listings are free and products can launch with or without revenue (BootstrapArena FAQ, last checked 14 Oct 2026).

The Product Hunt vs Show HN comparison and the Product Hunt alternatives guide go deeper on each. Whichever you choose, treat launch day as support work: be present, answer with facts, disclose, and never solicit votes. Hacker News says it penalises or bans submissions, accounts and sites that break that rule (HN FAQ, last checked 14 Oct 2026).

Record visits, activations and conversations from the launch by source. A launch that brings two hundred visitors and three activated users has told you something specific about either the venue or the landing page, and the Product Hunt guide explains how to tell which.

Stage 6: users 60 to 100 through your own writing and directories#

The first sixty came from conversations, a community and a launch, all of which are events. The last forty should come from things that keep working: pages that answer the questions your first users asked, and listings in the places buyers compare tools.

Write the pages your users searched for#

By now you have heard the problem described in the users' own words dozens of times. Write one page for each version of the problem, using those words in the title and the main heading. Google's best practices say to create helpful, people-first content, to use the words people would use to look for it in prominent places, and to make links crawlable so other pages can be found (Google Search Essentials, last checked 14 Oct 2026). The same page says it does not cost money to appear in search, and that meeting the requirements does not guarantee being shown.

If you also publish on a developer platform, keep the search credit on your own site. dev.to supports a canonical_url field in post front matter for exactly this (dev.to editor guide, last checked 14 Oct 2026).

List the product where buyers compare#

Directories are not launches. They are standing pages found by people comparing tools months later. They have readiness rules: SaaSHub, for example, accepts released software and rejects unreleased products, waiting-list landing pages and free subdomains (SaaSHub submission rules, last checked 14 Oct 2026). Use the directory tracker to keep the list short and to record which forms were actually sent.

Keep the list of people who asked#

Everyone who signed up and consented to hear from you is a channel. Email them when something they asked for ships. In the United Kingdom, the rule is consent or the soft opt-in for existing customers, a visible identity and a way to opt out in every message (ICO guide to PECR, last checked 14 Oct 2026). Short, specific, occasional messages are read. Weekly newsletters about nothing are not.

A twelve-week plan#

This is a sequence, not a schedule. Move faster when a stage produces what it should, and stop to fix things when it does not.

If you reach one hundred activated users before week twelve, the plan worked and you should write down why. If you reach week twelve with thirty, the plan still worked, because you now know which stage stalled.

What to measure and what to ignore#

The temptation at this stage is to count what is easy to count. Resist it.

Count:

• Activated users, by source.
• Returning users, by source, in the window you defined.
• Paying users, if the product is paid.
• Conversations that changed what you built.

Ignore, or at least do not optimise for:

• Page views and visitors without a next step.
• Signups that never activated.
• Votes, ranks and badges from launch venues.
• Follower counts.

A vote count does not explain why a launch went the way it did, and a visitor count does not tell you whether the landing page worked. Separate reach from conversion, as the Product Hunt guide describes, and judge each channel on activations.

Mistakes that cost the first hundred#

• Counting signups as users. The number goes up and nothing else does.
• Widening the net before fixing the funnel. Thirty people hitting the same confusing step is not thirty users.
• Posting everywhere on the same day. Nobody gets a reply, and the sources cannot be separated afterwards.
• Asking for votes. Hacker News penalises or bans for it (HN FAQ, last checked 14 Oct 2026), and Product Hunt forbids asking directly (Product Hunt Launch Guide, last checked 14 Oct 2026).
• Messaging strangers in bulk. Ineffective, and in the United Kingdom unlawful without consent (ICO guide to PECR, last checked 14 Oct 2026).
• Inventing traction. A "trusted by" row with no permission and a "used by thousands" line with no data are the fastest way to lose the users who check.
• Stopping at the launch. The launch is stage 5 of 6. The durable channels are what carry users 60 to 100 and beyond.

Where ZeroRaised fits#

ZeroRaised is one of the launch venues a bootstrapped maker can use in stage 5. Its funding policy excludes products that have ever received institutional venture capital or equity through an accelerator, and allows self-funding, revenue funding, friends-and-family funding, crowdfunding and non-dilutive grants. The submission form asks for the evidence described in the launch checklist.

ZeroRaised is live. No traffic, user or launch-result claims are made here.

The Indie Hackers launch guide covers a founder-community post. The vibe coded app marketing guide covers positioning and channel selection after shipping.

When directory submissions fit stage 5, use the free startup directories guide to check eligibility and submission effort before adding a listing.

For a narrower sequence immediately after the product is built, follow the 30-day plan for new SaaS growth.

When a shipped improvement answers earlier feedback, use the release notes guide to make the change and next action clear.

Sources#

• Paul Graham, Do Things that Don't Scale, last checked 14 Oct 2026
• The Mom Test, Rob Fitzpatrick, last checked 14 Oct 2026
• ICO guide to PECR, electronic mail marketing, last checked 14 Oct 2026
• Hacker News guidelines, last checked 14 Oct 2026
• Hacker News, Show HN guidelines, last checked 14 Oct 2026
• Hacker News FAQ, last checked 14 Oct 2026
• Product Hunt Launch Guide, last checked 14 Oct 2026
• Product Hunt featuring guidelines, last checked 14 Oct 2026
• DevHunt FAQ, last checked 14 Oct 2026
• Wonderlaunch About, last checked 14 Oct 2026
• BootstrapArena FAQ, last checked 14 Oct 2026
• Google Search Essentials, last checked 14 Oct 2026
• dev.to editor guide, last checked 14 Oct 2026
• SaaSHub submission rules, last checked 14 Oct 2026
• ZeroRaised funding policy, last checked 14 Oct 2026