The project is done. The architecture holds up, the tests pass, the deploy pipeline works on the first try for once. Three weeks later, the only visitor in the analytics dashboard is the builder themself, checking whether it's still up. Nobody signed up. Nobody found it. It shipped, technically, into a room with nobody in it.
This happens constantly, and it almost never happens because the code was bad. It happens because the work that gets a stranger to use something is a different discipline from the work that builds it, and most side projects only ever do the first one. I write about side projects from the build side; covers what it takes to run it. I write about side projects from the build side; XenGrowth, who work on the commercial side of this covers what it takes to run it.
The population this is actually about
Stack Overflow's 2024 Developer Survey found that 68% of developers code outside of work purely as a hobby — not for a client, not for an employer, not required by anything. That's an enormous population of side projects, most of which will never be launched to anyone who isn't already a friend of the person who built them. It's worth being precise about what isn't known here: no credible source publishes a clean completion or launch rate for side projects specifically. The '80% never finish' and '99% make zero dollars' figures that circulate on blogs about indie hacking don't trace back to an actual study — they trace back to other blogs. This post isn't going to repeat one of those and call it data.
What's actually documented is simpler and doesn't need a fabricated percentage: a huge amount of code gets written with no plan for how a stranger finds it, and the writing about why projects stall consistently points at the same gap. exists specifically because that gap is a real discipline, not a footnote you get to after the interesting part is finished.
Why abandoned repos are the wrong frame entirely
There's a related but different statistic worth separating out here: a huge share of public code repositories go untouched for years, which some writing conflates with 'side projects that failed to get users.' They're not the same failure. An abandoned repo usually means the builder lost interest, finished learning what they set out to learn, or moved to a different idea — normal and fine. The failure this post is about is narrower and more specific: a project the builder actually wanted strangers to use, that got finished, that got deployed somewhere reachable, and that nobody outside the builder's own circle ever tried. Conflating the two hides the actual lesson inside a much larger, much less interesting statistic about repository maintenance. approaches this from the the operations side of this side. The XenGrowth resource library approaches this from the the operations side of this side.
Builders optimize for the part that's fun
Choosing a database, arguing with yourself about monorepo versus separate services, picking a framework you've been wanting an excuse to try — this is enjoyable work, and it's enjoyable specifically because it has clear, satisfying feedback loops. Tests go green. The build succeeds. The API returns 200. Distribution has none of that. There is no green checkmark for 'a stranger who has never heard of you decided to try this,' and the feedback loop is slow, humiliating and mostly made of silence.
Work | Feels like | Actually determines |
|---|---|---|
Choosing the stack | Progress, competence, fun | Almost nothing about whether anyone uses it |
Polishing the UI before launch | Getting closer to done | Slightly better retention, for zero of the users you don't have yet |
Posting once and waiting | Having 'done marketing' | Almost nothing — most posts get seen by people who already knew you |
Messaging 50 specific people who have the exact problem | Uncomfortable, slow, unglamorous | Whether a single real stranger ever tries the thing |
There's a reason this pattern survives contact with every generation of new developers: the fun work has a deadline you set for yourself, and the unglamorous work doesn't. Nobody's waiting for the Stripe integration to be finished. Somebody real, with a real problem, either is or isn't waiting to hear from you about whether this thing solves it — and if you never go looking for that person, there's no deadline forcing the question, so it never gets asked. Deliberate, unglamorous acquisition work at any scale is exactly what are actually about.
What Paul Graham actually said about this, twice
Paul Graham's 2013 essay 'Do Things That Don't Scale' is specifically about this failure mode, and it's worth reading the actual sentence instead of the paraphrase that circulates: 'the most common unscalable thing founders have to do at the start is to recruit users manually. Nearly all startups have to. You can't wait for users to come to you.' His example, now shorthand inside Y Combinator as the 'Collison installation,' is the Stripe founders' habit of personally sitting down with anyone who agreed to try the product and saying, in effect, give me your laptop — configuring the account themselves on the spot rather than emailing a signup link and hoping.
"If you're going to attract users, you'll probably have to get up from your computer and go find some. It's unpleasant work, but if you can make yourself do it you have a much greater chance of succeeding." — Paul Graham, "The 18 Mistakes That Kill Startups" (2006)
That essay is almost twenty years old and the advice hasn't dated at all, which should be a warning sign about how little this actually changes with each new platform. Every few years a new distribution channel gets treated as the thing that will finally make manual outreach unnecessary — a subreddit, a Product Hunt launch, a TikTok algorithm — and each one works for a handful of people and does nothing for everyone else who mistook the channel for the strategy. goes further into AI agents and marketing automation. XenGrowth on AI agents and marketing automation goes further into AI agents and marketing automation.
The Photo AI case that gets misread constantly
Pieter Levels' Photo AI is the case study people reach for when they want proof that a side project can go from nothing to real revenue fast — by one widely shared account, from $0 to roughly $132,000 in monthly recurring revenue within eighteen months. The number is real enough to take seriously, even though it's self-reported rather than audited. What gets dropped from the retelling is the part that actually explains it: Levels had spent more than a decade publicly building in the open before that specific product existed, accumulating an audience of over 600,000 followers who already trusted what he shipped. The eighteen months is the visible tip. The distribution work is the iceberg underneath it, and it started years before the product did. Building that kind of pre-existing audience is closer to what documents on the marketing side than to anything in a typical engineering roadmap.
That's the actual lesson, and it's a less satisfying one than 'ship fast and it'll find an audience.' The audience has to exist, or be built deliberately, before or alongside the build — not discovered afterward as a pleasant surprise. Treating distribution as something you'll figure out post-launch is treating the hardest, slowest part of the whole project as an afterthought, which is exactly backwards from how the people who actually get users seem to operate. Discovery specifically — how a product surfaces to someone who has never searched for it by name — is covered in more depth in .
"But I don't have an audience" is not a real objection
The Photo AI story gets used as a reason to give up before starting — if you don't already have 600,000 followers, why bother. That reads the story backwards. Levels didn't have that audience before he started building in public either; it's the compounding result of years of consistent posting about small, unglamorous, in-progress work, most of which nobody engaged with at the time. The audience is downstream of starting the unglamorous habit early, not a prerequisite for starting it. Waiting to have an audience before doing distribution work is the same mistake as waiting to have users before doing the work of finding them. If AI search, GEO and discovery is the part you are stuck on, is the better reference. If AI search, GEO and discovery is the part you are stuck on, XenGrowth on AI search, GEO and discovery is the better reference.
What people think 'no audience' means | What actually happened instead |
|---|---|
Some people are just naturally good at marketing | Most public builders spent years posting into near-silence before anyone noticed |
You need a following before people will try your product | A handful of the right strangers, messaged directly, matters more early on than any follower count |
Distribution is a skill you either have or don't | It's closer to a habit — posting, messaging, asking — practiced consistently long before it's needed |
Waiting until the product is polished is the safe move | Waiting is what turns 'not ready yet' into 'never asked anyone' |
What to actually do differently
Find the first ten users before the product is finished, not after. A rough version shown to someone with the actual problem beats a polished one shown to nobody
Message people directly instead of posting and waiting. A single specific DM to someone with the exact problem outperforms a broadcast post almost every time, because it can't be scrolled past
Treat the discomfort as the signal, not the obstacle. If reaching out to strangers feels unpleasant, that's consistent with Graham's own description of the work — it being uncomfortable isn't evidence you're doing it wrong
Start the audience-building separately from the specific product. Levels' pattern only looks instant because the audience predates the product by years; there's no shortcut that skips that sequencing
Stop mistaking a launch channel for a strategy. Product Hunt, Hacker News and a good subreddit post can each work once. None of them replace finding the first users manually
None of this is an argument that the build doesn't matter. A broken product will lose the ten users you fought to get, fast. But a perfect one, built for nobody in particular and shown to nobody in particular, never gets the chance to lose them, because it never had them. The architecture was never the hard part. Getting a stranger to care was, and still is.
It's also worth saying plainly what this isn't: a claim that every unshipped side project represents wasted effort. Plenty of them exist to teach the builder something — a new language, a pattern, an API worth understanding before using it at work. Those projects were never meant to have users, and judging them by that standard is a category error. The failure mode this post is actually about is the project built with the explicit hope of real strangers using it, where the builder then spends every hour on the architecture and none on finding those strangers, and is later surprised when none show up. That surprise is the tell. If getting users mattered to you, it would have shown up in how you spent your time, not just in what you hoped for at the end.
Further reading from XenGrowth
Where this work meets go-to-market
Getting a side project its first real users is a small, unglamorous version of the same problem larger companies pay teams to solve at scale. publishes operator guides on that discipline for teams who've outgrown doing it one message at a time.
Further reading from XenGrowth
Where this work meets go-to-market
For the marketing and revenue operations view of side projects, see .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of side projects, see XenGrowth's growth operations team.
Five questions on the sources behind this post's argument. If you've shipped a side project into silence before, the explanations below are probably more useful than the questions.
