| name | mvp-spec |
| description | Turn a rough product idea into a structured MVP spec — problem statement, personas, core loop, feature split, data model, API routes, page list, and tech stack recommendation. Write this before touching any code. Triggers on requests like "spec this out", "MVP spec", "plan this product", "what should I build first", "scope this idea", "PRD", "product spec", "write a spec for...", "help me plan this", "what do I build in v1", "product requirements", or any request to structure a product idea before writing code. |
| category | planning |
| tags | ["mvp","spec","planning","product","prd"] |
| author | tushaarmehtaa |
The spec you write before touching any code. Turns a rough idea into a buildable v1 with a clean feature cut, data model, and stack recommendation.
Phase 1: Capture the Idea
Ask for anything missing:
- The idea — What does it do? One sentence.
- Who is it for? — Target user. "Developers" is too vague. "Solo SaaS founders building with Next.js" is specific.
- Monetization — Free, freemium, paid, credits? Skip for now if unclear.
- Tech preferences — Any stack constraints? Or let the skill recommend.
If the user gives you a paragraph, extract these from it and confirm before continuing. Don't ask for what you already have.
Phase 2: The One-Build Rule
Before writing anything, validate the scope:
- Is this ONE product, or three ideas stapled together?
- Can v1 be built and shipped in 1–2 weeks by one person?
- Is there one clear action the user takes to get value?
If the idea is too broad, cut it. This spec covers v1 only — not the vision, not the roadmap.
The narrowing question: "If you could only ship ONE feature this week and it had to deliver real value — what would it be?" That's the core loop. Build the spec around that.
Phase 3: Feature Split
List every feature that came up. Then sort ruthlessly.
LAUNCH (ships in v1)
Only features that complete the core loop:
- User can sign up
- User can do the one thing
- User gets value from doing it
- You can see that they got value
LATER (month 2+)
Everything else. Default everything here unless it's provably required for launch:
- Settings, preferences, notifications
- Team features, collaboration, multi-user
- Admin dashboard
- Analytics dashboards
- Mobile optimization
- Integrations, webhooks, API access
The test: "If I remove this, can a user still get value from v1?" Yes → LATER.
Phase 4: Data Model
Design only for LAUNCH features. Don't model LATER features — the schema will change anyway.
users
├── id (uuid)
├── email
├── [plan | credits — if monetized in v1]
├── created_at
└── updated_at
[core resource]
├── id (uuid)
├── user_id → users.id
├── [core fields]
├── created_at
└── updated_at
Relationships:
- users has many [resources]
- [resource] belongs to user
One table per entity. No join tables unless collaboration is in v1 (it almost never is).
Phase 5: API Routes
Only routes LAUNCH features actually need.
Auth
POST /api/auth/signup
POST /api/auth/login
GET /api/auth/me
[Resource]
GET /api/[resource] — list (current user only)
POST /api/[resource] — create
GET /api/[resource]/:id — get one
DELETE /api/[resource]/:id — delete
No PUT/PATCH unless editing is core to the loop in v1.
Phase 6: Pages
Every screen the user sees in v1.
/ — Landing page
/login — Auth
/signup — Auth
/dashboard — Main view after login
/[resource]/:id — Detail view (if needed)
/settings — Only if required for launch
Phase 7: Tech Stack
Match the recommendation to the user's stated constraints.
| Priority | Stack |
|---|
| Ship fastest, solo | Next.js + Supabase + Vercel |
| Full backend control | Next.js + Postgres + Prisma + Railway |
| AI-heavy | Next.js + Vercel AI SDK + Supabase |
| Python backend | FastAPI + Postgres + Supabase Auth |
Always explain why — one sentence per choice. "Supabase: auth + postgres in one service, no separate backend needed for v1."
Phase 8: Scope Cut List
The most important section. Explicitly list what v1 does NOT build.
v1 does NOT include:
- Team workspaces or multi-user support
- Email notifications
- API access for external integrations
- Mobile app
- Custom domains
- [anything that came up but got cut]
This prevents scope creep during the build. Reference it every time someone says "just one more thing."
Verify
[ ] Problem statement is one sentence
[ ] 2-3 user personas with specific pain — not demographic labels
[ ] Core loop identified — one action, one value delivered
[ ] Feature list split into LAUNCH and LATER
[ ] LAUNCH features cover exactly one core loop, nothing else
[ ] Data model covers LAUNCH features only — no speculative tables
[ ] API routes listed with HTTP methods
[ ] All pages listed — no screens without a route
[ ] Tech stack recommended with one-sentence reasoning per choice
[ ] Scope cut list explicitly names what v1 does NOT build
[ ] Entire spec is buildable in 1-2 weeks by one person
See references/guide.md for full example specs, the one-build rule applied to real product ideas, and data model patterns by product type.
