Founder template
How to Write a Spec for Your MVP - A Template for Non-Technical Founders
Short answer
An MVP spec doesn't need to be 30 pages. It needs to answer 6 questions: who is the user, what problem are you solving, what's the single workflow, what's in scope, what's NOT in scope, and what does success look like? This post is a copy-paste template you can fill in tonight and send to a developer tomorrow.
Published April 25, 2026 · Last updated April 25, 2026
What an MVP spec is for
An MVP spec is a single document that tells your developer what you want built. It's not a contract. It's not a wireframe. It's the brief that lets a senior developer scope your project, give you a fixed quote, and start coding within 48 hours.
Bad specs are 30 pages of hedged requirements that try to anticipate every edge case. Good specs are 1-2 pages that answer 6 questions clearly enough that a developer can ask follow-up questions on a 30-min call and start work the next day.
The 6 questions every spec must answer
1. Who is the user? Be specific. Not "small business owners." Try: "Wedding planners with 3-10 weddings per year, mostly solo or 2-person teams, currently using spreadsheets and email." Specificity makes every other decision easier.
2. What problem are you solving? One sentence. Not "streamline operations." Try: "Wedding planners spend 4 hours per wedding emailing vendors back and forth, losing context and missing deadlines."
3. What's the single workflow? The core loop your MVP delivers. Three to five steps, each describing what the user does. Try: "Planner adds a wedding → invites vendors via email → vendors confirm and upload contracts → planner sees status in one dashboard."
4. What's in scope for v1? A bulleted list of features required for the workflow above. Authentication, the primary screens, the primary actions, payments if needed. Stop here. If you're listing more than 8-10 items, you're scoping v2, not an MVP.
5. What's NOT in scope? Equally important. Mobile app, integrations, admin dashboards, multi-tenant features, internationalization - anything you've imagined but isn't required for the core workflow goes here. Saying it explicitly prevents scope creep later.
6. What does success look like? The metric that tells you the MVP worked. Not "users love it." Try: "By week 8, 5 paying wedding planners have used the dashboard for at least one full wedding."
Copy-paste template
Use this verbatim. Replace the bracketed placeholders. Send the result to your developer. It works.
MVP Spec - [Project Name]
1. User
[1-2 sentences. Who specifically uses this? What's their current workflow?]
2. Problem
[1 sentence. What pain point does this solve?]
3. Core workflow
[3-5 numbered steps the user completes end-to-end.]
4. In scope (v1)
- [Feature 1]
- [Feature 2]
- [Feature 3]
- [...up to ~8 items]
5. Explicitly NOT in scope
- [Feature/integration deferred to v2]
- [...]
6. Success metric
[Specific, measurable, time-boxed. "By week N, X users have done Y."]
7. Constraints
- Budget: $[amount]
- Timeline: [N weeks, target launch date]
- Stack preferences: [or "developer's choice"]
- Existing assets: [Figma link, brand guide, anything you have]
What to leave OUT of the spec
Database schemas. Your developer will design these. Listing tables makes you sound technical without actually informing the build.
Tech stack opinions, unless you have a real reason. If you must integrate with an existing system, say so. Otherwise, let the developer pick.
UI specifics, unless you have designs. "Modern, clean" is meaningless. Either include a Figma file or trust the developer's design sense.
Edge cases for v1. What happens if the wifi cuts out? What if a user uploads a 2GB file? Save these for v2. The MVP exists to validate the core flow.
Future features. They distract everyone. Mention them in section 5 (NOT in scope) and move on.
What to add if you have it
A screenshot from a similar product. One image saves 500 words. "Make the dashboard feel like Linear's project view" is more useful than a paragraph of UI description.
A Figma file. Even rough wireframes. Even hand-drawn sketches on paper. Visual context speeds the build dramatically.
Real user quotes. The exact words from your 5 user interviews. Developers reference these when scoping copy and microcopy.
A staging URL of an inspiration product. "This is what done looks like" is the fastest spec compression in existence.
What to do after you send the spec
Book the discovery call within 48 hours. The developer will have questions. Specs are starting points, not contracts. The call locks scope.
Get a fixed quote in writing. Price, timeline, deliverables. If you can't get this within a few days, the developer is not the right fit.
Sign and pay the deposit. 50% upfront is standard. Don't negotiate this down - paying signals commitment and earns priority on the developer's calendar.
Stop changing the spec. Scope is locked at signing. New ideas go in a "v2" doc. If something is genuinely critical that you forgot, agree on a fixed change-order fee in writing.