The launch is over when the founder stops refreshing the leaderboard. The useful work has just begun.
The first two days produce defects, praise, confusion, feature requests, sales leads, and noise in one stream. Treating them equally is how a team spends launch energy without learning.
Fix harm first. Study confusion second. Enjoy applause last.
Keep one intake list
Send support messages, comments, analytics anomalies, sales questions, and team observations into one shared list. Record the source, user type, affected step, severity, and evidence.
Do not let each channel become its own reality. Three reports of the same failed verification email may look like three small comments until they sit together.
Reply to people where they contacted you, but preserve the learning centrally.
Triage by consequence
Use four queues:
- Stop: privacy, payment, security, data loss, or widespread core failure.
- Repair now: a serious block with a safe, narrow fix.
- Investigate: repeated confusion or behavior you do not yet understand.
- Later: preference, polish, and speculative requests.
The launch-day runbook should already define the failures that pause or roll back the launch. Do not let public excitement lower that standard.
Answer the person before building the feature
A feature request describes a proposed solution. Ask what the person was trying to do, what happened instead, and why the result mattered.
Several different requests may share one cause. A request for folders, tags, and search may mean the default result is hard to recognize. Repairing the recognition problem could remove all three requests.
Thank the user. State what you understood. Do not promise a delivery date to reward their enthusiasm.
Make narrow changes
Launch traffic tempts founders into live reconstruction. Prefer small fixes with a clear failure, test, owner, and rollback.
Change copy when the promise is misunderstood. Repair the earliest broken step when onboarding fails. Add capacity only when capacity is the observed limit. Keep a timestamped change log so conversion shifts have context.
One fix at a time produces evidence. Five simultaneous fixes produce a better number and no explanation.
Contact the strongest users personally
Find the people who completed the core job, returned, paid, brought real data, or wrote a detailed message. Ask for a short conversation while the experience is fresh.
Also contact a few who began and stopped. Compare the two groups. The customer interview guide helps keep the conversation grounded in what actually happened.
Write the forty-eight-hour note
Record:
- Who arrived and from where.
- Who reached the promised result.
- Where serious failures occurred.
- What changed during the launch.
- Which user type showed the strongest pull.
- What the team will do next week.
Publish a version when the lessons help users or other founders and no private information is exposed. A clear post-launch note can earn more durable trust and links than the announcement itself.
The launch is not successful because attention peaked. It is successful when the next decision becomes less imaginary. Run a short startup launch retrospective before the evidence becomes a flattering story.