The vibe coder's distribution checklist — 12 things to do before you launch
A practical pre-launch checklist for indie and vibe-coded apps. Twelve concrete things to have ready before you launch, so your app actually gets seen.
Most launches don't fail on launch day. They fail in the two weeks before it that never happened. The distribution work, the message, the proof, the channels, got skipped because building was more fun, and then the app went live into silence.
This is the checklist that front-loads that work. Twelve things, grouped into four parts. None of them is hard. The trick is doing them before you publish, not wishing you had afterwards. Save it, and tick it off.
Your message (before anything else)
1. A one-line pitch. Under a dozen words, specific enough that the right person thinks "that's for me." If a stranger can't repeat it back, it's not done.
2. A problem story. Two or three sentences: the problem you hit, why existing options didn't fit, what you built. This is what you'll post everywhere, so write it once, well.
3. Who it's for, named. Not "everyone." The specific person. Naming them sharpens everything else and tells you which channels to use.
Your proof
4. At least one honest testimonial. Get one real person to use it and say one true sentence. A new app with zero signal is a risk nobody wants to take first; one real voice changes that.
5. A way to collect more. Set up the simplest possible way to ask every early user for feedback. Proof compounds, but only if you capture it from user one.
6. Numbers you're comfortable sharing. "Built in three weekends," "used by 40 people so far." Small, real numbers ground a launch and read as honest, not hyped.
Your assets
7. A one-click demo. The single highest-leverage asset. If people can try it in ten seconds without signing up, the product makes its own case. Build this before you write a word of copy.
8. A clean landing page. Clear headline naming the user, a demo or screenshots, one obvious next step, a line of proof. Simple beats fancy.
9. Screenshots or a short clip. Most launch channels are visual. A crisp 15-second clip of the thing working is worth more than three paragraphs describing it.
Your channels
10. Two or three chosen channels. Where your named user already gathers, a niche subreddit, a Discord, Show HN if it's technical. Not all of them. Two or three you'll do properly.
11. Early supporters told in advance. A handful of real people who like it and know the date. Not bought attention, just genuine humans who'll show up.
12. A follow-up plan. Launch day is one day. Decide now what you'll post next week and the week after, because distribution is a habit, not an event.
The point of the list
You don't need all twelve to be perfect. You need them to be done rather than skipped, because the skipped ones are exactly where launches quietly die. Run down the list before you publish, and you'll launch into an audience instead of a void.
A few of these, the proof and the channels especially, are ongoing work that's hard to keep up by hand. That's the bet behind Shipyard: honest reviews from real builders and distribution to the right places, so the list keeps getting ticked after launch day too. We're opening the first 50 founding spots now. If the pre-launch work is where you stall, come and build with us.
Frequently asked questions
What should I do before launching my app?
Get three things ready before launch day, your message (a one-line pitch and a problem story), your assets (a one-click demo, screenshots, a clear landing page), and your channels (two or three communities where your users gather, plus early supporters). Preparation is where launches are won.
What makes a successful indie app launch?
Preparation and proof. A clear one-line pitch, a working demo people can try instantly, a couple of honest early reviews, and two or three well-chosen channels, all ready before you launch. The day itself matters less than the two weeks before it.
Do I need a landing page before I launch?
Yes, a simple one. It needs a clear headline that names who it's for, a short demo or screenshots, one obvious next step, and ideally a line of social proof. It doesn't need to be fancy; it needs to make a stranger understand and trust the thing in ten seconds.
