You shipped it. The landing page is up, the signup flow works, the database is empty and staying that way.
This is the part nobody warns you about, and the advice you find is useless in a specific way: it's all written for companies that already have 10,000 users and want 100,000. Growth loops, paid acquisition, funnel optimization — none of that applies when your funnel has four people in it and two of them are your co-founder's browsers.
Getting to 100 is a completely different job. It isn't marketing. It's about a hundred individual conversations plus two or three assets that keep working after you stop pushing them. Here's the order I'd do it in.
Step 0: Decide who the 100 are, and make it uncomfortably narrow
"Developers" is not an audience. "Small teams" is not an audience.
"Solo Django devs who freelance and hate writing invoices" is an audience — because you can list them. You can name the subreddit, the Discord, the three newsletters, the GitHub topic, the hashtag. If you can't write down five specific places your user already hangs out, you haven't picked an audience, you've picked a demographic.
The test: could you make a spreadsheet of 100 real names? If yes, you're ready. If no, narrow it until you can. You will widen later — every company does — but you cannot start wide. Wide means invisible.
Write the list. Literally, a spreadsheet. You'll use it in step 3.
Step 1: Give away a working piece of your product, with no signup wall
The single highest-leverage thing a technical founder can build for distribution is a small free tool that fully solves one query.
Not a demo. Not a "free trial." A page that does one useful thing, immediately, for a stranger who has never heard of you: a converter, a calculator, a formatter, a validator, a generator. Whatever the smallest atom of your product's value is, extract it and put it on a public URL.
Why this beats writing blog posts: an article is a promise that you're smart. A tool is proof. And unlike an article, you can generate many of them from one registry:
// one entry → one route, one sitemap line, one landing page
export const TOOLS = [
{ slug: 'invoice-generator', name: 'Invoice Generator', component: InvoiceGenerator },
{ slug: 'regex-tester', name: 'Regex Tester', component: RegexTester },
{ slug: 'json-formatter', name: 'JSON Formatter', component: JsonFormatter },
// ...
] as const
Every entry is one more long-tail search query you now answer. On the product I work on we run about 62 of these — regex tester, JSON formatter, currency, loan, contrast checker, QR — and the point isn't the tools themselves, it's that each one is an entrance that keeps existing while I sleep.
Two rules that decide whether this works:
- The tool must completely solve the problem. A calculator that shows 80% of the answer and then asks for an email converts once and burns your name permanently.
- The upsell is one line at the bottom. "Need this as part of a bigger workflow? →" That's it. No modal, no banner.
This is the only step here that compounds. Do it first so it has time to age.
Step 2: Search for the complaint, don't broadcast the solution
Everyone tells you to "post on Reddit and Twitter." Then you post, and nothing happens, because you broadcast into a feed that owes you no attention.
Invert it. Instead of publishing, search — every day, for the words your user types when they're frustrated:
- Reddit and HN search for your problem phrased as a complaint
- GitHub issues on adjacent repos ("is there a way to…")
- Discord/Slack community search
- Stack Overflow questions with no accepted answer
- X/Bluesky search for the phrasing, not the category
Then answer the question completely, for free, without linking to yourself. If your answer is genuinely the best one in the thread, one of two things happens: someone asks what you use, or someone clicks your profile. Both convert far better than a link nobody asked for.
This is slow. Ten to twenty minutes a day. It is also the single most reliable source of the first 30 users I've ever seen, and it has a zero dollar CAC.
Step 3: Send 10 unscalable messages a day
Take the spreadsheet from step 0. Message ten of them. Not a template — an actual message that proves you looked at what they do.
The version that works is short and asks for nothing:
Hey — saw your post about spending Sundays on invoices. I built a thing that generates them from a sentence. Not selling you anything, genuinely just want to know if it's useless. Here's a link, no signup: [link]
What makes this work is the no signup. You are asking for two minutes, not a relationship. Half will ignore you. A few will try it. One or two will reply with the most valuable thing you'll get all month: the reason they wouldn't use it.
Ten a day for two weeks is 140 messages. That's your first 20–30 users and your entire early roadmap.
Yes, it doesn't scale. That's the point. Nothing that scales works at n=0.
Step 4: Ship visibly, so you always have something to say
The reason most founders go quiet on social is that they have nothing to post, because "still working on it" isn't a post.
Fix the supply problem, not the discipline problem: make your changelog a channel. Every shipped thing becomes a short public note — what changed, why, who asked for it. If you automate the ingest (merged PRs → drafted entries → you approve → publish + auto-post), the bottleneck becomes did we ship anything this week, which is the only bottleneck you want.
This does two jobs at once. It gives you a permanent reason to appear in front of people, and it's the proof-of-life signal every prospect quietly checks before trusting a small product.
Keep a human approving each line. An unreviewed pipeline will eventually announce fix: null check in payments guard to your users.
Step 5: Launch to a warm list, not a cold internet
Most first launches fail because they're the first time anyone hears the name.
Launch day should be the day you cash in attention you already built, not the day you go looking for it. That means steps 1–4 happen for four to eight weeks first, you collect every person who replied, tried it, or gave feedback, and on launch day you tell them — personally — before you post anywhere public.
Where to post, in rough order of effort-to-payoff for a dev product:
-
dev.to with
#showdev— this is the tag explicitly meant for "I built this," so you can be direct without annoying anyone - Hacker News (Show HN) — brutal, honest, occasionally life-changing; post the thing, not the pitch
- The niche community you identified in step 0 — usually higher quality traffic than HN, at 1% the volume
- Product Hunt — worth one shot, but treat it as a spike, not a strategy
A launch is a spike. The tools from step 1 and the changelog from step 4 are the baseline. Spikes feel good; baselines are what get you to 100.
Step 6: Make the product carry its own name
Every artifact your product produces is a distribution opportunity, and most products throw it away.
If a user creates something shareable — a doc, a board, a form, a report, an invoice, a public link — then the shared version should be beautiful, load fast for someone with no account, and carry the smallest possible "made with" mark. That's how Calendly, Typeform, Loom and Figma all grew, and it's the one loop that works without you doing anything.
Rules so it stays classy: the mark is small, it's on shared/public views only (never on the user's own workspace), and it's removable on a paid plan. Aggressive branding on someone else's work makes them stop sharing, which kills the loop you're trying to build.
Step 7: Make your first users' requests visible and fast
At 100 users, your feature request queue is not a backlog. It's your best marketing asset.
When someone asks for something small, ship it fast and tell them by name. We publish a commitment on this — ask for a tool you need and we build it in 3–7 days, with the deadline stored as a date on the request so the clock is public rather than aspirational:
type FeatureRequest = {
requestedAt: string
promisedBy: string // requestedAt + 7d
shippedAt?: string
}
The mechanism matters less than the effect: a user who watched you build their idea in a week doesn't become a customer, they become a source of customers. That's the cheapest referral program that exists, and at this stage you can actually honour it — which is a structural advantage you will lose at 10,000 users, so spend it now.
Step 8: Add a source column and read it monthly
Do this on day one and it costs you fifteen minutes; do it at user 500 and you'll never reconstruct the history.
One column on the signup row. Where did this person come from? Once a month, sort by it. You will find that two of the eight things on this list produced almost everything and the rest produced nothing — and that which two is different for every product, which is exactly why nobody can tell you in advance.
Kill the bottom two. Put that time into the top one. Repeat.
What to skip entirely at this stage
- Paid ads. With no conversion data, you're paying to learn something a hundred conversations teach you for free.
- SEO articles about your product category. You will not outrank anyone in year one. Tools (step 1) rank; think pieces don't.
- A rebrand, a redesign, a new landing page. These feel like progress and are procrastination in a nice font.
- Cold email at volume. Ten thoughtful messages beat a thousand templated ones, and don't get your domain burned.
- Waiting until it's ready. It will not be ready. Users at n=10 forgive rough edges that users at n=10,000 will not — early roughness is a discount you only get once.
The honest summary
The first 100 users come from: one thing that compounds (free tools), one thing that's daily and unglamorous (answering questions where they're already asked), one thing that doesn't scale (personal messages), and one thing that keeps you visible (shipping in public). Everything else is optimization you can't afford yet.
None of it requires a budget. All of it requires four to eight weeks of doing the boring version, consistently, while your instinct screams that you should be building features instead.
Build the features too. Just not instead.
Disclosure: I work on Xenition, which is where the free-tools and 3–7 day request examples come from — those are things we actually run, not hypotheticals. Happy to go deeper on the implementation of any of this in the comments.
