The MVP Planning Workbook

Before writing a single line of code — before even hiring a development team — you need honest answers to these 10 questions. Not hopeful answers. Evidence-based answers. Every "I think so" is a risk multiplier on your investment.

The 10 Questions:

1. Can you describe the problem in one sentence? If your problem statement takes a paragraph, you have not narrowed it enough. "Small restaurants lose 15% of revenue to no-show reservations" is clear. "The restaurant industry has operational inefficiencies" is not.
2. Have you talked to 20+ potential users? Not friends. Not family. Real potential customers who experience the problem today. What are they currently doing to solve it? How much time or money does the problem cost them?
3. What do people use today instead of your solution? Every problem has a current solution — even if it is a spreadsheet, a phone call, or doing nothing. Your product must be 10x better than the existing solution for people to switch.
4. Will people pay for this? Have you asked? Better yet: have you pre-sold it? A landing page with a "Join Waitlist" button that converts at 5%+ is evidence. Your mother saying "that sounds nice" is not.
5. What is your unfair advantage? Domain expertise, proprietary data, unique distribution channel, first-mover in a regulated market, or a technical innovation that is hard to replicate. "We will execute better" is not an advantage.
6. Can you define your target user in specific terms? "Everyone" is not a target market. "Independent restaurant owners in the US with 20-100 seats and no existing reservation system" is a target market.
7. What is the smallest version that tests your core hypothesis? Your MVP should test one thing: will users adopt your core value proposition? Everything else is scope creep in disguise.
8. Do you have 12-18 months of runway? Building the MVP is the easy part. Finding product-market fit takes time. Marketing, iteration, pivots — all cost money and time beyond the initial build.
9. Is the market large enough? A $10M total addressable market caps your upside. You need a TAM that justifies the investment — typically $100M+ for venture-backed, $10M+ for bootstrapped.
10. Can you commit to this for 3-5 years? Startups are not side projects. If you are not willing to spend years on this problem, do not spend thousands building a product for it.

Score yourself honestly. 8-10 yeses with evidence means you are ready to build. 5-7 means do more research. Below 5 means the idea needs more development before investing in code.

Feature creep kills more MVPs than bad code. The solution is a disciplined prioritization framework that forces you to confront what truly matters versus what feels important.

The Four Buckets:

Must-Have (P0): The product literally does not work without these. Users cannot complete the core workflow. For a marketplace: listing creation, search, and contact/purchase flow. For a SaaS tool: the one workflow that is your value proposition. If you have more than 5 must-haves, you have not defined "minimum" correctly.

Should-Have (P1): The product works without these, but the experience suffers significantly. Examples: email notifications, basic analytics dashboard, password reset, profile editing. These typically make it into the MVP but get simplified — basic versions, not polished versions.

Nice-to-Have (P2): Features that improve the experience but are not essential. Examples: advanced filters, export functionality, dark mode, social sharing, customizable dashboards. These are your post-launch iteration roadmap. Do not build them now.

Future (P3): Features for when you have traction. Mobile app, API for third-party integrations, advanced analytics, AI features, multi-language support. Write them down so you do not forget, then close the document.

The Prioritization Exercise: List every feature anyone has suggested. For each one, answer: (1) Does this directly help users complete the core workflow? (2) Will users leave if this is missing on day one? (3) Can this be added in a post-launch update without architectural changes? If the answer to #1 is no, it is P2 or P3. If #2 is no, it is P1 at best. If #3 is yes, defer it.

Real-world example: A client wanted their MVP to include: user auth, listings, search, messaging, payments, reviews, admin panel, analytics, email marketing, referral program, and a mobile app. We shipped: user auth, listings, search, messaging, and a basic admin panel. Five features. They found product-market fit in 60 days and added the rest over the next 6 months.

Personas get a bad reputation because most are useless — pages of fictional demographics that no one reads. A useful persona is a one-page decision-making tool that answers: who is this person, what do they need, and how do they behave?

The Template (fill this out for each persona):

Name and Role: Give them a name and title. "Sarah, Operations Manager at a 50-person logistics company." Keep it grounded in reality — ideally based on someone you actually interviewed.

Core Problem: One sentence. What is the biggest pain point your product addresses for them? "Sarah spends 10 hours per week manually reconciling delivery data across three different systems."

Current Solution: How do they solve this today? "A combination of Excel spreadsheets, email chains, and a whiteboard in the warehouse." This is your competition — not another SaaS tool.

Goals: What does success look like for them? (1) Reduce reconciliation time to under 1 hour/week. (2) Eliminate data entry errors that cause delivery failures. (3) Get real-time visibility into delivery status.

Frustrations: What makes current solutions painful? (1) Data lives in multiple places and never matches. (2) She is the bottleneck — everyone asks her for status updates. (3) Manual processes do not scale as the company grows.

Behavior Patterns: How tech-savvy are they? When do they work? How do they discover new tools? "Sarah is comfortable with software but not technical. She works 7am-4pm. She discovers tools through industry conferences and LinkedIn peer recommendations."

Decision Criteria: What will make them choose your product? (1) It must integrate with their existing delivery tracking system. (2) The team must be able to use it without training. (3) She needs to see ROI within the first month.

Create one persona for your primary user and one for your secondary user (if applicable — like an admin). Do not create personas for every possible user type. Your MVP serves one persona extremely well.

When you approach a development partner, the quality of your requirements directly impacts the accuracy of their estimate and the speed of delivery. Here is what to prepare — even if you are not technical.

User Flows (most important): For each core feature, describe the step-by-step journey. "User signs up → completes onboarding form → sees dashboard → creates first project → invites team member → assigns task." Use simple flowcharts or even bullet points. The goal is to show every screen the user touches and every decision point.

Data Entities: What are the main "things" in your system? Users, Projects, Tasks, Comments, Files, Invoices. For each entity, list the key attributes. A Project has: name, description, status, owner, due date, team members. You do not need a database schema — just the business objects and their relationships.

Integrations: What third-party services does your product connect to? Payment processing (Stripe), email (SendGrid/Resend), file storage (S3/Cloudflare R2), analytics (PostHog), authentication providers (Google, GitHub). List each integration and what data flows between systems.

User Roles: Who uses the system and what can each role do? Typical roles: Admin (full access), Manager (team-level access), Member (own data + shared resources), Guest (read-only). Map each role to the features they can access.

Non-Functional Requirements: These are constraints that are not features but matter: expected number of users at launch and in 12 months, performance expectations (page load under 2 seconds), compliance requirements (HIPAA, SOC2, GDPR), uptime requirements (99.9%?), and data retention policies.

What NOT to include: Do not specify technology choices unless you have strong reasons. Do not design the database schema. Do not write API specifications. These are decisions your development team should make based on your requirements. Your job is to describe the "what" — their job is to figure out the "how."

Most founders budget for the build and forget everything else. Here is a realistic breakdown by complexity tier, including post-launch costs that catch people off guard.

Tier 1: Simple MVP ($15-25K, 4-6 weeks)

• 3-5 core features, single user role or basic roles
• Standard auth (email + social login)
• Simple CRUD operations with clean UI
• Basic admin panel
• Responsive web app (no mobile app)
• Examples: landing page builder, booking tool, simple marketplace
• Monthly post-launch: $2-3K (hosting, support, minor updates)

Tier 2: Standard MVP ($25-40K, 6-8 weeks)

• 5-8 features, multi-role access control
• Payment integration (Stripe/subscription billing)
• Third-party API integrations (2-3 services)
• Email notifications and transactional emails
• Dashboard with basic analytics
• Examples: SaaS platform, two-sided marketplace, project management tool
• Monthly post-launch: $3-5K

Tier 3: Complex MVP ($40-50K+, 8-12 weeks)

• 8+ features, complex business logic
• Real-time features (chat, live updates)
• Advanced integrations (5+ third-party services)
• Compliance requirements (data encryption, audit logs)
• Multi-tenant architecture
• Examples: fintech platform, healthtech app, enterprise SaaS
• Monthly post-launch: $5-8K

Year 1 Budget Formula: MVP Build Cost + (Monthly Post-Launch × 10 months) + Infrastructure ($200-500/month) + Contingency (15% of total). For a $30K MVP: $30K + $40K + $4K + $11K = approximately $85K total Year 1 technology budget.

Timeline Killers to Budget For: Third-party API changes (budget 1 week), scope additions (budget 20% buffer), compliance reviews (budget 2-4 weeks for regulated industries), and app store approval (budget 2-3 weeks for mobile apps).

Use this checklist in the final week before launch. Every item should be verified, not assumed. A skipped checkbox is a launch-day crisis waiting to happen.

Infrastructure:

• Production environment is separate from staging
• SSL certificate is active and auto-renewing
• Domain DNS is configured with proper TTL
• CDN is active for static assets
• Database backups are running automatically (test a restore)
• Environment variables are set for production (not dev keys)

Monitoring and Error Tracking:

• Error tracking is active (Sentry or equivalent)
• Uptime monitoring pings every 60 seconds
• Performance monitoring tracks page load times
• Alert notifications go to phone, not just email
• Log aggregation is set up for debugging

Security:

• All API endpoints require authentication (unless intentionally public)
• Rate limiting is active on auth and API endpoints
• CORS is configured for your domain only
• Sensitive data is encrypted at rest and in transit
• Admin routes are protected with role-based access
• SQL injection and XSS protections are verified

User Experience:

• Onboarding flow tested with 5+ real users
• All forms have validation and error messages
• Loading states exist for all async operations
• 404 and error pages are branded (not default)
• Mobile experience tested on actual devices (not just browser resize)
• Email deliverability verified (check spam folders)

Business:

• Terms of service and privacy policy are published
• Cookie consent is implemented (if required)
• Payment flow tested with real transactions (then refunded)
• Support channel is active (email, chat, or help center)
• Analytics tracking confirmed for key conversion events
• Launch announcement is drafted and scheduled

Post-Launch Plan:

• On-call schedule defined for the first 2 weeks
• Bug triage process documented (critical vs. non-critical)
• User feedback collection mechanism is in place
• First iteration sprint is planned for week 2 post-launch
• Success metrics defined (what does "working" look like?)