# Launch Risk Mitigation Playbook
**Sage, CSO · February 23, 2026**
**Scenario-based action plans for launch-day issues**

---

## Overview

This playbook covers the 5 highest-impact risks that could derail launch (Days 0-14) and provides clear decision trees + action sequences for each.

**Rule:** If a risk scenario happens, follow the playbook. Don't improvise. Report to Jason immediately.

---

## Risk #1: Meta App Review Rejected Again

**Likelihood:** 20-30% (already rejected once; resubmitted with improved screencasts)
**Impact:** CATASTROPHIC — Launch delay of 7-10 days minimum

### Decision Tree

#### If notification arrives before March 4 (>24 hours before planned launch)

**Action:**
1. **Stitch:** Immediately download rejection reason + video feedback from Meta Partners dashboard
2. **Stitch + Jason:** 30-minute call — analyze root cause
   - Same issue as v3? → Different fix needed
   - New issue? → Never seen before, requires investigation
3. **Jason:** Decide: Launch Solo-only today (Day 1), or postpone full launch?

**Scenario A: Launch Solo-only immediately (Recommended)**
- Rename Founding Member offer: "Founding Members lock Pro pricing ($49/mo) — auto-publishing launching next week"
- Deploy Solo-tier, send Email 1, begin user onboarding
- Message to early users: "Pro auto-publishing coming within 7 days. Reserved for Founding Members at $49/mo."
- Resubmit v4 to Meta within 24 hours with new screencast fixes

**Why:** You keep momentum. Early users onboard, validation begins. Pro features arrive as a surprise upgrade.

**Scenario B: Postpone full launch (Only if resubmit timeline unclear)**
- Delay email nurture sequence + organic marketing by 3-5 days
- Use time to record v5 screencasts, test comprehensively
- Resubmit same week (target: Wed or Fri submission)

#### If notification arrives on Day 1 morning (launch day)

**Action:**
1. **All hands:** Emergency 15-min call (Jason, Stitch, Charlotte, Sage)
2. **Stitch:** Pull rejection details immediately
3. **Jason:** Make call: Launch Solo or delay?

**Scenario A: Launch Solo-only immediately (90% likely)**
- Deploy Solo tier today
- Email 1 goes out with caveat: "Pro coming this week"
- Set expectation: Pro launch delay is Meta's approval process, not product readiness

**Scenario B: Delay launch by 2-3 days**
- Only if rejection reason is completely new and requires major screencast redesign
- Example: "You didn't show [obscure permission] in OAuth flow"
- Fix, resubmit, launch when approved

**Communication to market:**
- Email to waitlist: "Stylify launches tomorrow! Solo tier available now. Pro (auto-publishing) arriving this week."
- Honest, sets expectations, creates urgency for FM spots

#### Post-Rejection Action (If Rejected Again)

**Immediate (within 4 hours):**
1. Stitch records new screencasts (v5) addressing specific feedback
2. Charlotte prepares "Solo launch" marketing narrative
3. Jason reviews all Meta feedback — drafts updated submission

**Within 24 hours:**
1. Submit v5 to Meta
2. Continue Solo-tier operation (users onboarding, early validation happening)

**Target resubmission:** Within 7 days. If Meta approves v5, upgrade early users to Pro at no cost (goodwill gesture).

### Monitoring

- Meta Partners dashboard: Check daily for approval status
- Watch Meta Developers changelog for API changes during review process

---

## Risk #2: Kristi's Content Approval Delays Past Launch

**Likelihood:** 20% (depends on her review timeline; target: Feb 26)
**Impact:** HIGH — Can't send emails, can't launch Instagram, can't show landing page

### Decision Tree

#### If Kristi can't commit to EOD Feb 26

**Call her immediately (don't wait):**

**Ask:** "Which of these 9 items are highest priority? Let's focus on those first."

**Priority order (if she picks top 3):**
1. **Email 1** (most critical — entry point)
2. **Landing page** (second most critical — discovery page)
3. **Email 2-3** (warm-up sequence)

**Defer to post-launch (acceptable):**
- Lead magnet PDF (less critical than nurture email)
- Email 4-7 (later in sequence, can be approved as drafts)
- Instagram posts (can use placeholder content Week 1, finalize Week 2)

#### If Kristi approves top 3 but not remaining 6

**Action:**
1. **Launch with Email 1 + landing page + basic Instagram content**
2. **Charlotte:** Collect remaining 6 items from Kristi by March 3 (deploy them March 4-5)
3. **Charlotte:** Create "Approved Content Tracker" — Kristi signs off on batches, not all-at-once

#### If Kristi is unreachable/unavailable before launch

**Escalation:**
1. Jason: Call Kristi directly (founder authority is highest priority signal)
2. Ask: "Can you do a quick 15-min async review of Email 1 via voice note?" (Lower friction than detailed written feedback)
3. If still unavailable: Deploy with Email 1 as-is (it's expert-reviewed; Charlotte has sign-off from 6 copywriting specialists via Expert Panel)

**Rationale:** If 6 expert copywriters approved it and it went through Charlotte's review, you have coverage. Launch and get Kristi's feedback post-launch.

### Monitoring

- Weekly check-ins with Kristi (Charlotte, starting Feb 24)
- "Are we still on track for [deadline]?" — keeps pressure light but consistent
- Build in 2-day buffer (target Feb 26, launch wiggle room through Feb 28)

---

## Risk #3: High Support Volume in Week 1 (>15 tickets/day)

**Likelihood:** Medium (depends on onboarding clarity)
**Impact:** MEDIUM — Slow response times tank retention; early users feel neglected

### Decision Tree

#### If >10 support emails arrive on Day 1

**Action:**
1. **Charlotte:** Sort by category (onboarding / feature / bug / billing)
2. **Charlotte:** Respond to top 3 categories using pre-drafted templates (setup by Feb 27)
3. **Charlotte:** Drop summary in inbox: "[X tickets received, [Y] resolved, [Z] pending escalation]"

#### If >15 tickets/day by Day 3

**This is a signal:** Either onboarding is broken, or first users are power users (good problem).

**Action:**
1. **Charlotte:** Analyze ticket categories — find the pattern
   - 50% "How do I connect Instagram?" → Onboarding doesn't explain step
   - 50% "How do I schedule posts?" → Pro feature is confusing
2. **Jason:** Review the tickets directly — determine if product issue or communication issue
3. **Stitch:** If onboarding bug, fix same-day. Deploy hotfix.
4. **Charlotte:** If communication issue, update Help Center / in-app tooltips. No code change needed.

#### If Charlotte is drowning (>20 tickets, >2 hours/day)

**Escalation:**
1. **Jason:** Take 50% of support queue (emails + DMs)
2. **Charlotte:** Focus on pattern analysis + Help Center updates
3. **Decision point:** Do we need to hire a dedicated CS person now? (Usually no at this stage, but measure it)

**Fallback:** Use support request as feature feedback, not a crisis. Every question is data.

### Monitoring

- Support tracker spreadsheet (live daily update)
- Daily pattern report (Charlotte → inbox, 5 min summary)
- Response time target: <4 hours (non-urgent), <1 hour (bugs)

---

## Risk #4: Brand Vibe Update Breaks Existing User Data

**Likelihood:** Low (migrations are additive, backward-compatible)
**Impact:** HIGH — First users can't onboard, demo is broken, team loses credibility

### Decision Tree

#### Pre-Deployment (Day -1)

**Stitch:** Run comprehensive QA (see Launch Readiness Checklist)

1. Test old user archetype values still load in database
2. Test quiz flow with new + old vibes
3. Test caption generation with new archetype vectors
4. Spot-check 3 users: old archetype → generate caption → verify it works

#### If QA finds issues (new vibes break generation, old values fail to load)

**Action:**
1. **Do NOT deploy Day 0.** Delay deployment by 24 hours.
2. **Stitch:** Identify root cause — migration script, database schema, alias logic?
3. **Stitch:** Fix + re-test on staging database
4. **Deploy on Day 1-2** (acceptable 24-hour delay for data integrity)

#### If deployment happens and breaks (Users report "my voice is broken")

**Immediate (within 1 hour):**
1. **Stitch:** Rollback Brand Vibe deployment (revert to pre-launch code)
2. **Charlotte:** Email affected users: "We're fixing a voice archetype issue. Your captions will work normally in 30 minutes."
3. **Stitch:** Debug on staging database (identify the bug)

**Within 4 hours:**
1. Fix deployed, users re-test
2. Charlotte: Follow-up email with apology + explanation

**Root cause analysis (within 24 hours):**
- Was it the migration script?
- Was it a backward-compatibility alias that failed?
- Was it database inconsistency?

**Prevention:** Implement guard rails — if archetype value is invalid, default to "Balanced" instead of crashing.

### Monitoring

- First 10 user onboardings post-deployment — manually verify
- Sentry for any archetype-related errors
- Direct user feedback: "Does your voice sound right?"

---

## Risk #5: Low Founding Member Signups (<10 by Day 7)

**Likelihood:** Low-Medium (depends on messaging + personal outreach)
**Impact:** MEDIUM — No social proof, no testimonials, no validation signal

### Decision Tree

#### If only 5-10 FM signups by Day 5

**This is normal.** Don't panic. You're measuring FMs who've already signed up + paid.

#### If still <15 FM by Day 10 (late to see uptick)

**Action:**
1. **Jason:** Personal outreach — email/call top 20 early users directly
   - "Hi [name], loved your first post! We're looking for [100] Founding Members who want to lock in Pro pricing at $49/mo for life. Interested?"
   - Personal ask is 2-3x more effective than email copy
2. **Charlotte:** Review Email 1-3 open rates — are people opening emails?
   - If <30% open rate: email subject lines need work (Charlotte to fix)
   - If >30% but no conversions: CTA needs work (Charlotte to A/B test)
3. **Lux (via Charlotte):** Run Instagram story polls: "Would you use auto-scheduling?" (gauge Pro interest)

#### If <30 FM by Day 14 (significantly below target of 50)

**This is a signal:** Either positioning is off, or price is wrong.

**Action:**
1. **Jason:** Direct user interviews (5-10 users, 15-min calls)
   - "Why haven't you upgraded to Pro?"
   - Listen for: Price objection? Feature objection? Doesn't understand auto-publishing? Doesn't believe it works?
2. **Based on feedback:**
   - If price is barrier: Lower FM offer to $39/mo (trade margin for validation)
   - If they don't understand Pro: Improve onboarding explanation (visual demo, not text)
   - If they don't trust auto-publishing: Provide guarantees (manual fallback, safety)
3. **Course-correct messaging for Week 3**

#### If FM goal becomes unachievable (<20 by Day 14, trending to 50 total)

**Acceptable pivot:**
- Lock in 50-75 FMs instead of 100
- Lower target is fine; validated users are better than rushed numbers
- 50 real FMs > 100 fake FMs

### Monitoring

- Daily FM signups (Jason tracks this)
- FM trial-to-paid conversion rate (Charlotte tracks)
- FM cohort churn at Day 7, 14, 30

---

## Risk #6: API Deprecation/Breaking Change Discovered Pre-Launch

**Likelihood:** Low (Instagram API relatively stable)
**Impact:** MEDIUM-HIGH — Auto-publishing feature might not work correctly

### Decision Tree

#### If Stitch finds Instagram API deprecation during risk audit (before March 5)

**Action:**
1. **Stitch:** Assess severity — is it a blocker or a future concern?
   - **Blocker:** Feature we're launching breaks (e.g., "instagram_business_content_publish permission deprecated")
   - **Future concern:** Feature still works but will break in 6 months (e.g., "Graph API v16.0 sunset scheduled for Q4 2026")

#### If BLOCKER discovered pre-March 5

**Action:**
1. **Stitch:** Check Meta's workaround / alternative API endpoint
2. **If fix exists:** Deploy to production before launch (Day 0-1)
3. **If no fix exists:** Inform Jason immediately
   - This could push back launch by 1-2 weeks
   - Meta review might need to be resubmitted with different permission scope
   - Escalate to Jason + Meta support (file support ticket)

#### If FUTURE CONCERN discovered

**Action:**
1. **Log in DECISIONS.md:** "Instagram API v16.0 sunset Q4 2026 — plan migration by Q3"
2. **Add to roadmap:** Plan for API migration in Month 4-6
3. **No launch delay needed** — continue as planned

#### If deprecation discovered DURING launch (Day 1-7)

**Action:**
1. **Stitch:** Assess impact — does it break auto-publishing for all users, or just some?
2. **If breaks all:** Disable Pro auto-publishing temporarily, message Pro users: "Temporary issue with Instagram's API. We're working with Meta to fix. ETA 24 hours."
3. **If breaks some:** Identify the subset (e.g., "only affects carousel posts"), fix incrementally
4. **Stitch:** File support ticket with Meta + implement workaround simultaneously

**Communication:**
- Transparency > silence. Early users will understand API issues.
- "Meta changed their API. We found it within 6 hours and deployed a fix. Thanks for your patience."

### Monitoring

- **Charlotte:** Daily scan of Meta Developers changelog (5 min, before session start)
- **Stitch:** Automated alerts on Instagram API status page (set up if not already done)
- **Before launch:** Run API audit to flag any pending deprecations

---

## Risk #7: Supabase Free Tier Auto-Pauses During Launch

**Likelihood:** Low (keep-alive script running)
**Impact:** CATASTROPHIC — Database offline, all users locked out

### Decision Tree

#### Before March 5: Pro Upgrade Recommended

**Action:**
1. **Jason:** Upgrade Supabase to Pro ($25/mo) by March 1
2. **Benefit:** Removes keep-alive workaround, adds safety margin, improves reliability
3. **Timing:** Do it now, not on Day 1

#### If can't upgrade before March 5

**Action:**
1. **Stitch:** Verify keep-alive is running (check server logs for 4-hour pings)
2. **Stitch:** Remove keep-alive script Day 1 (if Pro upgrade is done) OR keep it running Day 1-14 (if free tier continues)

#### If database goes offline during launch (Day 0-7)

**Action:**
1. **Stitch:** Check Supabase dashboard — why did it pause?
   - Inactivity? → Reactivate + upgrade to Pro immediately
   - Quota exceeded? → Investigate usage + upgrade plan
2. **Charlotte:** Notify users (email + Twitter): "We're experiencing a temporary database issue. ETA 30 minutes."
3. **Stitch:** Upgrade to Pro while database is being restored
4. **Post-recovery:** Retrospective — what caused the pause? How do we prevent it?

### Monitoring

- Supabase dashboard: Check daily (Stitch)
- Monitor keep-alive in server logs: Is it pinging every 4 hours?
- Database connection errors in Sentry: Any timeout warnings?

---

## Decision Escalation Matrix

| Risk | Jason | Charlotte | Stitch | Sage |
|------|-------|-----------|--------|------|
| Meta rejection | **FINAL CALL** (launch solo vs. delay) | Supports decision | Implements | Assesses GTM impact |
| Content approval delay | **FINAL CALL** (launch with partial content?) | Escalates + prioritizes | — | — |
| High support volume | Escalates if Charlotte drowning | Executes + analyzes patterns | Fixes bugs | — |
| Brand Vibe breaks | — | — | **DECIDES** (rollback vs. fix forward) | — |
| Low FM signups | **PERSONAL OUTREACH** (drives FM asks) | Tracks + reports | — | Analyzes messaging |
| API deprecation | **DECIDES** (launch vs. delay for fix) | Communicates to users | **ROOT CAUSE** | Assesses risk |
| Supabase downtime | **DECIDES** (upgrade now vs. patch?) | Communicates to users | **EXECUTES** | — |

**Rule:** If unclear who owns decision, ask Sage. If still unclear, it goes to Jason.

---

## Post-Incident Playbook

After any risk scenario is triggered:

1. **Immediate (within 1 hour):** Fix the issue (Stitch), communicate to users (Charlotte), brief Jason
2. **Within 24 hours:** Root cause analysis (why did it happen?)
3. **Within 48 hours:** Prevention plan (how do we prevent it next time?)
4. **Log in DECISIONS.md:** Brief entry with date, cause, resolution, prevention
5. **Update this playbook:** If scenario is new or response was ineffective

---

## The Golden Rule

**When in doubt, communicate.**

Silent problems get worse. Transparent problems get fixed. Early users respect honesty about problems more than they respect silence about solutions.

Example phrases:
- "We found a bug. Here's what we did, when it's fixed."
- "This isn't working as intended. We're investigating."
- "Meta's API changed overnight. We're adapting."

Trust = honesty + speed. Not perfection.

---

*Sage, Chief Strategy Officer · Stylify*
*Prepared Feb 23, 2026 · Updated through Day 14 post-launch*