A SaaS launch checklist, from idea to first users
Most of a launch happens before the launch post. This checklist follows the order in which the work usually comes: checking that the problem is real, cutting the first version down to one job, making sure a stranger can pay and get help, then launching and learning from the first accounts.
Check the problem before writing code
Talk to people who have the problem, not to friends who will be kind about it. Find them where they already complain about it: a forum, a subreddit, an issue tracker, a professional community. Ask what they do today, what that costs them in time or money, and what they have already tried. When several people describe the same workaround unprompted, the problem is real. When everyone is mildly interested and nobody is looking for a fix, it is not a product yet.
A one-page site that describes the result and the price, with a waiting list or a pre-order, tests whether people will act rather than nod. Say plainly on that page what exists today and what does not.
Ship one workflow
Pick the one job the product does better than what people use now, and leave the rest for later: team accounts, settings, admin screens. The first version only has to do that job reliably for the people you talked to.
Buy the parts that are not your product. Authentication, payments and analytics are sold as services with free tiers; the stack guide compares their prices as read on their own pricing pages. Each part you buy is one you do not have to secure and maintain.
Before telling anyone
Go through the product as a stranger would, on a fresh account: landing page, sign-up, first useful result, payment. Pay with a real card, then refund yourself. Make sure an empty account does not look broken; sample data or a template helps.
Decide what you will measure: one activation event that means a new user got the value (a first project created, a first message sent), and the share of sign-ups that reach it. Add error tracking and an uptime check, so you hear about problems before users do.
Publish the pages that let a stranger trust you: terms of service, a privacy policy that names the services that process personal data, a support address someone reads, and the name of the company behind the product.
Launch where your users already are
Choose two or three places where your users already talk, and read their rules on self-promotion before posting. The guide on first links covers the launch sites and the Show HN rules. Write the post yourself, lead with the problem and how the product solves it, and keep the day free to answer.
Tell the people you interviewed first. They are the most likely first users, and their reaction shows whether the product does what they described.
Learn from the first accounts
The first users teach you more than they pay. Offer each one a short call or a personal message, watch where they get stuck, and fix the steps between sign-up and the activation event before you look for more traffic.
Look at who comes back in the first week and write to those who do not. Ship visible fixes and tell the people who asked for them. If a user offers a testimonial, publish it with their name and their permission; never write one yourself.