I've launched a few products at this point, and I've made enough mistakes to know what actually matters versus what's just procrastination disguised as preparation. Here's the checklist I run through before every launch.
1. Set up analytics before you have users
I know it feels pointless when you have zero users, but in a few months you're going to wish you had data from day one. Setting up analytics takes maybe 30 minutes and it means you can actually see what users do in your app, not what you think they do.
I use PostHog for this. It's free for most early stage products, and you can track events, see session recordings, and run basic funnels. Mixpanel and Amplitude work too. At minimum you want to track sign ups, key activation events, and upgrades if you have paid plans. You can add more later, but get the basics in before launch.
2. Set up a feedback board
I skipped this on my earlier projects and regretted it every time. A feedback board is where users can submit feature requests, report bugs, and upvote each other's ideas so you can see what's actually important to them.
Without one, you get feature requests scattered across email, Twitter DMs, support chat, and random Slack messages. You lose track and end up building what you remember rather than what matters. With a feedback board, the most requested stuff floats to the top and you can see exactly how many people want something. When you ship it, you can notify everyone who asked, which is huge for retention.
I think this step is so important that I actually built my own tool for it called UserJot. There are also open source options like Fider if you want to self-host. Whatever you pick, make it accessible from inside your app. The easier it is to submit feedback, the more you'll get, and more feedback early on means fewer bad decisions later.
3. Set up error monitoring
Your app will break, and you want to know about errors before your users tell you, or worse, before they just leave and never come back.
Sentry and Axiom are good options for this. They catch exceptions, show you the stack trace, and tells you how many users are affected. The free tier is enough for most products at this stage. Set it up for both frontend and backend so when something breaks, you have context about what page they were on, what they were trying to do, and what browser they're using. Takes maybe 20 minutes and will save you hours of debugging later.
4. Set up transactional emails
You need to send emails for welcome messages, password resets, receipts, and notifications. Don't try to send from your own server because you'll end up in spam folders and waste days debugging deliverability issues.
I use SES because the API is clean and it's very powerful. Postmark is another solid option. At minimum you want a welcome email for sign ups, password reset, and receipts for purchases if you're charging. You can get fancy with drip sequences later, but for launch just get the basics working.
5. Get your landing page right
I'm not saying spend three weeks on it, but spend more than an afternoon. Your landing page has one job, which is convincing someone to try your product, and everything on the page should support that.
You want a clear headline that explains what it does in one sentence, a screenshot or demo that shows the actual product, some social proof even if it's just one testimonial from a beta user, and a clear call to action with one obvious button. Things like fancy animations, beautiful illustrations, and ten different pricing tiers can wait.
I use Astro for building static landing pages. It's very simple, powerful and can be easily deployed anywhere. A simple test is to show your landing page to someone who doesn't know what you're building and see if they can explain what it does in 10 seconds. If they can't, simplify.
6. Test the critical paths
Before you announce to the world, actually use your product like a real user would. Go through the sign up flow with a new email instead of your test account, try the main thing your product does, go through the payment flow if you have one, test password reset, and sign out and sign back in.
I can't count how many times I've launched something and the sign-up flow was broken in some edge case. If you can, get 2-3 people to test it too because fresh eyes catch things you've gone blind to.
7. Prepare your launch channels
Figure out where you're going to announce before launch day, not during. For most dev tools and products, the usual options are Twitter, Hacker News if it's technical enough, Product Hunt, relevant subreddits, Indie Hackers, and your email list if you have one.
You don't need to hit all of these. Pick 2-3 that make sense for your audience and write your launch posts in advance. You don't want to be crafting tweets while also fixing bugs on launch day.
8. Have a way to talk to users
On launch day, people will have questions, find bugs, and give feedback. You need a way to respond quickly. Email works, chat widgets like Intercom or Crisp work, and Discord servers work if you want to build community.
I usually start with email and my feedback board. The key is to respond fast, especially early on. People remember when the founder replies in 5 minutes and it builds loyalty that's hard to get otherwise.
9. Ship before it's perfect
Your app isn't ready and it never will be. There's always one more feature to add, one more bug to fix, one more design tweak that would make it better. Ship anyway.
The feedback you get from real users in week one will be worth more than the features you'd build in month three. If your core feature works and people can sign up, you're ready enough.
The checklist
[ ] Analytics tracking key events
[ ] Feedback board accessible from the app
[ ] Error monitoring on frontend and backend
[ ] Transactional emails working
[ ] Landing page explains what you do clearly
[ ] Critical paths tested with a fresh account
[ ] Launch posts written for 2-3 channels
[ ] Way to respond to users ready
That's it. The launch itself matters less than you think. What matters is what you do in the weeks after, which is talking to users, fixing what's broken, and building what they actually need. The checklist just makes sure you're not starting from zero when the feedback starts rolling in.
Top comments (2)
axiom is really nice
oh yeah, really nice product.