How to Get Your First 100 Users as a Solo Dev

The first 100 users rarely arrive from one clever tactic. They arrive from a small set of channels, repeated with patience, pointed at one clear landing page. This guide is a practical order of operations for a solo developer with limited hours — what to set up first, what to skip, and how to avoid the two most common failure modes: building in silence, and marketing a product that is not ready to keep anyone who tries it.

Before channels: get one page ready to receive traffic

Every channel below eventually sends someone to a URL. If that URL is unclear or missing, the channel work is wasted. Before posting anywhere, make sure you have:

• One sentence describing who this is for and what changes for them.
• A way to act immediately — signup, waitlist, or demo link.
• Proof that something real exists: a screenshot, a working demo, or a visible build history.

A public build page that shows real, dated progress does this well because it doubles as proof and as a conversion point. See waitlist from GitHub commits for the mechanics.

Channel 1: build in public, consistently

Posting your actual progress — the decisions, the bugs, the small wins — draws people who like watching something get built, some of whom become users the moment there is something to try. The mechanism is repetition and honesty, not virality.

Consistency beats intensity here. A short post on most shipping days compounds faster than an occasional long essay. See how to build in public as an indie hacker for a full cadence playbook.

Channel 2: communities where your exact user already gathers

Find three to five online spaces (forums, Discord servers, subreddits, niche Slack groups) where people already discuss the problem you solve — not where they discuss your product category in the abstract. Participate genuinely for a while before ever mentioning your project. Then share progress, not pitches, and let interested people ask questions.

This channel is slow but high-trust: users who arrive this way tend to give better feedback and stick around longer than users from a single viral post.

Channel 3: show-and-tell launches

Product directories and launch communities give a short burst of attention. Treat that burst as a spike, not a strategy — use it once your landing page and onboarding are solid enough to convert a wave of curious first-time visitors, and be ready to follow up with everyone who signs up during it.

For the etiquette of promoting without getting flagged as spam, see how to promote a GitHub project without spam.

Channel 4: your existing network, asked directly

Colleagues, former teammates, people you have helped before — a direct, specific message beats a public post for this group. Tell them exactly what you built and exactly what would help (try it, share feedback, forward to one relevant person). Most solo founders undersell this channel out of politeness and lose easy early users as a result.

Channel 5: SEO pages that answer a real question

Search traffic is slow to start and durable once it starts. A small number of honest guides aimed at questions your future users actually type — not invented keyword shells — will keep bringing people long after a single social post has been forgotten. This article is itself an example of that approach.

A simple weekly rhythm

You do not need five channels running at once. A workable weekly rhythm for a solo developer:

• Shipping days: post progress publicly, same day or next morning.
• 2–3 times a week: participate genuinely in one or two communities.
• Once a week: reach out directly to two or three specific people.
• Monthly: write or update one guide aimed at a real search query.

Track signups against effort per channel for a month, then drop whatever produced nothing and double down on whatever worked, even if it feels less exciting than the others.

Signals that a channel is worth keeping

Not every channel deserves equal ongoing effort. After a few weeks, look for these signals rather than raw volume:

• Referral quality: do users from this channel activate and stick around, or sign up and vanish?
• Time cost per signup: a channel that takes an hour for one signup is not automatically worse than one that takes ten minutes for none — track both sides.
• Compounding vs one-off: a guide that keeps ranking is worth more over a year than a launch spike, even if the spike looked bigger on day one.
• Feedback density: channels where users reply and explain themselves are worth more than channels that only produce silent signups, because they tell you what to build next.

Where gittomarket fits

The build-in-public channel above is the one most solo developers abandon first because writing a post every shipping day competes directly with the time you would rather spend shipping. gittomarket automates that specific piece: connect a GitHub repo once, and on shipping days it auto-renders a designed commit stat card and posts it to X, with LinkedIn and Bluesky cross-posts, using AI captions written for your customers rather than a raw commit log. Approval runs through Telegram — tap to approve, or ignore and it posts automatically.

The same shipping day writes an auto blog article from the commits and keeps a public build page live at /w/<slug>with waitlist capture and a dofollow backlink — the "one page ready to receive traffic" from the start of this guide. Free plans get 10 auto-posts a month and a build page from day one; the founding plan is $9/month for the first 20 spots before the price steps up. A live example is gittomarket's own build page. None of this replaces communities, direct outreach, or launches — it just keeps the build-in-public channel running without eating your shipping time.