# Mvp Launcher

> Ship MVPs fast: validation frameworks, scoping, build-vs-buy, realistic budgets, tech-stack selection, 3-week sprints, launch checklists, analytics/legal setup, and post-launch playbooks. Use when scoping, building, or launching an MVP and deciding what to build vs buy, what to cut, and how to validate and instrument it.

- **Type:** Skill
- **Install:** `agentstack add skill-san-npm-skills-ws-mvp-launcher`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [san-npm](https://agentstack.voostack.com/s/san-npm)
- **Installs:** 0
- **Category:** [Data & Analytics](https://agentstack.voostack.com/c/data-and-analytics)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [san-npm](https://github.com/san-npm)
- **Source:** https://github.com/san-npm/skills-ws/tree/main/skills/mvp-launcher
- **Website:** https://skills-ws.vercel.app

## Install

```sh
agentstack add skill-san-npm-skills-ws-mvp-launcher
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# MVP Launcher

## 1. Validate Before Building

**Minimum validation checklist (do ALL before writing code):**

- [ ] Problem interviews with 5+ target users (ask about pain, not your solution — see interview script in §13)
- [ ] Competitor analysis — list top 5, identify gaps
- [ ] Landing page + waitlist (a no-code builder like Carrd, Framer, or a single Next.js page) — target 100+ signups or 5%+ visitor→signup conversion
- [ ] Fake-door test: advertise the feature, measure clicks before building (read the ethics rules below first)
- [ ] Define success metric: "MVP is successful if X users do Y within Z days"

**Kill signals:**  **Ethical fake-door / waitlist testing — non-negotiable.** A fake-door test measures intent, not deception.
> - **Disclose state.** Label it "Join the waitlist" / "Coming soon" / "Request early access" — never imply a feature exists if clicking can't deliver it. Don't take payment for something you can't ship; if you charge to validate willingness-to-pay, use a refundable pre-order/deposit and say so.
> - **Minimize data.** Collect only an email (and optionally one qualifying question). No unnecessary PII; no pre-checked marketing opt-ins. State why you're collecting it and add a one-line privacy note + link (see §10).
> - **Honor the implied promise.** Email everyone who signed up — even if you kill the idea ("we're not building this") — and let them unsubscribe.
> - **Don't run misleading paid ads.** Ad platforms (and consumer-protection law in the EU/UK/US) prohibit advertising products that don't exist or can't be bought. Frame ads as "early access / beta," not "buy now."

For deeper interview technique and ongoing feedback loops, pair this with the **`customer-feedback`** skill; for early-community and waitlist growth tactics, see **`community-building`**.

## 2. Scope with MoSCoW

| Priority | Definition | Example |
|----------|-----------|---------|
| **Must** | Product is useless without it | Core value proposition, auth, data persistence |
| **Should** | Expected but can workaround | Email notifications, search, mobile responsive |
| **Could** | Nice to have, adds polish | Dark mode, export, keyboard shortcuts |
| **Won't** | Explicitly cut for v1 | Admin dashboard, API, integrations, i18n |

**The ONE thing test:** Complete this sentence: "Users will choose this over alternatives because ___." If your MVP doesn't nail that sentence, re-scope.

## 3. Build vs Buy

| Feature | Recommendation | Service | Build time if DIY |
|---------|---------------|---------|-------------------|
| Auth | **Buy** | Clerk, Supabase Auth, Auth0 | 2-5 days |
| Payments | **Buy** | Stripe, Lemon Squeezy | 3-7 days |
| Email (transactional) | **Buy** | Resend, Postmark | 1-2 days |
| Email (marketing) | **Buy** | Loops, ConvertKit | 2-3 days |
| File uploads | **Buy** | UploadThing, S3+presigned | 1-3 days |
| Search | **Buy** (until >100k records) | Algolia, Meilisearch | 3-5 days |
| Realtime | **Buy** | Ably, Pusher, Supabase Realtime | 2-4 days |
| Analytics | **Buy** | PostHog, Plausible | 1-2 days |
| CMS | **Buy** | Sanity, Payload | 3-7 days |
| Core feature | **Build** | — | That's your product |

**Rule:** If it's not your core differentiator, use a service. Period.

## 4. Tech Stack Selection

| Project type | Frontend | Backend | DB | Deploy |
|-------------|----------|---------|-----|--------|
| SaaS | Next.js / Remix | Server Actions / tRPC | Postgres (Neon) | Vercel |
| Marketplace | Next.js | API routes + queue | Postgres + Redis | Railway |
| Dev tool / API | Docs site (Mintlify) | Hono / Fastify | Postgres or SQLite | Fly.io |
| Content site | Astro / Next.js | Headless CMS | CMS-managed | Vercel / Cloudflare |
| Mobile-first | React Native / Expo | Supabase | Supabase Postgres | EAS |

**Don't overthink this.** Pick what you know. An MVP in a familiar stack ships 3x faster than one in the "right" stack. The table above is a JS/SaaS default — it is *not* universal. The following constraints override "pick what you know" and can force a different stack:

| Constraint | What it forces | Notes |
|-----------|----------------|-------|
| **Regulated (health/HIPAA, finance/PCI/SOC 2, gov)** | Vendors who sign a BAA/DPA and are in scope for your framework; audit logging; encryption at rest; least-privilege | Generic free tiers often *exclude* a BAA. Confirm contracts before storing regulated data. PCI scope shrinks dramatically if you never touch card data (use Stripe Checkout/Elements). |
| **B2B / enterprise sales** | SSO (SAML/OIDC) and SCIM provisioning on the *near* roadmap, org/role data model from day 1 | Even if v1 ships email login, model `organization → membership → role` now. Auth providers (Clerk, WorkOS, Auth0) sell enterprise SSO as an add-on — don't hand-roll SAML. |
| **Data residency / sovereignty (EU, etc.)** | Region-pinned hosting + DB; a sub-processor list; vendors offering EU regions | Pick a DB/host region in-jurisdiction (e.g. EU) and verify every sub-processor (analytics, email, LLM) honors it. |
| **Mobile + offline-first** | Local-first store with sync (SQLite/WatermelonDB, or a sync engine), conflict resolution | A server-only Postgres CRUD app does not work offline. Decide sync semantics before building. |
| **AI / LLM-heavy** | A model-cost + eval + safety plan (see §11) | Token costs, latency, eval harness, and data-retention terms change your architecture and unit economics. |
| **High-scale realtime / data** | Purpose-built infra (queues, streaming, columnar/analytics DB) | Don't force these into the SaaS default; but also don't pre-build them for an MVP with 50 users. |
| **Team skill** | Your existing language/runtime, even if "unfashionable" | Rails, Django, Laravel, Phoenix, .NET, Go all ship MVPs fine. Familiarity beats trend. |

**Heuristic:** start from the constraints above; only when none bind, fall back to the default table.

## 5. Three-Week Sprint Plan

### Week 1: Core + Foundation
- [ ] Scaffold project, git repo, CI pipeline
- [ ] Auth integration (Clerk/Supabase) — budget ~1 day, not minutes (see the auth row in §8 for everything you still own)
- [ ] Database schema + ORM setup (Prisma/Drizzle)
- [ ] Core feature — the ONE thing — working end-to-end
- [ ] Basic CRUD for primary entity

### Week 2: UI + Integrations
- [ ] UI components (shadcn/ui or similar — don't build from scratch)
- [ ] Payment integration if monetized (Stripe Checkout)
- [ ] Transactional email (welcome, key actions)
- [ ] Mobile responsive pass
- [ ] Error handling + loading states

### Week 3: Polish + Ship
- [ ] Analytics + error monitoring wired with real events (see §12 for the event schema)
- [ ] SEO basics (meta tags, OG images, sitemap)
- [ ] Legal pages sized to your risk tier (privacy policy, terms, cookie/consent banner if needed — see §10; a generator is fine for Tier 0 only)
- [ ] Production deploy + custom domain
- [ ] Seed 3-5 beta users, collect feedback
- [ ] **LAUNCH**

## 6. Launch Checklist

### Infrastructure
- [ ] Custom domain + DNS configured
- [ ] SSL/HTTPS enforced
- [ ] Environment variables set (no secrets in code)
- [ ] Database backups enabled
- [ ] CDN for static assets

### Monitoring
- [ ] Error tracking (Sentry) with source maps
- [ ] Uptime monitoring (BetterStack, UptimeRobot)
- [ ] Analytics tracking core events

### SEO & Social
- [ ] Title + meta description on all pages
- [ ] OG image (use og-image.vercel.app or similar)
- [ ] Favicon + web manifest
- [ ] robots.txt + sitemap.xml
- [ ] Social profiles linked

### Legal & Payments
- [ ] Privacy policy that names your actual data, purposes, and sub-processors (analytics, email, payments, LLM vendors) — see §10
- [ ] Terms of service page
- [ ] Consent banner sized to your tracking + audience, not "if EU traffic" — see the consent decision rule in §10
- [ ] Stripe (or other PSP) test mode → live mode verified; webhooks verified in live mode
- [ ] Refund policy documented (and consumer-law cancellation rights honored where they apply)

## 7. Post-Launch: First 48 Hours

**Hour 0-6:** Monitor error tracking, watch for 5xx spikes, be in support channels.
**Hour 6-24:** Share on social and post on relevant communities — but each platform has its own rules and culture (below). Spray-and-pray gets you flagged or banned.
**Hour 24-48:** Follow up with every user who signed up (use the feedback email in §13). Ask one thing: "What almost stopped you from signing up?"

### Launch channels — rules, not just a list

| Channel | Norms / mechanics | Don't |
|--------|-------------------|-------|
| **Show HN** | Title = "Show HN: ". Post yourself, be the top commenter, answer every reply fast and humbly. Best early US-AM weekday. Front-load a direct, no-signup demo link. | No marketing voice, no fake upvote rings (HN flags rings → penalty/ban), no "we're excited to announce". |
| **Product Hunt** | Pick a launch *date*, line up a hunter/maker, prep gallery + tagline + first comment, mobilize your list to comment (not just upvote). 12:01 AM PT start. | Don't beg for upvotes off-platform (against rules); don't relaunch the same product repeatedly. |
| **Reddit** | Find subs where your users already are; read each sub's self-promo rule (many require a 9:1 contribute:promote ratio or ban links). Lead with the problem, link as context. | Don't cross-post identical text to many subs (spam filter), don't post a bare link in a sub that bans them. |
| **Indie Hackers** | Share the *story/metrics* (build log, revenue, lessons), not an ad. Engagement rewards transparency. | Don't post a pure landing-page link with no narrative. |
| **LinkedIn / X** | Founder voice, a short build-in-public thread, one clear CTA + link. | Don't link-dump; algorithms suppress naked outbound links. |
| **Niche communities (Discord/Slack/forums)** | Ask mods before promoting; contribute first. Often your highest-intent users. | Don't drop links in #general unannounced. |

Track each channel with a tagged URL (UTM params) so you know which channel actually converts — see §12.

### Metrics to Watch (Week 1)

| Metric | Target | Tool |
|--------|--------|------|
| Signups | Track daily | Analytics |
| Activation (core action done) | >30% of signups | PostHog funnel |
| Day-1 retention | >20% | PostHog cohort |
| NPS / feedback sentiment | Qualitative | Manual outreach |
| Error rate |  **Not legal advice.** This is a triage tool. A generator is acceptable *only* at Tier 0. The higher your tier, the more you need a real DPA review and, past a point, a lawyer.

**Pick the highest tier that applies:**

- **Tier 0 — brochure / waitlist, email-only, no payments.** A reputable generated privacy policy + terms is usually fine. Still: name your email/analytics vendors, add an unsubscribe path, and don't over-collect.
- **Tier 1 — accounts + payments, general consumer/B2B.** You now need: a privacy policy that *actually lists* your sub-processors (analytics, email, payments, hosting, LLM), a data-retention/deletion stance, a real cookie/consent decision (below), refund/cancellation terms, and DPAs signed with each vendor. Generators are a starting draft, not the finish line.
- **Tier 2 — sensitive data or sensitive users.** Health/medical, financial, biometric, precise location, or **children** (under-13/16 → COPPA / GDPR-K, strict). Also: EU/UK personal data at scale, US state privacy laws (e.g. CPRA and the growing set of US state laws), or selling/sharing data for ads. **Get counsel.** You likely need DPAs/BAAs, a lawful basis, data-subject-rights tooling (access/delete/opt-out), and possibly a DPIA.
- **Tier 3 — regulated industry / high-risk AI.** Fintech, insurance, healthcare delivery, anything making automated decisions about people, or AI in domains flagged as high-risk under regimes like the EU AI Act. **Counsel + compliance review before launch**, not after.

**Consent banner — decision rule (replaces "if EU traffic"):**
- Loading **non-essential** cookies/trackers (ad pixels, most third-party analytics, session replay) for visitors in the EU/UK and similar regimes generally requires **prior opt-in consent** (ePrivacy/GDPR) — a banner that blocks those scripts until the user agrees.
- US state laws (CPRA et al.) lean toward an **opt-out** model (e.g. "Do Not Sell/Share", Global Privacy Control) rather than opt-in.
- **You may not need a banner at all** if you use a cookieless / privacy-first analytics tool (e.g. Plausible, or PostHog configured without cookies) and load no ad/marketing trackers. The cleanest MVP path: minimize trackers so consent is simple or unnecessary.
- The trigger is the **purpose and origin** of what you load, not merely "is the visitor in the EU." Map your scripts first.

## 11. AI / LLM MVP Concerns (2026)

If your MVP wraps an LLM, these are first-class engineering and unit-economics problems, not afterthoughts:

- **Unit economics.** Price every AI call: `tokens_in + tokens_out → $/request`. Multiply by realistic per-user volume. AI cost can exceed your subscription price — gate it (rate limits, usage caps, paid tiers). Cheaper/smaller models for easy turns, premium models only when needed.
- **Evals before launch.** Build a small golden set (20–100 representative inputs with expected behavior) and an automated eval you re-run on every prompt/model change. Without evals you can't tell if a "harmless" prompt tweak regressed quality. Track win-rate over the set.
- **Prompt injection & untrusted input.** Treat any text the model ingests (user content, web pages, files, tool outputs) as potentially adversarial. Never let model output trigger privileged actions without validation; constrain tools; don't put secrets in prompts; sanitize/structure tool I/O.
- **Safety & abuse.** Add input/output filtering for your domain, refuse out-of-scope requests, and rate-limit to prevent cost-abuse. Log prompts/outputs for debugging — but see retention below.
- **Data-retention & training terms.** Read the provider's data policy: does your data train their models, and how long is it retained? For sensitive/regulated data choose a zero-retention / no-training tier or a deployment that contractually excludes training, and disclose AI processing in your privacy policy (ties to Tier 2/3 in §10).
- **Human-in-the-loop.** For consequential outputs (money, health, legal, irreversible actions) require human review/confirmation. Show sources/uncertainty; let users correct and report bad outputs (feeds your eval set).
- **Latency & fallbacks.** Stream responses; set timeouts; have a fallback model/path so a provider outage doesn't take your product down.

> For agent/tool design, RAG, memory, and eval depth, see the **`ai-agent-building`** skill.

## 12. Product Analytics & Activation Funnel

You can't decide *iterate vs pivot* (§7) without instrumented behavior. Set this up **day 1**, not after launch.

**Tooling:** PostHog (product analytics + funnels + session replay + flags, generous free tier, self-hostable), or Plausible (lightweight, cookieless, privacy-first) for traffic + Sentry for errors. Pick PostHog if you need funnels/retention; Plausible if you only need privacy-friendly traffic.

**Name events as `object_verb`, snake_case, with consistent props.** A minimal SaaS schema:

```ts
// Acquisition
posthog.capture('signup_started',   { method: 'email' })       // or 'google', 'github'
posthog.capture('signup_completed', { method: 'email' })

// Activation — the ONE core action that delivers value (define this explicitly!)
posthog.capture('project_created',  { source: 'onboarding' })  // 2–5% (cold traffic) | Sharpen the landing-page promise (§13) |
| Signup → aha event (activation) | >30% | Fix onboarding: fewer steps, prefill, demo data, clearer first action |
| Aha → day-1 retention | >20% | The core value isn't sticky — re-examine the problem |
| Trial/free → paid | a few % is normal | Pricing/packaging or value-timing issue |
| Error rate |  Numbers are rough planning benchmarks, not laws — they var

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [san-npm](https://github.com/san-npm)
- **Source:** [san-npm/skills-ws](https://github.com/san-npm/skills-ws)
- **License:** MIT
- **Homepage:** https://skills-ws.vercel.app

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-san-npm-skills-ws-mvp-launcher
- Seller: https://agentstack.voostack.com/s/san-npm
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.