home / skills / shipshitdev / library / mvp-architect
This skill helps you scope an MVP by guiding problem clarity, core hypothesis, and feature prioritization for rapid, validated launches.
npx playbooks add skill shipshitdev/library --skill mvp-architectReview the files below or copy the command above to add this skill to your agents.
---
name: mvp-architect
description: Use this skill when users need to scope an MVP, define minimum viable features, plan early product development, or determine what to build first. Activates for "what should my MVP include," "scope my MVP," "what to build first," or product scoping questions.
version: 1.0.0
tags:
- business
- hexa
- mvp
- product
- scope
- build
- features
auto_activate: true
---
# MVP Architect - Minimum Viable Product Scoping
## Overview
Help indie founders scope the smallest possible product that validates their core hypothesis using Hexa's methodology. Get to market in 3 months or less.
**Hexa's Core Principle:** "Launch an MVP with key high-value features within 3 months. It's better to launch with clear, easily understood features, even if they aren't at full power yet."
## When This Activates
- "What should my MVP include"
- "Help me scope my MVP"
- "What features do I need"
- "What to build first"
- "Been building for months, haven't launched"
## Hexa's 7 Principles
1. **Dig Beyond User Requests** — Root needs, not surface wants
2. **Combat Confirmation Bias** — Challenge assumptions
3. **Partner with Design Partners Early** — Build with real users
4. **Prioritize Adaptable Milestones** — 6-month goals, 2-week sprints
5. **Sketch Before Designing** — Keep ugly until validated
6. **Build Around Dry Elements** — Only include stable features
7. **Stress-Test Architecture** — Database design affects everything
## Quick Workflow
### Step 1: Problem Clarity Check
- 10+ customer interviews?
- One-sentence problem?
- 3-5 design partners?
### Step 2: Core Hypothesis
```
We believe that [customer] has a problem with [pain point].
We believe that [solution] will solve this.
We will know we're right when [success metric].
```
### Step 3: Feature Prioritization
For each feature ask:
- Tests core hypothesis? → Keep
- Users explicitly asked? → Maybe
- Critical path? → Keep
- Can do manually? → Don't build
**Target: 3-5 features maximum.**
### Step 4: Dry Elements Test
Only build features that remained stable through ALL design partner feedback.
### Step 5: User Journey (3-4 Screens)
- How do users sign up?
- First action?
- Core value delivery?
- Success confirmation?
## Anti-Scope Creep Checklist
Before adding ANY feature:
1. Does this test our core hypothesis? → If no, cut it
2. Have 3+ design partners asked? → If no, defer it
3. Can we launch without this? → If yes, defer it
4. Can we do this manually first? → If yes, don't build it
5. Will this delay launch by >3 days? → If yes, cut it
## The "Launch in 2 Weeks" Test
If you HAD to launch in 2 weeks, what would you cut?
**Whatever you'd cut... cut it now.** That's your real MVP.
## Integration
- `idea-validator` - Validate before scoping
- `startup-icp-definer` - Define who you're building for
- `fullstack-workspace-init` - Set up codebase
- `brand-architect` - Name and position product
---
**For complete hypothesis framework, feature prioritization matrix, dry elements identification, screen mapping, technical architecture checklist, timeline templates, and output format, see:** `references/full-guide.md`
This skill helps founders and small teams scope a minimum viable product (MVP) that validates the core hypothesis quickly and with minimal waste. It applies a pragmatic methodology focused on launching high-value, testable features within three months. The output is a tight feature set, a simple user journey, and a shortlist of non-negotiable technical checks to avoid rework.
I guide you through clarifying the problem, writing a clear hypothesis, and prioritizing no more than 3–5 features that directly test that hypothesis. I run features through a dry-elements test and an anti-scope-creep checklist so you only build what’s stable and necessary. Finally, I map a 3–4 screen user journey and a short launch timeline, calling out manual workarounds you can use instead of building functionality immediately.
How many features should my MVP have?
Target 3–5 features max; each must directly test the core hypothesis or be critical to the user’s path to value.
What if users ask for many features?
Only include features requested by multiple design partners and that survive the dry-elements test; defer or do them manually first.
How do I know the MVP is ready to launch?
You’re ready when the core hypothesis has a measurable success metric, the 3–4 screen journey delivers value, and technical checks don’t block rollout.