---
name: shipping-and-launch
description: Prepare and execute production launches with pre-launch checks, feature flags, staged rollout, monitoring, and a rollback plan. Use when deploying to production, planning a canary or beta, migrating data, or writing a rollback strategy. Not for hardening code against vulnerabilities: use security-and-hardening. Not for CI pipeline setup: use ci-cd-and-automation.
license: MIT
metadata:
  author: TechTide AI (Alex Cinovoj)
  provenance: rewritten from patterns in addyosmani/agent-skills (MIT)
  category: Delivery & Handoff
---

# Shipping and Launch

Every launch must be reversible, observable, and incremental. Deploying is easy; deploying with a rollback plan ready, monitoring in place, and a definition of success is the job.

## Pre-Launch Gate

Before any production deploy, clear the full checklist in references/pre-launch-checklist.md: code quality, security, performance, accessibility, infrastructure, and documentation. Run it as a gate, not a suggestion. Sections that do not apply get an explicit "N/A because", not silence.

## Decouple Deploy from Release: Feature Flags

Ship dark, release gradually:

1. Deploy with flag OFF. Code is live but inactive.
2. Enable for the team. Internal use in real production.
3. Gradual rollout: 5%, 25%, 50%, 100%.
4. Monitor at every stage.
5. Clean up: remove the flag and dead path within 2 weeks of full rollout.

Rules: every flag has an owner and an expiration date, flags never nest (combinations explode), and CI tests both flag states.

## Staged Rollout Sequence

1. **Staging:** full test suite plus manual smoke of critical flows.
2. **Production, flag off:** verify health check, watch error monitoring for anything new.
3. **Team enable:** 24-hour window.
4. **Canary at 5%:** compare canary vs baseline for 24-48 hours. Advance only on green thresholds.
5. **25%, 50%, 100%:** same monitoring each step, ability to drop back a step at any point.
6. **Full rollout:** monitor one week, then remove the flag.

### Advance / Hold / Roll Back Thresholds

| Metric | Advance | Hold and investigate | Roll back |
|--------|---------|----------------------|-----------|
| Error rate | Within 10% of baseline | 10-100% above | Above 2x baseline |
| P95 latency | Within 20% of baseline | 20-50% above | Above 50% |
| Client JS errors | No new error types | New errors under 0.1% of sessions | New errors above 0.1% |
| Business metrics | Neutral or positive | Decline under 5% | Decline over 5% |

Roll back immediately, without a meeting, on: error rate above 2x baseline, P95 up more than 50%, spiking user reports, data integrity issues, or a discovered security hole.

## Rollback Plan (written before deploy)

Every deploy carries this, filled in:

- **Triggers:** the specific thresholds above, plus feature-specific conditions.
- **Steps:** disable flag (under 1 minute), or revert and redeploy previous version (under 5 minutes), then verify health and error dashboards, then notify the team.
- **Database:** name the migration's rollback command and state whether new-feature data is preserved or cleaned up. A migration without a tested down-path is a one-way door; call it out.

## Monitor

Application: error rate (total and per endpoint), latency p50/p95/p99, request volume, key business metrics. Infrastructure: CPU, memory, connection pools, disk, queue depth. Client: Core Web Vitals, JS errors, API error rates as seen from the client. Wire an error boundary and server error reporting before launch, and return generic errors to users while logging details internally.

## Verification

Within the first hour after deploy:

- Hit the health endpoint. Expect 200. If not, roll back now, debug later.
- Open the error dashboard. Expect no new error types vs pre-deploy. A new error type means hold the rollout and investigate before advancing.
- Walk the critical user flow manually end to end. Expect it to complete. If it fails, roll back.
- Confirm logs are flowing and readable, and confirm the rollback mechanism works (flag toggle dry run where possible).

## Good vs Bad

**Bad:** "It passed staging, ship it to 100% Friday at 4pm, we'll add dashboards next sprint." No baseline, no canary, no one watching. The first monitoring signal is a customer email on Saturday.

**Good:** Deploy flag-off Tuesday morning, team enable for a day, canary at 5% with error and latency panels open, advance on green thresholds, full rollout Thursday, flag removed the week after.

## Footguns

- **Migrations without a down-path.** The code rolls back in minutes; the schema does not. Fix: write and test the rollback migration before deploy, or design the migration to be backward compatible with the previous release.
- **Zombie feature flags.** Months-old flags multiply untested code paths. Fix: owner plus expiration on creation, cleanup within 2 weeks of 100%.
- **Canary judged without a baseline.** "Errors look fine" means nothing without pre-deploy numbers. Fix: capture baseline error rate and P95 before enabling anything.
- **Rollback plan that only exists in someone's head.** Under incident pressure, memory fails. Fix: written triggers and steps attached to the deploy, rehearsed once.

## Red Flags: Stop the Deploy

- "It works in staging, it'll work in production."
- "We don't need a flag for this one."
- "Monitoring is overhead, we'll add it later."
- "Rolling back is admitting failure."
- "It's Friday afternoon, let's just ship it."

No change is small enough to skip the gate. If the pre-launch checklist, thresholds, and rollback plan feel like overkill, that is the signal you have stopped respecting production, not that production has become safe.

## Completion Checklist

- [ ] Pre-launch checklist cleared or items marked N/A with reason
- [ ] Feature flag configured with owner and expiration (or explicit reason none is needed)
- [ ] Rollback plan written, including database down-path
- [ ] Baseline metrics captured, dashboards ready, someone watching the first hour
- [ ] Post-deploy verification passed: health, errors, latency, critical flow, logs

Any box unchecked: not done. Fix or say so.