In this guide 6 sections
Check eight things before launch. Sign-up works end to end, payments settle, a privacy notice exists, backups restore, monitoring raises an alarm and someone reads the support mailbox. Analytics record the key steps, and feedback has a home. Skip polish. Fix anything that can lose money, data or trust.
Can a stranger sign up and reach the point of the product?
Open a private browser window and sign up as a stranger would, using a fresh webmail address, a cheap Android handset and one bar of signal. You will find the broken verification link, the form that rejects an apostrophe in a surname and the button hidden behind the keyboard.
Then try to fail on purpose. Mistype the password. Request a reset twice. Close the tab halfway and return an hour later. Early users forgive a plain design, but they rarely forgive being locked out on the very first day.
Count the screens between the landing page and the first useful result, then cut every field you will not need this month. Each extra screen sheds a few more people. Be ruthless.
- SPF and DKIM set so verification mail reaches the inbox
- Sign-up works on a small phone screen
- A wrong entry shows a readable message
- The first useful result appears within minutes
Money, privacy and the rules you cannot skip
Run one live payment with a real card, then refund it. Test mode hides trouble with webhooks, receipts and failed charges, so replay one webhook twice to prove the customer is not billed or upgraded twice. Then decline a card on purpose.
Write the privacy notice and terms before launch, in plain words. Say what you collect, why, who sees it and how a person asks for deletion. Show it to a lawyer in your market when the product holds health or financial records.
Never keep card numbers in your own database. Hash every password with bcrypt or argon2. These rules are dull, yet breaking them is exactly how a quiet launch turns into a very loud problem within a week.
- One live payment, one refund, one declined card
- Receipts and invoices carry the right business details
- Privacy notice and terms linked from the sign-up form
- A named person who handles deletion requests
Backups, monitoring and the night something breaks
A backup you have never restored is only a hope. Load last night’s pg_dump or snapshot into a scratch database, open a few customer records and write down how long the whole exercise took. That number is your real recovery time.
Add an UptimeRobot-style ping and a Sentry-style error tracker that message a human being, because without them you learn about outages from an angry customer. One alert channel is plenty. Keep it simple.
Decide who is awake. Write down who owns the hosting login, the domain registrar and the right to roll back a release. Make sure two people know each one before the first real customer pays.
- Automatic daily database backup with a tested restore
- Uptime check on the home page and sign-in page
- Error alerts sent to a phone, not a forgotten inbox
- Domain, hosting and code access held by the company
Analytics and feedback decide what you build next
Choose three events before launch: signed up, reached the key action, came back within a week. Send them to PostHog or Plausible and track little else. A dashboard with forty charts and no question behind it teaches you nothing at all.
Give users an easy way to speak. A feedback link in the footer, a reply-to address that a human reads and a phone call to each of your first ten customers will beat any survey widget.
Tag every message as bug, confusing, missing or price. After a few weeks, the pile shows what version two should be, and it is rarely what you guessed in the pitch deck.
Launch small and keep a rollback ready
Invite a short list first. Ten to thirty people you can phone will find the awkward bugs while the damage stays small, and you should open the doors wider only after one quiet week.
Keep the previous release deployable. If a change breaks payments at night, you want to be back in minutes, not rebuilding from a laptop in a taxi. Practise the rollback once while nothing is wrong. It takes ten minutes.
Print the checklist, tick each line with a name and date, and hold a short go or no-go call with everyone who owns a line. An unticked line touching money or data blocks the launch. The rest can follow.
MVP launch readiness sheet
A printable grid with eight rows: sign-up, payments, privacy, backups, monitoring, support route, analytics and feedback. Columns record the test performed, the owner, the date checked, pass or fail and a note. A lower block lists the three analytics events and the rollback steps with the person who may call them.
Open a blank worksheet to printQuestions owners ask
How many users should the first launch have?
Start with a small invited group that you can phone or message directly. Widen the list after a week without serious faults. Early volume matters less than conversations with real users.
Do we need a privacy notice for an MVP?
Yes, if you collect any personal details, including a name and an email address. Keep it short and true. Ask a lawyer to review it when the product handles health, children’s or financial data.
Can we launch without payments?
You can, and often should, if the real test is whether people want the product. A manual invoice or a payment link covers the first customers. Add automated billing once demand is clear.
What can wait until after launch?
Visual polish, extra settings, secondary reports and rarely used screens. Fix before launch anything that can lose money, lose data or lock a person out of their account.