The Launch Plan

Launch Is Not a Date

There is a version of "launch day" that every engineer has lived through. You have been building for months. The date is circled on the calendar. Leadership has been told. Everyone is excited. The date arrives. And then you discover, on that morning, that your database connection pool is sized for test traffic not production traffic, that one of three dependent teams finished their part the night before and hasn't been tested in combination with yours, and that nobody wrote the runbook for the most likely failure mode.

This is not bad luck. This is what happens when a team treats launch as a date rather than a state.

A date is a point in time. A state is a set of conditions that are either true or false. "February 14th" is a date. "All rollback procedures have been tested, the on-call engineer knows how to execute them, and load tests have passed at 2x expected traffic" is a state.

The difference matters enormously. A date can arrive whether you are ready or not. A state cannot. You cannot lie to a state. You can lie to a date — you can tell yourself the team will "figure it out on the day" — but you cannot lie to a checklist that says "load test passed at 2x traffic: yes/no."

The best launch plans are collections of states. They say: here is what must be true in order to proceed to the next phase. Here is what we will check. Here is who approves it. Here is what happens if any of it is not true. The date is a target, not a commitment. The states are the commitment.

The State Machine Model

Think of your launch as a series of states that your system and your organization must move through. Each state has an entry condition — what must be true before you enter it — and an exit condition — what must be true before you leave it.

Notice that every transition has a condition. You don't get to move from "Pre-Launch Readiness" to "Launch Window" just because the calendar says so. You get to move when the checklist says so. This is the fundamental shift in how you think about launching.

At any state, you can also transition backwards — or sideways to a "blocked" state. If something fails during the launch window, you don't just push through because the date is today. You pause, assess, and either fix it fast or roll back. The state machine makes this explicit and removes the social pressure to proceed unsafely.

Before You Write the Plan

Most engineers jump straight to writing the launch checklist. That's a mistake. Before you write a single item, you need to answer three questions. The answers to these questions determine the entire shape of your plan — which rollout strategy you use, how long your stabilization window is, who needs to be in the war room, and how detailed your rollback procedure needs to be.

The Three Questions

Question 1: What does failure look like, and how quickly will we know?

Some failures are loud. Your service crashes and alerts fire immediately. Some failures are quiet. A subtle data corruption bug that only affects 0.1% of users. A regression in a rarely-used code path. A metric that drifts the wrong direction over 48 hours.

Before you plan the launch, map out the top five ways this launch can fail. For each one, ask: how long does it take for this failure to become visible? How visible is it — loud alarm or slow drift? This tells you how long your stabilization window needs to be, and it tells you which metrics you need to watch in real time during the launch itself.

If your failures are loud (service down, error rate spikes), you might feel confident doing a fast rollout. If your failures are quiet (user-visible bugs that take days of usage to surface), you need a slow rollout with a long stabilization window.

Question 2: What is the blast radius?

The blast radius is the answer to: if this launch goes badly, how many users are affected, and how badly? A launch that affects 100% of users with potential data loss has a much larger blast radius than a launch that affects 10% of users with a slightly degraded UI.

Blast radius determines your rollout strategy. High blast radius means you start with a tiny slice of traffic — 1% or less — and you instrument everything before you roll out further. Low blast radius means you can be more aggressive.

Blast radius also determines whether you need external communications — do you need to notify users in advance? Do you need customer support briefed? Does legal need to review anything? The larger the blast radius, the more of the organization needs to be prepared.

Question 3: Can we roll back, and how long does it take?

This is the question most teams skip. They assume rollback is possible without ever checking. This assumption has caused many very bad days.

Rollback is not always possible. If your launch includes a database schema migration that removes a column, and your new code has been running against that schema for an hour, rolling back means the old code will fail because the column it expects is gone. You cannot simply revert the binary. You have to run a different migration first.

Before you finalize your launch plan, you must answer: what does rollback actually mean for this specific launch? What are the exact steps? How long do they take? Who can execute them at 2am? Have we tested them?

If rollback is difficult or impossible, your launch plan must be significantly more conservative. Slow rollout, longer stabilization, more checkpoints. The difficulty of rollback is inversely proportional to how fast you should be willing to proceed.

Anatomy of a Launch Plan

A launch plan is a document — not long, but specific. It covers three phases: pre-launch, the launch window, and stabilization. Each phase has a set of tasks, owners, and exit criteria. Let's walk through each one.

The Launch Checklist

The launch checklist is the most important artifact in your launch plan. It is the thing that stands between you and shipping something that is going to hurt your users or wake up your on-call team at 3am.

A good checklist has a few properties. First, it is specific — not "monitoring is set up" but "P95 latency alert configured on the payments service, fires to #payments-oncall, threshold 800ms." Second, every item has an owner — a name, not a team. Third, every item is binary — it is either done or it is not done. "Mostly done" and "good enough" are not states on a checklist.

Here is a template. Your specific project will add items. The mistake is removing items without a very good reason.

Rollout Strategies

How you actually deploy matters as much as whether you're ready. There are four main rollout strategies, each suited to different situations. Choosing the right one is a judgment call based on the blast radius, the reversibility of the change, and the confidence you have in your testing.

Big Bang: Everybody Gets It at Once

You flip the switch and 100% of users are on the new system immediately. This sounds scary but is sometimes the right call — particularly for infrastructure changes that can't be partially deployed, or for changes so small and well-tested that the blast radius is genuinely low.

The advantage of big bang is simplicity. There is no complexity of running two versions simultaneously. There are no concerns about what happens at the boundary between old and new. You ship it, it's done.

The disadvantage is that if something goes wrong, it is wrong for everyone immediately. This means your monitoring needs to be extremely good — you need to detect a problem within minutes, not hours — and your rollback needs to be fast and tested.

Gradual / Percentage Rollout: Turning the Dial Slowly

You start with a small percentage of users on the new version — say, 1% — and gradually increase that percentage as you build confidence. 1% → 5% → 10% → 25% → 50% → 100%, with monitoring checkpoints between each step.

This is the most common strategy for significant launches at mature companies. It contains the blast radius at every step. If something goes wrong at 5%, you've affected 5% of users, not all of them. You have time to diagnose before it spreads.

The gradual rollout works best when users are interchangeable — when it doesn't matter which users see the new version. If you have strong user-level consistency requirements (where the same user must always see the same version), percentage rollout can create confusing experiences and you need to be thoughtful about how you implement it.

Day 1 — 08:00  ▶ Deploy to 1%
               Watch for 30 min. Error rate: 0.18% (baseline). Latency P99: 240ms.

Day 1 — 08:35  ▶ Increase to 5%
               Watch for 1 hour. Error rate: 0.20%. No alerts fired.

Day 1 — 09:45  ▶ Increase to 10%
               Watch for 2 hours. Error rate: 0.35%  ← slightly elevated
               Investigate → traced to a noisy log in one service, not a real error.

Day 1 — 12:00  ▶ Increase to 25%
               Watch for remainder of day. All signals nominal.

Day 2 — 09:00  ▶ Increase to 50%
               Watch for 4 hours. No issues.

Day 2 — 14:00  ▶ Increase to 100%
               ✓ Launch complete. Stabilization period begins.

Notice what this timeline makes possible. On Day 1 at 09:45, the team saw a slightly elevated error rate. Because the rollout is gradual, they have time to investigate — it was a noisy log entry, not a real problem. In a big bang deployment, that same observation would have been terrifying. In a gradual rollout, it was a 15-minute investigation during a low-stakes moment.

Feature-Flagged: Decoupling Deploy from Launch

This is the most powerful and flexible strategy. You deploy the code to 100% of servers — but the feature is off for everyone. The code is in production but dormant, controlled by a configuration flag. Then you turn the flag on for specific users — maybe internal employees first, then a beta group, then wider audiences — all without any code deployment.

Feature flags give you something that no other strategy provides: the ability to deploy code and launch features as two completely separate events. The engineer who finishes the code at 10pm on Thursday doesn't have to worry about the launch — they just merge the code with the flag defaulted to off. The launch happens whenever the team is actually ready, on its own schedule.

The most important discipline with feature flags is cleaning them up. A flag that was temporary for a launch and is still sitting in the code a year later is technical debt. The old code path behind the disabled flag is a maintenance burden — it has to be kept working even though nobody uses it. Teams that use feature flags heavily need a strict policy: when a launch is declared stable, the flag is scheduled for removal within a defined timeframe.

Dark Launch: Testing Under Real Load Without User Impact

A dark launch is when you send real production traffic to the new system but don't show the results to users. The request goes to both the old system and the new system. The old system's response is what the user sees. The new system's response is logged, compared, and analyzed — but never shown.

This technique is enormously powerful for high-risk changes where you need to know "will this new system behave correctly under real traffic?" before you commit to showing it to users. The new system gets exercised at full production scale and load, but there is zero user impact if it misbehaves.

Dark launches are not free. Running dual systems at full load costs money and engineering effort. But for launches where the cost of getting it wrong is very high — financial transactions, medical data, critical user-facing calculations — the cost of a dark launch is trivial compared to the cost of a bad live launch.

The Launch War Room

A war room is just a place where the relevant people are gathered — physically or virtually — for the duration of the launch window. The name sounds dramatic, and sometimes the experience is. But mostly it is a quiet room where people watch dashboards and respond quickly when something goes wrong.

Not every launch needs a war room. A small change with a narrow blast radius and a well-tested rollback can be launched by one engineer with a checklist. But for significant changes — new systems, major features, high-volume migrations — a war room is the right call. It exists to reduce the time between "something is wrong" and "we've done something about it" to the minimum possible.

Who Needs to Be There

The war room should be small. Every person you add is another person who might have an opinion, ask a question at the wrong moment, or muddy the decision-making. The right people are:

• The launch commander. One person with the authority to make calls. Proceeds, pauses, rollbacks — all decisions flow through them. They can consult others, but the decision is theirs alone. This role should be designated explicitly in the launch plan, before the launch day.
• The engineer who knows the system deepest. Not the most senior person, necessarily — the person who actually knows where to look when something goes wrong.
• The on-call engineer. They need to see the launch happen so they understand what has changed by the time they're holding the pager alone.
• A representative from each dependent team. If your launch depends on three other services, you want one person from each of those teams who can answer questions quickly and fix things on their end if needed.

Everyone else gets the live dashboard link and an agreement to not interrupt the war room unless they see something the war room doesn't.

The Go / No-Go Call

Before you begin the rollout, you make the go/no-go call. This is a formal moment — not casual, not implied. The launch commander goes through the checklist, confirms every item is green, and asks each team representative: "Are you go or no-go?" Each person must answer explicitly.

This might feel ceremonial. It is ceremonial — intentionally so. The ceremony forces people to be explicit about their readiness. It creates a moment where someone who has a nagging concern can say "no-go" and explain why, rather than staying quiet while the launch proceeds and the concern turns into an incident.

If anyone says no-go, you have two options: fix the issue and repeat the go/no-go, or delay the launch to the next planned window. You do not pressure people to change their vote. A no-go from one person who has a real concern is worth more than a smooth launch that hides a problem waiting to explode.

Rollback: The Plan You Hope to Never Use

Everyone acknowledges that rollback matters. Very few teams have actually tested their rollback. Even fewer have timed it, written it as a step-by-step procedure, and confirmed that the on-call engineer can execute it at 2am under pressure.

Here is the thing about rollback: the only moment you will ever need it is a moment when everything is going wrong simultaneously. Your error rate is spiking. Alerts are firing. Users are complaining. Leadership is asking for updates. In that moment, you cannot improvise a rollback. You execute the procedure you wrote and tested when things were calm.

A rollback plan answers these specific questions:

1. What exactly gets rolled back? Just the binary? The binary plus the database migration? The feature flag plus the binary? Be precise.
2. What are the exact steps? Command by command, action by action. Not "revert the deployment" but the actual commands to run, the actual dashboards to watch, the actual confirmation to look for that says rollback is complete.
3. How long does it take? Time it in staging. Know your SLA for rollback. If rollback takes 45 minutes, you need to start it 45 minutes earlier than you might have otherwise.
4. Are there any data implications? If the new system wrote any data during its time live, does rolling back the code invalidate that data? Is there a cleanup step? Does the old code know how to handle data the new code wrote?
5. Who can authorize a rollback? The launch commander can authorize a rollback during the war room. But what about at 3am, when the launch is over and the war room has disbanded? Who has the authority and the knowledge to initiate a rollback at that point?

Common Failure Modes

There are five ways launches fail that are common enough to deserve explicit attention. Most of them are not technical failures. They are process failures — things that happen when the launch plan is incomplete or not followed.

1. The Checklist Nobody Actually Checked

The checklist exists. It lives in a document somewhere. On launch day, someone says "we went through the checklist" — but what they mean is "we looked at the checklist and assumed everything was probably fine." Nobody actually verified each item. Nobody had to say their name next to a completed item. The checklist was theater, not practice.

Fix: assign owners to checklist items. Each item must have a person whose name is on it, who has verified the item themselves, and who is accountable if that item turns out to have been unchecked. The go/no-go meeting is the moment where each owner says "I checked mine, it's good." No names, no launch.

2. The Rollback That Wasn't

The launch goes wrong and the team decides to roll back. They attempt to execute the rollback procedure. It doesn't work — because the procedure was written for a slightly different version of the system, or because a step was missed, or because a dependency that didn't exist when the procedure was written now exists. Now the team is improvising under pressure, making the situation worse.

Fix: test the rollback in staging, with the exact code that will be in production, at least once before the launch. Time it. Put a "rollback tested on [date]: yes/no" item on the checklist. If the rollback hasn't been tested, the launch doesn't go.

3. The Missing Monitoring

The launch completes successfully. Everything seems fine. Three hours later, a customer reports a critical bug. The team looks at their dashboards. The dashboards don't show the bug — because nobody set up a metric for the specific thing that broke. By the time the bug is found, it has affected thousands of users for hours.

Fix: before the launch, explicitly list the top five ways this launch can fail, and confirm that there is a metric and an alert for each one. "We would know within 10 minutes if [failure mode] happened" for each item on that list.

4. The Launch at 4pm on a Friday

The launch was supposed to happen on Thursday. It slipped. "We're basically ready" is the assessment. Someone says "let's just do it Friday afternoon, it'll be fine." The launch happens. A problem surfaces Friday at 6pm. The best engineers are all offline by 7pm. The problem festers over the weekend. By Monday, the blast radius has been two days instead of two hours.

Fix: this is a policy. No significant launches on Fridays or before holidays. Non-negotiable. The pressure to ship is always present; the policy is what prevents it from overriding judgment. If a launch slips past Thursday, it goes to the following Tuesday.

5. Launch and Abandon

The launch succeeds. The war room disbands. The team that built the feature disperses — some go on vacation, some move to the next project, some simply stop paying attention. The feature is in production but nobody is watching it. A slow failure starts developing — not an alarm-triggering spike, but a gradual drift in the wrong direction. It's discovered three weeks later by a user, not by engineering.

Fix: define the stabilization period before the launch. Assign an owner for that period. The owner is responsible for reviewing the slow signals every day until the period ends and the launch is declared stable. The end of the stabilization period is a declaration, not an assumption.

The Principle in One Sentence

Every launch decision you make under pressure in the war room was actually made before the launch — when you wrote the rollback procedure, when you tested the alerts, when you ran the go/no-go meeting. By launch day, you are not making decisions; you are executing decisions already made.