Post-launch week

The daily cadence

Same three rituals every day, at roughly the same times. Rituals beat willpower when you're tired.

• Morning metrics check (15 min): uptime, error rate, traffic, conversions, page-load performance. Compare against launch-day baseline, not against your hopes. Write the numbers down — memory lies, logs don't.
• Midday triage (30 min): work the bug backlog by severity. S1s immediately, S2s same-day, S3s scheduled. Anything unreproducible gets a "needs reproduction steps" note, not a shrug.
• Evening feedback review (20 min): read every user report, support email, and comment from the day. Tag each: bug, confusion (UX/copy problem), or request. Confusion is the most valuable category — it shows you where the product misleads.

Days 1–2: stabilize

• Fix S1s and S2s. Nothing else matters yet — no new features, no redesigns, no "while we're in there."
• Watch for the second-order bugs: the fix for launch-day bug #1 often causes bug #4. Deploy fixes in small batches and watch error rates after each deploy.
• Confirm backups ran on schedule in production and the first post-launch backup is restorable. Your preflight drill was on staging; production is the real test.
• If traffic spiked, check hosting costs and resource headroom — a surprise bill or a saturated server on day 3 is avoidable if you look on day 1.

Days 3–4: learn

• Read the analytics like a detective: where do visitors actually go (vs. where you expected)? Where do they drop out of signup or checkout? One funnel fix this week is worth more than ten features.
• Answer every piece of user feedback, even the ones you won't act on. A fast, human reply in week one creates the kind of early user who forgives week-two bugs.
• Fix the top three "confusion" items — usually copy, onboarding order, or a misleading button label. These are cheap fixes with outsized conversion impact.
• Raise DNS TTLs back to normal if you lowered them for the cutover (see the DNS cutover playbook).

Days 5–7: harden and plan

• Ship the first planned post-launch deploy: the accumulated S2/S3 fixes, behind the same deploy discipline as launch (checklist, smoke tests, rollback ready). Prove the deploy pipeline works as a routine, not just a launch event.
• Review performance properly: real page-load times across devices and networks, largest contentful paint, slow queries. Set a performance budget now, while the site is young and fast.
• Tighten security basics you may have deferred: dependency updates, secret rotation for any credential that was ever in a chat log or screenshot, review of who has production access.
• Write the week-one retrospective (template below) while it's fresh.

Bug triage SLAs for week one

Severity	Definition	Response target
S1	Site down, checkout/signup broken, data issue	Drop everything; fix or roll back immediately
S2	Major feature broken, workaround exists	Acknowledge within 4 hours; fix same day
S3	Minor, cosmetic, edge-case	Log it; schedule within the week

The week-one retrospective

One page, written once, kept forever. Answer honestly:

1. What broke, and what was the actual root cause of each item?
2. Which preflight step caught the most issues — and which step did we skip that we shouldn't have?
3. What did users misunderstand? (Copy/UX fixes for next week.)
4. What surprised us about traffic, conversions, or costs?
5. What one process change would make the next launch smoother?

File it where you'll find it before the next launch. This document compounds — by your third launch it's a private playbook no template can replace.

What not to do in week one

• Don't redesign. You have seven days of data; that's not enough to conclude anything about design.
• Don't add features users "asked for" on day two. Log requests, look for patterns by day seven, then decide.
• Don't turn off monitoring because "it's been quiet." Quiet is what monitoring is for.
• Don't skip the retrospective because you're tired. Tired is exactly when the lessons are clearest.