| name | launch-rollout-patterns |
| description | Phased rollout strategy, feature flag patterns, rollback trigger definition, and canary deployment criteria. Use when planning a product launch, designing a progressive rollout, or defining rollback thresholds. |
Launch Rollout Patterns
The safest launch is the one where nothing goes wrong at full scale because you caught the problem at 1% traffic. This skill covers the patterns for progressive rollout — from internal testing to full production — with clear success criteria and rollback triggers at each phase.
When to Use This Skill
- Planning a rollout for a new feature or product
- Designing feature flag targeting for progressive exposure
- Defining rollback triggers before launch (not during an incident)
- Planning a geographic or segment-based rollout
- Reviewing a launch plan for missing safeguards
Core Concepts
1. Never Big-Bang Launch
A big-bang launch (feature off → feature on for everyone simultaneously) removes your ability to:
- Attribute metric changes to the feature specifically
- Catch errors before they affect your entire user base
- Roll back without a full production incident
Every meaningful feature launch should be phased.
2. Define Rollback Triggers Before Launch
Rollback criteria decided during an incident are criteria decided under pressure. The question is not "should we roll back?" but "we already agreed we would roll back at this threshold — do we do it now?"
3. Success Thresholds, Not Just Error Thresholds
Define both what success looks like (proceed to next phase) AND what failure looks like (roll back). Without success thresholds, a rollout stays in limbo indefinitely.
Standard Rollout Phases
Phase 0: Internal Testing
Target: Internal team + selected employees
Duration: Until no critical bugs found
Proceed to Phase 1 when: Zero P0/P1 bugs in 48 hours
Phase 1: Alpha (Limited Beta)
Target: 1-5% of production traffic / invited users
Duration: 1-2 weeks minimum
Proceed to Phase 2 when: [defined success criteria]
Roll back when: [defined thresholds]
Phase 2: Expanded Beta
Target: 10-25% of traffic
Duration: 1-2 weeks
Proceed to Phase 3 when: [defined success criteria]
Roll back when: [defined thresholds]
Phase 3: Broad Rollout
Target: 50-75% of traffic
Duration: 1 week
Proceed to Phase 4 when: [defined success criteria]
Roll back when: [defined thresholds]
Phase 4: Full Rollout
Target: 100% of eligible users
Post-launch monitoring: 2 weeks active monitoring
Adjust phases based on feature risk level:
- Low risk (copy change, minor UI): Phase 0 → Phase 4 directly
- Medium risk (new UX, new flow): All phases, compressed timelines
- High risk (payment, auth, data model): All phases, extended timelines, extra monitoring
Rollback Trigger Definition
Template
## Rollback Triggers: [Feature Name]
### Automatic Rollback (no human decision required)
These conditions trigger immediate rollback without waiting for approval:
- Error rate on [endpoint] exceeds [X]% for 5+ consecutive minutes
- [Metric] drops below [threshold] in any 1-hour window
- [P1 or higher bug] confirmed in production
### Manual Rollback (human decision required within 30 minutes)
These conditions trigger a team review and rollback decision:
- Conversion rate on [flow] drops > [X]pp from baseline
- Support ticket volume increases > [X]% vs. same period previous week
- NPS score drops > [X] points within 48 hours of rollout expansion
### Rollback Procedure
1. Disable feature flag for current cohort
2. Confirm metric recovery within 15 minutes
3. File incident report
4. Notify stakeholders
5. Root cause analysis before re-launch
Threshold Setting Guidelines
| Metric | Conservative Threshold | Aggressive Threshold |
|---|
| Error rate increase | > 1x baseline | > 3x baseline |
| Core conversion drop | > 2pp | > 5pp |
| Revenue impact | > 1% decrease | > 5% decrease |
| Support volume increase | > 20% | > 100% |
| Page load time increase | > 500ms P95 | > 1s P95 |
Use conservative thresholds for payment flows, auth, and data operations. Use aggressive thresholds for low-risk UI changes.
Feature Flag Patterns
Targeting Strategies
| Strategy | Use When | Implementation |
|---|
| Percentage rollout | Random exposure for A/B testing | Hash user ID to [0-100], enable for users < threshold |
| Cohort targeting | Target specific segments (new users, power users) | Match on user attribute |
| Geographic targeting | Phase by region (primary market → secondary) | Match on user location |
| Beta opt-in | Engaged users who want early access | Match on beta flag in user profile |
| Employee-first | Internal validation before external exposure | Match on internal user flag |
Feature Flag States
OFF: Feature completely disabled for all users
SHADOW: Feature executes but output is not shown (backend validation)
BETA: Feature visible to targeted cohort only
PARTIAL: Feature live for [X]% of traffic
FULL: Feature live for all eligible users
SUNSET: Feature disabled pending removal (post-deprecation)
Flag Naming Convention
feature.[product-area].[feature-name].[variant]
Examples:
feature.checkout.guest-checkout.enabled
feature.listings.bulk-upload.rollout-pct
feature.payments.split-payment.beta
Geographic Rollout Sequencing
For products with multi-market presence:
Tier 1: Primary market (highest traffic, most test data)
Launch here first. Most bugs found with the most signal.
Tier 2: Similar markets (comparable infrastructure, similar user behavior)
Launch after Tier 1 is stable for [X] days.
Tier 3: Adjacent markets (different language, different infrastructure needs)
Requires localization validation in addition to functional testing.
Tier 4: Emerging markets (lower bandwidth, different device distribution)
Requires performance validation under constrained conditions.
Launch Communication Plan
Internal Communication
| Audience | Message | Timing |
|---|
| Engineering | Technical details, rollback procedure, on-call escalation path | 48 hours before Phase 1 |
| Support | Feature summary, expected user questions, escalation path | 24 hours before each phase expansion |
| Leadership | Feature summary, launch plan, success metrics | 1 week before Phase 1 |
| All company | Feature announcement and availability | Phase 4 launch day |
User Communication
- Phase 0–2: No external communication (internal / invited users only)
- Phase 3: Soft announcement to beta users
- Phase 4: Full release notes, in-app announcement (if warranted), external PR (if warranted)
Post-Launch Monitoring Checklist
First 24 hours after each phase expansion:
Best Practices
- Write rollback triggers before the launch plan is approved — not after
- Run shadow mode for high-risk features — execute the logic, don't show the results; validate the backend before the UI
- Instrument before Phase 1 — if tracking isn't in place for Phase 1, you're flying blind
- Set an expiry for feature flags — flags that live forever become technical debt; schedule removal when full rollout is confirmed
- Socialize the rollback plan — the engineering on-call must know the rollback procedure before launch day
