How to Run a SaaS Launch Week: A Day-by-Day Deployment Plan

Launch week concentrates everything your SaaS will ever be into five days: the most traffic your product has ever seen, the most decisions per hour you will ever make, and the least favorable conditions for debugging you will ever face. New customers are signing up while you read logs. The first real payments are clearing while a stranger forms a first impression. Break something on an ordinary Tuesday and you lose an afternoon; break it on launch day and you lose the audience you spent months earning.

The founders who come through launch week energized rather than wrecked have one thing in common, and it isn't luck or a bigger server. They stopped changing the product before the week started and spent the days beforehand preparing: freezing, rehearsing, and writing the messages they hoped not to send. The plan that saves your launch is not launch day's plan. It is the week before.

That's what this guide gives you: a day-by-day plan that starts at T-7, an hour-by-hour routine for launch day, the stabilization work for days 2 through 5, a copy-paste command sheet for the moments when adrenaline is high, a list of what not to touch, and a complete SaaS launch week checklist you can run against your own product. It's written for a team of one or two — and it works precisely because it assumes nobody is coming to help.

The Plan Is the Week Before, Not Launch Day

Here's the most useful reframe in launch planning: launch day is not when the work happens. It's when the results of the work are revealed. Deploying, verifying, watching, responding — every launch-day activity only goes well if it was rehearsed on quieter days, by a calmer version of you.

So the plan runs on a T-minus schedule. Each day before launch has one theme and produces one output:

Day: T-7 — Theme: Freeze and harden — You finish with: A codebase you are done changing
Day: T-5 — Theme: Security and data pass — You finish with: Secrets, backups, and access verified
Day: T-3 — Theme: Dress rehearsal — You finish with: Every money path clicked on the launch build
Day: T-2 — Theme: Rollback and comms prep — You finish with: A timed rollback and pre-written messages
Day: T-1 — Theme: Go/no-go — You finish with: A yes — or a deliberately moved date
Day: Launch day — Theme: Execute and watch — You finish with: Users onboarded while you watch calmly
Day: Days 2–3 — Theme: Stabilize — You finish with: Hotfixes shipped, queues clean, feedback triaged
Day: Days 4–5 — Theme: Retrospective — You finish with: Written notes that make the next launch easier

Two ground rules for the week. Each day's work finishes by early afternoon — tired founders make launch-week-sized mistakes at 11 p.m. And keep a decision log: one file where you write down every "we'll handle that after launch" call. You will not remember them, and the day-4 retrospective needs them.

T-7: Freeze and Harden

One week out, the goal is a product you are done changing. Declare a freeze on risky changes: anything that touches authentication, payments, the data model, or the deploy path stops moving. Bug fixes and copy edits are still allowed. The freeze doesn't mean "no work"; it means "no new risk." Every change you decline this week is a class of failure you don't have to rehearse for.

With the code frozen, harden it:

Run the full verification suite from a clean checkout. Clone fresh, install, run the tests, the linter, and the build. If the build only works on your laptop, learn that seven days out, not launch morning.
Do a restore rehearsal. Your backups are theoretical until you have restored one. Take the latest database backup, restore it to a scratch target, open the data, and confirm the application actually runs against it. (T-5 will verify the backup configuration itself; this is the drill that proves you personally can recover.)
Run a load sanity check. Not a formal load-testing program — a burst. A few minutes of concurrent requests against staging's signup page and your heaviest endpoints while you watch response times, connection-pool usage, and worker memory. You're looking for obvious collapses, not perfection: the query that only appears with twenty concurrent users, the pool that exhausts, the queue that backs up.
Update dependencies — except risky majors. Apply security patches and patch releases. Defer major version bumps and framework upgrades until after launch. A major upgrade is a fresh test cycle you no longer have time for, and it buys you nothing this week.
Deploy the current build to staging and let it sit. The build you launch should have days to bake, not hours. Everything the T-3 rehearsal tests depends on this.

T-5: Security and Data Pass

With the code frozen, spend a day on the launch-week failure classes that never appear in a test suite: secrets, backups, and access.

Secrets audit. Confirm every credential lives in environment configuration and none in the repository. Rotate anything that ever touched a chat message, a support ticket, or git history. Confirm the application's database user has only the permissions the app actually uses, and that you, as a human, use a separate account.
Backup verification. Confirm automated backups are on and actually producing restorable files: the last successful backup timestamp, the retention window, and whether point-in-time restore is available. Managed database platforms often handle this for you — your job is to confirm rather than assume, because an automated backup you never verified is functionally the same as no backup.
Access review. List everything with production access: hosting dashboard, database, DNS registrar, payment provider, email. Remove dormant accounts and contractor access that has ended. Enable two-factor authentication on the registrar and payment provider at minimum. Launch weeks are exactly when a fat-finger or a phishing email does the most damage, so shrink the blast radius now.

T-3: Dress Rehearsal

Three days out, run the launch itself, privately. Deploy the launch build to staging through the real deploy path — the same artifact that will go to production, not "roughly this code." Then click through every money-path flow in a real browser: signup, activation, upgrade, test-mode payment, webhook handling, receipt, and the paths people forget, cancel and downgrade. Go slowly where you're bored. Boredom is where drift hides.

Two rehearsals matter most:

The webhook replay test. Most payment providers let you resend test-mode events to your endpoint. Replay a subscription update and a failed payment, then confirm your handler survives double delivery and out-of-order events without double-applying them. Webhook handlers written once and never re-tested are the classic launch-week casualty.
The ancillary paths. Password-reset emails, OAuth redirects, and contact forms — anything tied to third-party configuration that references a hostname. Sandbox credentials expire, redirect URI lists drift, and T-3 is when you want to find out.

The dress rehearsal rarely catches application bugs; your test suite catches those. It catches integration drift — the seams between your app and everyone else's — which is what breaks on launch day.

T-2: Rollback and Comms Prep

Two days out, prepare for the version of launch day you don't want to have. An hour here changes the outcome of a bad launch more than any other work this week.

Rollback drill. On staging, deploy a deliberately broken build — pointing at a missing environment variable is suitably harmless — and roll it back. Time it. Find the actual control you would use in production: the releases page in your hosting dashboard, a CLI command, or a redeploy of a known-good commit. If it's one click, bookmark it. If it's twenty steps, write them down. On platforms with blue/green releases the previous healthy release is already warm and rollback is a traffic switch — verify how that works now, not during an incident.
Status templates. Write your investigating, monitoring, and resolved updates today, while calm, and commit to a next-update time in each — never a fix time. During an incident you will write worse sentences than you think.
Support canned replies. Three of them: "we know, we're on it," "known issue with a workaround," and "thanks — that's new to us, here's what happens next." A launch-day inbox rewards the founder who can reply in ninety seconds.
Monitoring thresholds, agreed with yourself. Write down the numbers that mean act: error rate above X% for five minutes, p95 latency above Y, queue depth above Z and climbing. At 11 p.m. with a spike on the graph, you don't want to be debating whether this is normal. That debate should have happened two days earlier, on paper.

One more habit: bookmark your platform's public status page — Deployxa's is here. The first question of every incident is "is it them or me?", and answering it from memory costs ten minutes you'll wish you had.

T-1: The Go/No-Go Checklist

The day before launch, you build nothing. You verify, and you sleep. Run this list honestly:

[ ] Latest database backup restored to a scratch target this week and inspected
[ ] Rollback rehearsed and timed; the rollback control is one bookmark away
[ ] Launch build has been healthy on staging since T-3, health checks green throughout
[ ] Every money-path flow completed on the launch build, including cancel and downgrade
[ ] Webhook replay passed; payment provider confirmed in test mode
[ ] Monitoring thresholds written down; one test alert received on your phone, end to end
[ ] Custom domain resolves with valid SSL on every hostname (this was done before T-7)
[ ] Status templates and support replies saved somewhere reachable offline
[ ] On-call is you; your calendar is clear; you have slept
[ ] Announce time decided and written down

Then apply the only launch-week arithmetic that matters: a no-go costs you a week, a bad go can cost you the launch. If any money-path item or the rollback drill failed, delay — quietly, without drama, to the next date that lets you fix it. Nobody remembers a launch that slipped five days. Customers remember the product that was broken when they tried it.

Launch Day, Hour by Hour

Deploy early in your morning, not at peak. If your customers share your timezone, a 7 a.m. deploy gives you hours of light traffic to find problems in before the crowd arrives. Deploying at 5 p.m. on launch day means your first release of the day happens in front of the largest audience you've ever had.

Time: 07:00 — Action: Deploy the launch build — What "good" looks like: Health checks pass before traffic switches; the prior release stays warm
Time: 07:15 — Action: Verification pass — What "good" looks like: Health endpoint 200, homepage renders, signup completes with a real email
Time: 07:30 — Action: Money-path check — What "good" looks like: You personally complete a test-mode checkout and the webhook upgrades the account
Time: 08:00 — Action: Announce — What "good" looks like: Only now — after your own signup and checkout have worked
Time: 08:00–12:00 — Action: Watch loop every 30 minutes — What "good" looks like: Signups completing, first real checkout lands, error rate flat, queue depth flat
Time: 12:00–13:00 — Action: Lunch away from the deploy button — What "good" looks like: No changes made hungry
Time: 13:00–18:00 — Action: Watch loop continues; triage feedback — What "good" looks like: No repeat errors; every message gets a reply
Time: 18:00 — Action: Daily close — What "good" looks like: Open items written down; nothing non-essential shipped

The watch loop is four things, checked every thirty minutes: the signup flow (complete one from an incognito window), the first real checkout (confirm the payment actually upgraded the account, not just that the webhook endpoint returned a 200), the error rate (your dashboard or error tracker), and queue depth (background jobs, emails, webhook retries — queues are where launch-day problems go to hide).

And the freeze rule, which matters more than anything else on this page: no non-hotfix deploys during peak hours. If it isn't fixing a live problem, it waits for the evening trough or next week. Hotfixes ship one at a time, get verified immediately afterward, and are always made with the rollback in mind. Most launch-day disasters are not the first deploy — they're the "quick fix" pushed at peak, unverified, while frustrated.

Days 2–3: Stabilize, Don't Build

The spike passes; the debris doesn't. Days 2 and 3 have a cadence, and it is deliberately boring:

Hotfix cadence. Batch the small fixes into one deploy at the evening trough, once a day at most. Urgent fixes ship alone and get verified alone. The goal is that at any given moment, you can say exactly what is running in production.
Queue cleanup. Retry backlogs, dead-letter entries, emails that gave up — fix the cause first, then replay what should have gone through. A cleaned queue on day 3 is the difference between "that week was noisy" and "why is this customer's account still wrong."
Watch the money path again. Days 2–3 are when the first renewals, upgrades, and failed-payment retries fire — code paths that may not have run at real volume yet. The launch spike tested your signup; the billing cycle tests your revenue.
Thank-you and feedback triage. Reply personally to every early customer — two lines from the founder beat any onboarding sequence. Tag every piece of feedback now / next / never, and stop re-deciding it.

Your only jobs on these two days: users in, money working, errors trending down. Features are for week two.

Day 4–5: The First Retrospective

Before the week fades into ordinary operation, spend 30–60 minutes writing down three answers. Blameless rules apply even when there's only one of you: your past self made decisions with the information it had.

What broke? Every incident and near miss, with how you found out — alert, customer, or luck (the honest answer is usually the instructive one), how long recovery took, and the one change that would have prevented it.
What did the metrics say? Signups against activations, checkout completion, error rates and latency at peak, queue peaks. Compare them with the thresholds you wrote at T-2. The week just ran the experiment on whether those numbers were right; recalibrate anything it proved wrong.
What changes before the next launch? Edit the checklist while the memory is fresh, adjust the thresholds, and note the investments the week earned — real alerting, a formal load test, a second person on call. Launch two should be calmer than launch one, and this document is the only mechanism that makes it so.

The Launch-Week Command Sheet

Everything below uses fictional values — app.example.com, queue:default, /var/log/app — so swap in your own, and test each command on staging during T-3. A command sheet you have never run is just text.

# HEALTH — after every deploy, and hourly on launch daycurl -sS -o /dev/null -w "%{http_code}\n" https://app.example.com/healthz# expect: 200 # SIGNUP PATH — a 200 is not enough; also complete a real signup in a browsercurl -sS -o /dev/null -w "%{http_code} -> %{redirect_url}\n" https://app.example.com/signup # ERROR COUNT — 5xx responses in the current access log (adjust path and format)awk '$9 ~ /^5/ {c++} END {print c+0}' /var/log/app/access.log # QUEUE DEPTH — pending jobs in a Redis-backed queue (adjust to your job system)redis-cli LLEN queue:default # LAST BACKUPS — freshness check, so you never assumels -lh /backups | tail -n 3

# ROLLBACK — verify these steps on YOUR platform during T-2, never during an outage# 1. Open your hosting dashboard -> Releases (or Deployments)# 2. Select the last known-healthy release# 3. Roll back, then watch health checks pass before you leave the page# 4. Post the status update below; diagnose in staging, not in production # STATUS UPDATES — fill the brackets; commit to a next-update time, never a fix time[Investigating] 14:05 UTC - Some customers may see errors or slow signups onapp.example.com. We are investigating and will post an update by 14:35. [Resolved] 15:02 UTC - A bad release caused signups to fail between 13:40 and14:55 UTC. We rolled back at 14:55 and monitored until 15:00. All systems arenormal, and no customer data was affected.

What NOT to Do During Launch Week

The freeze only works if it covers more than code. Each of these is a change class that reopens risk you closed at T-7:

Don't: Schema changes and migrations — Why it can wait: A failed migration under peak traffic has no fast undo, and old and new app versions share one database during any deploy — Do instead: Ship needed migrations before T-7; defer the rest
Don't: Dependency upgrades (majors) — Why it can wait: A major bump is a fresh test cycle, not a patch — Do instead: Security patches only; schedule majors for the week after
Don't: Infrastructure moves — Why it can wait: A new CDN, host, or DNS reshuffle invalidates everything you rehearsed — Do instead: Freeze the topology; infrastructure moves are a project, not a Tuesday
Don't: Big marketing stunts on untested infra — Why it can wait: A 10x-traffic stunt stress-tests infrastructure you froze days ago — Do instead: Let the launch itself be the traffic event; stunts wait two more weeks
Don't: New features "while you're in there" — Why it can wait: Every change reopens the risk surface you closed — Do instead: Write it on the post-launch list; ship it in week two

Launch week is a stability event. Stability is the product you're shipping that week — treat everything else as a distraction with a cost.

Where Deployxa Fits in a Launch Week

None of the discipline above belongs to a particular platform, but the platform decides how much of it is ceremony. Here's where Deployxa earns its place on the calendar.

Run the T-3 dress rehearsal on a separate non-production project: Deployxa deploys Git repositories or local projects as containerized applications with automatic framework and runtime detection, so the same app runs in staging and production without a second build pipeline to maintain. Finish the custom domain and automatic SSL before T-7 — add the domain, create the DNS records, and the platform handles certificate issuance and renewal — so launch week inherits a hostname that already works. Releases are blue/green and health-gated: the new version runs in a standby slot, passes health checks, and only then receives traffic, with the prior healthy release kept warm for a short rollback window in which rollback can be sub-second. That turns the T-2 rollback drill into confirming a control rather than building a procedure. Health checks and logs are visible per deployment from the dashboard — most of what the launch-day watch loop needs — and managed PostgreSQL and MySQL workflows include automated backups that your T-5 verification confirms.

A separate staging project adds some cost — current plans are on the pricing page. And the honest limits: Deployxa won't write your status updates, choose your monitoring thresholds, click through your money paths, or enforce the freeze. If a build fails, AI-assisted build repair may apply bounded fixes before retrying — helpful mid-week, but not guaranteed and never a substitute for your review. The launch-week discipline is yours on every platform; Deployxa's job is to make the mechanical parts boring.

The Full SaaS Launch Week Checklist

Run this list top to bottom, then keep it open all week:

Freeze and harden (T-7)

[ ] Code freeze declared: risky changes deferred, bug fixes allowed
[ ] Full verification suite green from a clean checkout
[ ] One database backup restored to a scratch target and inspected
[ ] Load sanity check run on staging — no pool, memory, or queue collapses
[ ] Dependencies patched: security and patch releases only, majors deferred
[ ] Custom domain live with valid SSL on every hostname

Security and data (T-5)

[ ] Secrets audited; anything exposed rotated; least-privilege database user confirmed
[ ] Automated backups confirmed on, fresh, and restorable, with a retention window you can state
[ ] Access review done: dormant accounts removed, 2FA on registrar and payment provider

Dress rehearsal (T-3)

[ ] Launch build deployed to staging via the real deploy path
[ ] Every money-path flow clicked end to end, including cancel and downgrade
[ ] Webhook replay test passed: double delivery and out-of-order events survive

Rollback and comms (T-2)

[ ] Rollback drilled and timed on staging; the control is bookmarked
[ ] Status templates and support canned replies written
[ ] Monitoring thresholds written down; one test alert received on your phone

Go/no-go (T-1)

[ ] All of the above green; calendar clear; you are rested
[ ] Announce time decided; the no-go rule agreed with yourself in advance

Launch day and after

[ ] Deploy in your morning; verify signup and checkout before announcing
[ ] Watch loop every 30 minutes: signups, checkout, error rate, queue depth
[ ] No non-hotfix deploys during peak hours
[ ] Days 2–3: one batched evening hotfix, queue cleanup, feedback triaged
[ ] Days 4–5: retrospective written; checklist updated for the next launch

A launch week you can enjoy is a launch week you already finished preparing. If your launch date isn't on the calendar yet, put it there — then make the next step small: create a non-production project on Deployxa, deploy what you have today, and run the T-7 freeze list against it. The launch you rehearse is the launch you get to watch instead of firefight.