You shipped it in a weekend. That's exactly why nobody's using it.
The hard part of building a product moved in 2026 — and most makers are still pouring their energy into the part that got easy.
There's a specific kind of quiet that happens about three weeks after launch. The app works. The landing page is clean. You shipped the whole thing in a weekend because Cursor and Claude Code let one person out-build a small 2020 dev team. And then... nothing. A trickle of signups from your own timeline, and then the graph goes flat.
If that's where you are, I want to be clear about something: it's not that your product is bad. It's that "it's live" and "people use it" are two completely different problems, and in 2026 they've never been further apart.
Here's the shift, stated plainly. When building was hard, building was the moat. If you could make something others couldn't, the difficulty itself protected you. That world is gone. The technical barrier to shipping software is the lowest it has ever been, and it keeps dropping. Which means the thing that used to be your edge — that you could actually build it — is now table stakes. Everyone can build it. Some of them can build it this afternoon.
Pieter Levels put it more bluntly than I could: a lot of indie hackers have built fancy AI factories with no money and no traffic. That line stuck with me because it names the trap so precisely. The tooling makes you feel productive. You're shipping features, the commit graph is green, the demo looks incredible — and none of it touches the actual bottleneck, which is that no human being knows your thing exists or has a reason to care.
The uncomfortable follow-up: the makers who look like overnight AI success stories usually aren't. Levels' Photo AI is the famous example, and the part people skip is that he'd spent roughly a decade building an audience before it existed. The AI didn't create the distribution. The distribution was already there, and the AI let him fill it fast.
So what do you actually do about it? Three things I'd argue for, none of them glamorous.
Build distribution before you finish building the product, not after. The instinct is "let me get it perfect, then I'll market it." Backwards. If you don't have a way to reach even 100 of the right people on the day you launch, you don't have a launch — you have a file that happens to be public. Start posting about the problem, in public, weeks before the product is done. Not to hype it. To find out whether anyone else is annoyed by the thing you're annoyed by.
Get specific about one person, not a market. "Founders" is not an audience. "Solo founders who are technical, hate marketing, and just watched their third weekend project get zero signups" is an audience — and if you can describe that person precisely, you can find exactly where they hang out and say the exact sentence that makes them stop scrolling. Vague targeting is the real reason most distribution "doesn't work." It was never aimed at anyone.
Treat distribution as a product surface, not a chore. The best-distributed indie products have a reason built in for one user to pull in the next — a shared output, a public artifact, a result worth screenshotting. If growth only happens when you personally post, you've built a job, not a loop. That's a design problem, and you can solve it the same way you solve any other feature.
I'll admit the bias here. At Murror we spend our days on a product about understanding one person deeply — reflecting someone's emotions back with real insight instead of a generic mirror — and the longer we do it, the more I think distribution is the same skill wearing different clothes. You cannot reach people you haven't bothered to understand. The maker who genuinely knows what their user is frustrated by, at 11pm, in their own words, will out-distribute the one with a better model and a vaguer sense of who it's for. Every time.
The good news buried in all of this: if building is no longer the moat, then the moat is available to anyone willing to do the unglamorous work. Knowing your person. Owning a relationship instead of renting attention. Being early to a workflow before a competitor gets embedded in it. None of that requires funding or a team. It requires you to stop hiding in the part of the work that feels productive and go do the part that actually decides whether the thing lives.
Ship in a weekend, sure. Just don't confuse the weekend with the work.
Replies
WebCurate.co
I agree with this.
Building has become much easier, but getting people to find it is still the hard part. In my experience, distribution, and consistency usually take much more time than writing the code itself.
Murror
@hosseinyazdi exactly — and part of why it feels harder is that code has a clean finish line and distribution never does, so it always feels less "done." the consistency point is the one people underestimate most: it's compounding you can't shortcut or buy your way past. thanks for reading.
Point 4 hit home. The mistake I made too was writing a big pile of posts before launch — Google barely trusts a new site so they just sit there. The ones that worked came later, after I had a few users, answering the exact questions they asked me. Fewer posts, aimed at stuff people were already searching. Thanks for writing this, the after-launch part is the part nobody posts about.
Murror
@saied_alimoradi this is a fair correction and honestly a better version of the point than i made. "write a big pile of posts first" is basically what point one implies, and you're right that a brand-new domain has no trust to spend, so the content just sits there. what actually worked for you — fewer posts, written after real users hand you the exact questions — is the rule i should have led with. "answer the questions they already asked me" is a keeper. thank you.
I'm the case study in your first paragraph. Shipped it, launched here last week, flat. Single digit upvotes, zero signups. So this landed harder than it otherwise might have.
The advice is right. What I'd add is aimed at the people who will read it, agree, and still not do it, because build distribution first is the correct answer and also the one a certain kind of maker nods at and quietly ignores. Not laziness. Some of us find talking about our own work genuinely uncomfortable, and telling that person to post consistently for six weeks before launch is a bit like telling someone who's afraid of water to just swim.
Two things that work for that person specifically.
Your third point is the one that suits them best and I'd promote it above the other two for that audience. If distribution is a product surface then it runs without you being visible. A small made-with mark on whatever your users already share does the posting you won't do. It's the only one of the three that survives contact with someone who hates self-promotion.
Second, pick channels where the content doesn't need an audience to work at all. Directories, registries, search. Saied's point about SEO landing after you have users rather than before is the same shape. The useful one for me was finding the upstream that other directories ingest from, so one submission propagates instead of filling in twenty forms.
On the Levels example, worth flagging what it does to someone starting from zero today. A decade of audience building described as the prerequisite reads as: you should have started ten years ago. Accurate, and unusable. The version I can act on is much smaller, which is to be useful in other people's threads rather than posting about my own. I've done that for one day and had more real conversations than my launch produced. Not a strategy exactly, but it's available on a Tuesday, which the decade isn't.
Murror
@dalemooney this is the most useful comment on the thread and i want to sit with it instead of waving it off. you're right that i wrote "build distribution first" like it was a willpower problem, and for someone who finds talking about their own work genuinely uncomfortable, that's not laziness and i shouldn't have framed it that way. your two moves are the real, usable version of the post: a made-with mark does the posting you won't, and channels that don't need an audience (directories, and finding the upstream that others ingest from so one submission propagates) work whether or not you can bring yourself to self-promote. and "be useful in other people's threads instead of posting about your own" — the fact that one day of that beat your whole launch says everything. that's not a lesser strategy. it's the one that's actually available on a tuesday. rooting for the thing you shipped, and thank you for the pushback.
@monatruong_murror That is a generous reply, thank you.
One thing worth adding, since you may write about this again. The reason being useful in other people's threads works is not that it is a clever workaround for people who dislike self promotion. It is that it inverts who has to care first. Posting about your own thing needs a stranger to care about you before they read a word. Answering somebody's actual problem needs them to care about their problem, which they already do, or they would not have posted it.
That is why it is available on an ordinary Tuesday when self promotion is not. It asks nothing of you that you do not already have.
The honest cost is that it produces nothing that looks like a launch. No spike, no graph, nothing worth screenshotting. What it produces is a small number of people who recognise your name, which is real and unmeasurable, and you have to be willing to work without the feedback for a while.
This is the part I keep coming back to on my own project — it's easier to keep building than to go talk to strangers about the problem, since code has a much shorter feedback loop.
What's worked for me: treat the pre-launch stretch as practice being specific in public. If a stranger won't react to the one-sentence version of the problem, the landing page copy won't save you either. The 'distribution as a product surface' point is the one I'd push on — the cheapest distribution is an output people naturally want to show someone else, not a referral mechanic bolted on after.
Murror
@akbar_b "practice being specific in public" is a sharper way to say it than i managed — if the one-sentence version of the problem doesn't get a reaction from a stranger, no landing page copy is going to rescue it. and you're right to push on the third point: the difference between a shareable output and a bolted-on referral is that the referral asks the user to do you a favor, while a good output just lets them look good to someone else. one of those scales without the user thinking about you at all. appreciate this.
@monatruong_murror Figured I'd toss out one concrete example instead of leaving it abstract: the AI coding tools that spread fastest did it through something people could point at — a generated PR, a public run — not an invite-a-friend prompt bolted on after launch. Probably the cleanest version of "output vs referral" I've seen actually work.