Run any Skill in Manus with one click

mvp-launch

Stars465

Forks52

UpdatedJanuary 9, 2026 at 22:14

Web app MVP launch checklist knowledge. Auto-triggered when conversation involves "launch readiness", "MVP checklist", "production ready", "go live", or pre-launch verification. Provides the 10-point criteria for what counts as "done" in each area. Based on "Realistic MVP Launch Checklist (from building 30+ apps)".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ooiyeefei

ooiyeefei/ccc

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

name	mvp-launch
description	Web app MVP launch checklist knowledge. Auto-triggered when conversation involves "launch readiness", "MVP checklist", "production ready", "go live", or pre-launch verification. Provides the 10-point criteria for what counts as "done" in each area. Based on "Realistic MVP Launch Checklist (from building 30+ apps)".

MVP Launch Checklist

A battle-tested 10-point checklist for web app MVP launches. Based on building 30+ apps.

Philosophy: "Don't overbuild. Just make it stable, usable, and something people can trust."

The 10-Point Checklist

1. Stripe Setup (Payment Infrastructure)

What counts as DONE:

Trials configured with appropriate period
Plan switching works (upgrade/downgrade)
Failed payment handling with retry logic
Webhook endpoint registered in Stripe Dashboard
Live keys tested (not just test mode)

Required Webhook Events:

customer.subscription.trial_will_end
customer.subscription.created
customer.subscription.updated
customer.subscription.deleted
invoice.payment_succeeded
invoice.payment_failed
invoice.created
checkout.session.completed

Verification: See references/stripe-testing.md

2. Mobile-First Design

What counts as DONE:

Tested on real phones (not just browser resize)
Touch targets appropriately sized (44x44px minimum)
Forms work on mobile keyboards
No horizontal scroll on mobile

Key insight: Browser resize mode lies. Real device testing is mandatory.

Bonus (not required):

PWA manifest for installability
Offline capability for core features

3. Smooth Onboarding

What counts as DONE:

Steps kept minimal (3-5 max)
Users guided to a fast first win
Progress indicator if multi-step
Can be skipped/completed later

Anti-pattern: Don't require 10 fields before users see value.

4. AI & Automation Stability

What counts as DONE:

API errors handled gracefully
Retry logic with exponential backoff
Edge cases don't crash the app
Timeouts configured appropriately
Fallback behavior when AI fails

Good defaults:

3 retry attempts
30-60s timeout for complex operations
User-friendly error messages

5. Critical Emails

What counts as DONE:

Welcome email (immediate after signup)
Trial-ending email (before trial expires)
Failed payment email (when charge fails)
Password reset (if not using external auth)

Nice to have (don't overbuild):

Support acknowledgment email
Usage milestone emails

6. Error Logging

What counts as DONE:

Error tracking service configured (Sentry, Bugsnag, etc.)
PII scrubbed from logs
Critical errors trigger alerts
Enough context to debug issues

Goal: Catch bugs before users notice them.

7. User Feedback Loop

What counts as DONE:

Simple form or tool to collect feedback
Screenshots/context capture (optional but helpful)
Feedback reaches the team (email, Slack, GitHub Issues)

Examples: Typeform, in-app widget, email link, GitHub Issues integration.

8. Authentication & Roles

What counts as DONE:

Secure page protection (no unauthorized access)
Password reset works (or external auth handles it)
Basic roles defined (admin vs user minimum)
Session management (logout, expiry)

If using external auth (Clerk, Auth0): Most of this is handled for you.

9. Custom Domain with SSL

What counts as DONE:

Own domain configured (no .vercel.app, .replit.app)
HTTPS enabled (auto or manual SSL)
DNS properly configured

Why it matters: Trust. Users won't pay for myapp.replit.app.

10. Real Database & Backups

What counts as DONE:

Production database (not dev/local DB)
Automated backups configured
Point-in-time recovery possible

Good choices: Supabase, Neon, PlanetScale, Convex, AWS RDS.

Anti-pattern: Replit DB, SQLite in production, no backups.

Scoring

Score	Meaning
10/10	Fully implemented, production-ready
7-9/10	Mostly complete, minor gaps
4-6/10	Partial implementation, needs work
1-3/10	Minimal/broken implementation
0/10	Not implemented

Overall (sum of 10 areas):

85-100: Launch Ready
70-84: Nearly Ready
50-69: Needs Work
<50: Not Ready

References

references/search-patterns.md - Grep patterns for discovery
references/stripe-testing.md - Stripe CLI verification commands

More from this repository

same repository

project-showcase

ooiyeefei/ccc

Add a filterable, project-based showcase catalog to a personal or company site — the pattern where every project is one card that opens a detail page, and visitors filter by the KIND of project (a launched product vs a hackathon build vs an R&D experiment). Use when someone wants to build a portfolio / projects / "things I've built" page, a showcase grid with filters, or wants to add one new project to an existing showcase and isn't sure how to categorize or present it. Interviews you about your stack and what you already have before writing anything.

2026-07-12465

google-analytics-setup

ooiyeefei/ccc

Set up Google Analytics 4 (GA4) on a website and wire a real conversion event (form submit, signup, purchase) end to end. Guides the user through account/property/data-stream creation, installing the gtag.js tag, firing a conversion event, marking it as a Key Event, and verifying it in DebugView BEFORE spending on ads. Use whenever someone wants to add GA4, "install Google Analytics", track a form submission or signup, set up conversion tracking, find their Measurement ID (G-XXXXXXXXXX), debug why GA4 events aren't showing, or decide how many GA4 properties/streams they need. Meets the user wherever they are — always asks what they've already set up first.

2026-07-10465

meta-pixel-setup

ooiyeefei/ccc

Set up the Meta Pixel (Facebook/Instagram ads tracking) on a website and fire a conversion event (Lead, CompleteRegistration, Purchase) end to end. Guides the user through Business Suite / Events Manager, creating or finding the Pixel/Dataset ID, installing the base code, firing a standard event, and verifying it with the Meta Pixel Helper BEFORE running ads. Use whenever someone wants to add the Meta/Facebook Pixel, track FB/IG ad conversions, install "the pixel", find their Pixel/Dataset ID, set up a Lead or Purchase event for Meta ads, debug why Pixel events aren't firing, or is being pushed by Meta's wizard toward the Conversions API and isn't sure if they need it. Meets the user wherever they are — always asks what they've already set up (Facebook Page? Business Suite? a Pixel ID?) first.

2026-07-10465

htmldrop

ooiyeefei/ccc

Reach for this skill when an HTML artifact — report, deck, brief, mockup, dashboard, proposal, spec, or landing page, whether the user already has it or you just generated it — needs to reach other people or get tightened before it ships. Three situations: (1) they want a shareable link — public, or password-protected so only a client or specific people can open it; (2) they want reviewers to comment/annotate on it, then pull that feedback back to answer, fold, or synthesize into a revised version; (3) they want to co-edit it with you live and locally first — pointing at sections and commenting while you edit in real time, nothing deployed — to polish before sending. Cues: share, publish, get a link, password-protect, send to the client, collect or incorporate feedback, review it together, iterate in edit mode. Not for deploying apps/frameworks (Vercel, Next.js, npm), CSS/layout debugging, PDF annotation, A/B testing, or emailing screenshots.

2026-07-06465

cross-app-shared-auth

ooiyeefei/ccc

Blueprint for wiring many apps to one shared login plus a central accounts database, so a person has a single account across every app and access to each app accrues per app (opt-in, deny-by-default). Use this whenever onboarding a new app into a shared-auth family, setting up cross-subdomain SSO, building a central entitlement or "app access" database, adding per-app access gating, or when the user mentions one login for many products, shared accounts across apps, subdomain SSO, a central accounts service, app entitlements, or letting people sign up from any app OR a landing page and have it register centrally. Trigger even if the user does not say "shared auth" but describes a portfolio or family of apps that should share identity.

2026-07-03465

uat-testing

ooiyeefei/ccc

End-to-end User Acceptance Testing for web applications. Analyzes branch changes and specs to generate exhaustive test cases, sets up the local environment, executes tests via Playwright browser automation, and produces a pass/fail results report with screenshots and fix documentation. Use when the user says "run UAT", "test this feature", "UAT testing", "acceptance test", "test my branch", "generate test cases", or wants to verify a feature branch against its spec before merge.

2026-06-15465

name	mvp-launch
description	Web app MVP launch checklist knowledge. Auto-triggered when conversation involves "launch readiness", "MVP checklist", "production ready", "go live", or pre-launch verification. Provides the 10-point criteria for what counts as "done" in each area. Based on "Realistic MVP Launch Checklist (from building 30+ apps)".

MVP Launch Checklist

A battle-tested 10-point checklist for web app MVP launches. Based on building 30+ apps.

Philosophy: "Don't overbuild. Just make it stable, usable, and something people can trust."

The 10-Point Checklist

1. Stripe Setup (Payment Infrastructure)

What counts as DONE:

Trials configured with appropriate period
Plan switching works (upgrade/downgrade)
Failed payment handling with retry logic
Webhook endpoint registered in Stripe Dashboard
Live keys tested (not just test mode)

Required Webhook Events:

customer.subscription.trial_will_end
customer.subscription.created
customer.subscription.updated
customer.subscription.deleted
invoice.payment_succeeded
invoice.payment_failed
invoice.created
checkout.session.completed

Verification: See references/stripe-testing.md

2. Mobile-First Design

What counts as DONE:

Tested on real phones (not just browser resize)
Touch targets appropriately sized (44x44px minimum)
Forms work on mobile keyboards
No horizontal scroll on mobile

Key insight: Browser resize mode lies. Real device testing is mandatory.

Bonus (not required):

PWA manifest for installability
Offline capability for core features

3. Smooth Onboarding

What counts as DONE:

Steps kept minimal (3-5 max)
Users guided to a fast first win
Progress indicator if multi-step
Can be skipped/completed later

Anti-pattern: Don't require 10 fields before users see value.

4. AI & Automation Stability

What counts as DONE:

API errors handled gracefully
Retry logic with exponential backoff
Edge cases don't crash the app
Timeouts configured appropriately
Fallback behavior when AI fails

Good defaults:

3 retry attempts
30-60s timeout for complex operations
User-friendly error messages

5. Critical Emails

What counts as DONE:

Welcome email (immediate after signup)
Trial-ending email (before trial expires)
Failed payment email (when charge fails)
Password reset (if not using external auth)

Nice to have (don't overbuild):

Support acknowledgment email
Usage milestone emails

6. Error Logging

What counts as DONE:

Error tracking service configured (Sentry, Bugsnag, etc.)
PII scrubbed from logs
Critical errors trigger alerts
Enough context to debug issues

Goal: Catch bugs before users notice them.

7. User Feedback Loop

What counts as DONE:

Simple form or tool to collect feedback
Screenshots/context capture (optional but helpful)
Feedback reaches the team (email, Slack, GitHub Issues)

Examples: Typeform, in-app widget, email link, GitHub Issues integration.

8. Authentication & Roles

What counts as DONE:

Secure page protection (no unauthorized access)
Password reset works (or external auth handles it)
Basic roles defined (admin vs user minimum)
Session management (logout, expiry)

If using external auth (Clerk, Auth0): Most of this is handled for you.

9. Custom Domain with SSL

What counts as DONE:

Own domain configured (no .vercel.app, .replit.app)
HTTPS enabled (auto or manual SSL)
DNS properly configured

Why it matters: Trust. Users won't pay for myapp.replit.app.

10. Real Database & Backups

What counts as DONE:

Production database (not dev/local DB)
Automated backups configured
Point-in-time recovery possible

Good choices: Supabase, Neon, PlanetScale, Convex, AWS RDS.

Anti-pattern: Replit DB, SQLite in production, no backups.

Scoring

Score	Meaning
10/10	Fully implemented, production-ready
7-9/10	Mostly complete, minor gaps
4-6/10	Partial implementation, needs work
1-3/10	Minimal/broken implementation
0/10	Not implemented

Overall (sum of 10 areas):

85-100: Launch Ready
70-84: Nearly Ready
50-69: Needs Work
<50: Not Ready

References

references/search-patterns.md - Grep patterns for discovery
references/stripe-testing.md - Stripe CLI verification commands