Ready to supercharge your AI agents?

Install any skill in seconds. Free to start, no credit card required.

SaaS Launch Checklist · vibeeval | DecimalAI

Saas Launch Checklist

SkillScore50Maintained

saas-launch-checklist

Pre-launch verification across infrastructure, security, legal, payment, email, analytics, and performance. Day-1 monitoring, rollback plan, incident response skeleton, and post-launch week-1 checklist.

DevOpsby vibeeval

Links this skill to your agents and keeps it current with the author’s updates.

Automatic

DevOps & SRE pack

1 · One-time — install the CLI (docs ↗)

pip install decimalai

2 · Get the skill — writes .claude/skills/saas-launch-checklist/SKILL.md

decimalai skills pull saas-launch-checklist --out .claude/skills/

No CLI? Get the same file — curl · raw file

curl -fsSL --create-dirs -o .claude/skills/saas-launch-checklist/SKILL.md https://app.decimal.ai/s/saas-launch-checklist/SKILL.md

Raw file: /s/saas-launch-checklist/SKILL.md ↗ · machine-readable summary at /s/saas-launch-checklist.json ↗

In productionGlobal

how this skill behaves on real traffic · last 30 days

No production data for this skill yet — usage numbers appear here once agents start running it.

Anonymized aggregate across every org using this skill — proof from real production use, not a demo.

Does this skill help? · Benchmark: with vs. withoutsign in to run this on your agents

24 test cases from the publisher’s eval.yaml · each run twice on gemini-3.6-flash — with the skill injected, then without · last run 56d ago

Yes — +42% lift · at higher cost+142% tokens0% turns50% of whole cases pass with skill (12/24)

Test case	Without → With	Effect	Δ tokens	Δ turns
case-05	✗→✓	▲ Improved	—	—
case-03	✗→✓	▲ Improved	—	—
case-13	✗→✓	▲ Improved	—	—
case-19	✗→✓	▲ Improved	—	—
case-10	✗→✓	▲ Improved	—	—

Showing 5 of 24 cases

SkillSafety

✓ 3 of 3 passed

Code scan15 of 15 checks clean

0 critical · 0 warning · 0 info — scanner v4 — 7/30/2026

live_secretremote_code_executionreverse_shelldata_exfiltrationssrf_metadataagent_snoopinganti_refusaldestructive_commandsobfuscated_unicodeunicode_homoglyphopaque_blobsuspicious_urltool_overreachtrigger_abuseprompt_injection_phrasing

IntentSafe

LLM judge · does the skill do what it claims

ContentClean

LLM judge · policy & harmful-content review

Source

Imported

vibeeval / vibecosystem

skills/saas-launch-checklist/SKILL.md

View on GitHub ↗

License MITImported 8/1/2026Version v1

Skill contents

SKILL.md

SaaS Launch Checklist

A structured checklist for shipping a SaaS product to production with confidence. Every item exists because someone skipped it and regretted it.

Pre-Launch Checklist (28 Items)

Infrastructure (5 items)

] SSL/TLS -- Certificate installed, auto-renewal configured (Let's Encrypt / ACM), HSTS header present
] CDN -- Static assets served through CDN, cache-control headers set, origin shielding enabled
] Backup -- Database backup scheduled (daily minimum), tested restore procedure, off-site copy
] Monitoring -- Health check endpoint returns 200 when healthy and 503 when degraded, uptime monitor pings every 60s
] Alerting -- PagerDuty/Opsgenie configured, on-call rotation set, escalation policy defined (5 min ack SLA)

Security (5 items)

] Penetration test -- Run OWASP ZAP or equivalent against staging, fix all HIGH/CRITICAL findings
] Dependency audit -- npm audit / pip-audit / trivy shows zero critical CVEs
] Secret rotation -- All production secrets differ from staging, rotation schedule documented
] Rate limiting -- API endpoints rate-limited (e.g., 100 req/min per user), auth endpoints stricter (10 req/min)
] Headers -- CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy all configured

Legal (4 items)

] Terms of Service -- Reviewed by legal counsel, published at /terms, acceptance recorded at signup
] Privacy Policy -- GDPR/CCPA compliant, published at /privacy, covers data collection, retention, and third parties
] Cookie consent -- Banner shown to EU visitors, non-essential cookies blocked until consent, preferences stored
] DPA (Data Processing Agreement) -- Template available for enterprise customers, sub-processor list published

Payment (4 items)

] Test transactions -- Full purchase flow tested with test cards (success, decline, 3DS), subscription upgrade/downgrade verified
] Webhook verification -- Stripe/Paddle webhook signature verified, replay attacks prevented with idempotency keys
] Invoice generation -- Invoices auto-generated with correct tax info, downloadable as PDF, emailed on payment
] Dunning flow -- Failed payment retry schedule configured (day 1, 3, 5, 7), grace period before cancellation

Email (4 items)

] SPF/DKIM/DMARC -- DNS records configured, DMARC policy set to quarantine or reject, verified with mail-tester.com
] Transactional templates -- Welcome, password reset, invoice, and trial expiry emails tested across Gmail/Outlook/Apple Mail
] Unsubscribe -- One-click unsubscribe header present (RFC 8058), /unsubscribe endpoint works, preference center available
] Sender reputation -- Dedicated IP warmed up (if >10k emails/day), bounce handling configured, complaint feedback loop active

Analytics (3 items)

] Core events -- Signup, activation, purchase, and churn events tracked with user ID and properties
] Funnels -- Signup-to-activation and trial-to-paid funnels configured in analytics dashboard
] Dashboards -- Real-time dashboard shows active users, revenue (MRR), error rate, and response time

Performance (3 items)

] Load test -- k6/Artillery run at 2x expected peak traffic, p95 latency under 500ms, zero errors
] CDN cache -- Cache hit ratio above 90% for static assets, proper Cache-Control and ETag headers
] Image optimization -- All images served as WebP/AVIF with responsive srcset, lazy loading below the fold

Day-1 Monitoring Dashboard

Build this dashboard before launch. Every panel answers a specific question.

+-----------------------------------------------------+
|                  SaaS Launch Dashboard               |
+---------------------------+-------------------------+
| Request Rate (req/s)      | Error Rate (%)          |
| Normal: 10-50/s           | Target: < 1%            |
| Alert: > 200/s            | Alert: > 2%             |
+---------------------------+-------------------------+
| p95 Latency (ms)          | Active Users (real-time) |
| Target: < 200ms           | Shows WebSocket/polling  |
| Alert: > 500ms            | count                    |
+---------------------------+-------------------------+
| Signup Rate (/hr)         | Payment Success Rate (%) |
| Compare to projection     | Target: > 95%            |
| Alert: 0 for 30min        | Alert: < 90%             |
+---------------------------+-------------------------+
| CPU / Memory              | Database Connections      |
| Alert: > 80%              | Alert: > 80% pool        |
+---------------------------+-------------------------+

Dashboard as Code (Prometheus Queries)

yaml
# monitoring/launch-dashboard.yml
panels:
  - title: Request Rate
    query: sum(rate(http_requests_total[5m]))
    alert_threshold: 200

  - title: Error Rate
    query: |
      sum(rate(http_requests_total{status_code=~"5.."}[5m]))
      / sum(rate(http_requests_total[5m])) * 100
    alert_threshold: 2

  - title: p95 Latency
    query: |
      histogram_quantile(0.95,
        sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
    alert_threshold: 0.5

  - title: Signup Rate
    query: sum(increase(user_signups_total[1h]))
    alert_threshold: 0  # alert if zero for 30 min

  - title: Payment Success Rate
    query: |
      sum(rate(payment_completed_total[5m]))
      / sum(rate(payment_attempted_total[5m])) * 100
    alert_threshold: 90  # alert if below

Rollback Plan Template

Complete this before you deploy. If you cannot fill every field, you are not ready to launch.

markdown
# Rollback Plan: [Product Name] v[X.Y.Z]

## Decision Criteria
Trigger rollback if ANY of these occur within 60 minutes of deploy:
- [ ] Error rate exceeds 5%
- [ ] p95 latency exceeds 2 seconds for 5 consecutive minutes
- [ ] Payment processing fails for 3+ consecutive attempts
- [ ] Data integrity issue detected (mismatched records)

## Rollback Steps
1. Set feature flag `launch_v1` to OFF (immediate, <30 seconds)
2. Revert DNS/load balancer to previous deployment
3. Run: `kubectl rollout undo deployment/api --to-revision=PREV`
   OR: `docker compose -f docker-compose.prod.yml up -d --force-recreate`
4. Verify health check returns 200 on previous version
5. Notify #incidents channel: "Rollback executed, investigating"

## Data Migration Rollback
- [ ] Database migration has a DOWN migration
- [ ] Tested: `npm run migrate:down` or `python manage.py migrate APP PREVIOUS`
- [ ] New columns are NULLABLE (old code ignores them)
- [ ] No destructive changes (column drops, renames) in this release

## Communication
- Engineering: #incidents Slack channel
- Support: Pre-drafted message in support tool
- Customers: Status page update (only if downtime > 5 min)

## Owner
- Rollback decision: [On-call engineer name]
- Execution: [DevOps engineer name]
- Communication: [Support lead name]

Incident Response Playbook Skeleton

markdown
# Launch Day Incident Playbook

## Severity Levels
| Level | Definition                  | Response  | Example                    |
|-------|-----------------------------|-----------|----------------------------|
| SEV-1 | Service down, data loss     | 5 min     | Database unreachable       |
| SEV-2 | Major feature broken        | 15 min    | Payments failing           |
| SEV-3 | Minor feature broken        | 1 hour    | Email delivery delayed     |
| SEV-4 | Cosmetic issue              | Next day  | Alignment bug on Safari    |

## On-Call Roster (Launch Day)
| Role               | Primary        | Secondary      | Contact        |
|--------------------|----------------|----------------|----------------|
| Incident Commander | [Name]         | [Name]         | [Phone/Slack]  |
| Backend Engineer   | [Name]         | [Name]         | [Phone/Slack]  |
| Frontend Engineer  | [Name]         | [Name]         | [Phone/Slack]  |
| DevOps/SRE         | [Name]         | [Name]         | [Phone/Slack]  |

## Response Flow
1. DETECT  - Alert fires or user reports issue
2. TRIAGE  - Assign severity, open incident channel (#inc-YYYYMMDD-NN)
3. CONTAIN - Feature flag OFF, rollback, or scale up
4. FIX     - Root cause fix, deploy to staging, verify
5. DEPLOY  - Push fix to production with monitoring
6. REVIEW  - Post-incident review within 48 hours

## Pre-Written Status Page Messages
- Investigating: "We are aware of an issue affecting [X] and are investigating."
- Identified: "The issue has been identified. A fix is being deployed."
- Resolved: "The issue has been resolved. All systems are operational."

Post-Launch: First 7 Days Checklist

Day 1 (Launch Day)

] All-hands monitoring: dashboard on a shared screen or TV
] Respond to every support ticket within 2 hours
] Track signup funnel: landing page visits -> signups -> activation
] Check error logs every hour for new error patterns
] Verify email deliverability (check spam folders with seed accounts)

Day 2-3

] Review Day 1 analytics: signup count, activation rate, bounce rate
] Fix any P1/P2 bugs discovered by real users
] Check payment reconciliation: Stripe dashboard matches your records
] Send first-day cohort a "how's it going?" email (personal, from founder)
] Monitor server costs: actual vs projected infrastructure spend

Day 4-5

] Analyze user behavior: where do users drop off? Heatmaps, session recordings
] Run second load test if traffic patterns differ from projections
] Review and tune alerting thresholds (reduce noise, catch real issues)
] Check SEO: is Google indexing your pages? robots.txt correct?
] Backlog grooming: prioritize bugs and feature requests from real users

Day 6-7

] Week 1 retrospective: what worked, what did not, what to change
] Publish week 1 metrics: signups, activation, retention, revenue
] Plan week 2 priorities based on actual user data (not assumptions)
] Thank early adopters (personal email, discount, or swag)
] Remove launch-specific feature flags and temporary monitoring

Contrast: Phased Rollout vs Big Bang Launch

BAD: Big Bang Launch

Monday 9:00 AM:
  - Mass email to 50,000 person waitlist
  - ProductHunt launch post goes live
  - Hacker News submission
  - All social media posts scheduled simultaneously
  - Full feature set available to everyone

Monday 9:15 AM:
  - 3,000 concurrent users hit the app
  - Database connections exhausted
  - Payment webhook queue backs up
  - Support inbox: 200 tickets in 30 minutes
  - Error rate: 15%
  - Team panics

Monday 10:00 AM:
  - Emergency rollback
  - Status page: "We are experiencing issues"
  - ProductHunt comments: "This doesn't work"
  - First impression destroyed

GOOD: Phased Rollout

typescript
// Feature flag configuration for phased rollout
const LAUNCH_PHASES = {
  phase1: {
    name: 'Team and Friends',
    startDate: '2025-01-06',
    criteria: { userList: 'internal-testers' },  // 50 users
    goal: 'Find critical bugs before anyone else sees them',
  },
  phase2: {
    name: 'Beta Waitlist (10%)',
    startDate: '2025-01-08',
    criteria: { percentage: 10 },                 // 500 users
    goal: 'Validate onboarding flow and payment',
  },
  phase3: {
    name: 'Beta Waitlist (50%)',
    startDate: '2025-01-10',
    criteria: { percentage: 50 },                 // 2,500 users
    goal: 'Load test with real traffic patterns',
  },
  phase4: {
    name: 'Full Waitlist + Public',
    startDate: '2025-01-13',
    criteria: { percentage: 100 },                // everyone
    goal: 'General availability',
  },
} as const

Week 1 Monday:    50 internal users     -> Find showstoppers
Week 1 Wednesday: 500 beta users        -> Validate payment flow
Week 1 Friday:    2,500 beta users      -> Verify infrastructure holds
Week 2 Monday:    Full public launch    -> Confidence backed by data

Each phase gate:
  [x] Error rate < 1%
  [x] p95 latency < 300ms
  [x] Payment success > 98%
  [x] NPS from phase users > 30
  [x] Zero data integrity issues
  -> Only then proceed to next phase

Why Phased Rollout Wins

| Dimension | Big Bang | Phased Rollout | |-------------------|------------------------|--------------------------| | Risk | All-or-nothing | Contained per phase | | Feedback | Overwhelming, chaotic | Manageable, actionable | | Infrastructure | Guess and hope | Scale based on real data | | Recovery | Public failure | Private fix | | First impression | One shot | Refined over 4 attempts | | Team stress | Maximum | Distributed |

Key principle: Launch is not a single moment -- it is a process. Every item you skip is a bet that nothing will go wrong in that area. The checklist exists to make the boring stuff automatic so you can focus on users.

Illustrative Want to see what saas-launch-checklist would put in front of your model? Preview the rendered body and check its trigger phrases — no LLM call, no signup.

Latest benchmark · publisher runVerified

7/29/2026, 01:50 UTC · 24 cases

Lift

+42%

50% vs 8%

Agent turns

1.0 vs 1.0

Tokens

+142%

6,347.13 vs 2,620.92

fail → pass · 10pass → pass · 2fail → fail · 12

Per-case results (24)

Case	Status	Duration (ms)			Turns			Tokens			Tool calls
Case	Status	Without	With	Δ	Without	With	Δ	Without	With	Δ	Without	With	Δ
case-05 We are setting up API rate limiting for our web application endpoints before opening to public traffic. We plan to apply a uniform rate limit of 500 requests per minute across all endpoints, including login and authentication routes. What rate limits should be established for standard API versus authentication endpoints?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-07 We are designing our SaaS subscription billing and payment failure recovery flow in Stripe. Our team proposed retrying failed payments daily for 30 consecutive days before canceling the account. What failed payment retry schedule and grace period should be configured?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-06 We are preparing our SaaS platform legal and compliance requirements for launching in North America and Europe. We plan to load all marketing tracking cookies immediately when a user visits from the EU and show a passive banner notice. How should user cookie tracking and consent be handled for EU visitors?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-03 We are launching our new platform shortly and want to ensure proper observability and post-release management. Could you provide a guide for setting up our launch monitoring dashboard metrics alongside a day-by-day task checklist for the first week after going live?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-13 We just completed Day 1 of our SaaS product launch. Our team is deciding what operational checks to run during Days 2 and 3 post-launch. Should we start building new major feature requests immediately?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-19 We are defining payment failure thresholds for triggering an automatic launch rollback. Our team suggests waiting until 50 payment failures accumulate over 24 hours. What consecutive payment failure threshold triggers an immediate rollback?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-09 We are optimizing our SaaS front-end performance and static asset delivery before launch. Our team plans to test performance at 1x peak traffic and targets an 80% CDN cache hit ratio. What load test parameters and cache hit ratio targets should we enforce?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-14 We are entering Days 4 and 5 of our SaaS release. We want to organize our engineering focus during this mid-week post-launch phase. What specific infrastructure and analytics tasks should be conducted?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-10 We are drafting Prometheus PromQL queries for our launch day Grafana dashboard to track application latency. We plan to calculate the p50 median response time over a 15-minute window. What metric quantile and calculation window should be used for latency monitoring?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-16 We are completing security checks before our application launch. We plan to run npm audit and ignore high severity vulnerabilities if they are in devDependencies, and skip staging penetration testing. What vulnerability findings and audit thresholds must be resolved prior to release?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-11 We are building an incident response playbook skeleton for our SaaS launch. For a SEV-1 issue like total database outage or service unavailability, our team proposes a 30-minute initial response SLA. What response SLA and definition should be assigned to SEV-1 incidents?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-24 We are designing our SaaS landing page hero section in Tailwind CSS. Can you provide the HTML and Tailwind CSS classes for a responsive hero section with a headline, call-to-action button, and hero image?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-15 We are choosing between sending a mass broadcast launch email to our 50,000 waitlist subscribers on Monday morning vs executing a phased rollout strategy. How should user access be structured during a phased launch sequence?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-01 We are preparing to push our web application to production next week. Can you provide a comprehensive pre-launch checklist organized by key operational domains like infrastructure, security, billing, and compliance so our team can verify our deployment readiness?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-08 We are finalizing our SaaS transactional email configuration for user signups and billing. We set our DMARC policy to 'none' and added a standard link at the bottom of marketing emails. What DMARC policy and unsubscribe standards should be implemented for launch readiness?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-22 We need to write an AWS Terraform script to provision an ECS Fargate cluster with an Application Load Balancer and RDS PostgreSQL instance. Can you provide the Terraform HCL code modules for this infrastructure?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-18 We are setting up our launch day incident response team roster. We only assigned an Incident Commander to handle everything during an outage. What dedicated technical roles should be assigned on the launch day on-call roster?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-21 We are wrapping up the first week after launching our SaaS application. What specific retrospective and cleanup actions should be completed on Days 6 and 7?	pass→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-12 When executing an emergency production rollback after a bad release, our team plans to recompile and re-deploy the previous Git commit first. What should be the immediate step 1 taken to halt new feature code execution within 30 seconds?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-02 I need a standard rollback plan template for our upcoming software release. Please outline the required structure, including decision criteria for triggering a revert, technical reversion steps (with database safety guidelines), and communication ownership roles.	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-04 We are configuring our SaaS infrastructure health checks and alerting escalation policy prior to production launch. We plan to set our monitoring uptime ping to 5 minutes and allow up to 30 minutes for incident acknowledgement. What operational parameters should we configure for production monitoring and alerting readiness?	fail→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-17 We are setting up event tracking in Mixpanel before our SaaS launch. We plan to log page views anonymously without tying user identity across sessions. What core product events and identifiers should be tracked?	pass→pass	—	—	—	—	—	—	—	—	—	—	—	—
case-20 We plan to send 50,000 marketing and transactional emails per day immediately upon SaaS launch from a brand-new IP address without any warm-up period. What sender reputation step is required for high-volume email delivery?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—
case-23 We are setting up GitHub Actions to build Docker images and push them to Amazon ECR on every push to main. Can you write the YAML workflow file for this CI pipeline?	fail→fail	—	—	—	—	—	—	—	—	—	—	—	—

These cases were also screened by the skill’s intent / safety pass.See the Trust review ↗Reproduce this benchmark in Colab ↗

How this skill was measured

DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 24 cases were attempted. The headline lift of +42 percentage points is the difference between those two pass rates over the 24 comparable cases.

Model measured: gemini-3.6-flash
Graded by: gemini-3.6-flash
Grading method: judged
Verification: verified
Pass rate without the skill: 8.3%
Pass rate with the skill: 50%
Cases attempted: 24
Cases counted toward lift: 24
Cases that regressed: 0
Skill version measured: v1
Run completed: 7/29/2026, 01:50 UTC

The per-case answers from this run were removed by the retention sweep, so the case table below shows the verdicts without the text either arm produced. The counts above were recorded at the time and are unaffected. Answers are now kept for 180 days.

SkillScore blends 4 signals1 of 4 complete

BenchmarkPass rate WITH skill on a verified run50

Live evalNeeds ≥10 evaluated traces in 30 days

AI ratingNeeds ≥10 rated traces

AdoptionNeeds ≥10 serves across ≥2 orgs in 30 days

Efficiency · separate axis (at equal correctness)+0% turns+151% tokens

Shown for transparency; not credited unless a verified run shows no correctness regression.

Backed by 1 of 4 signals — each added signal makes the score more robust.

Verified on gemini-3.6-flash · re-tested 55 days ago

Other measured skills in the registry, with their headline benchmark lift.