The Dev Log › Startup & Business

How to Write an MVP Spec That Founders and Developers Both Understand

By Jezer Niel Blanca, Full Stack Developer · May 29, 2026 · 6 min read

A simple, practical format for scoping an MVP: problem first, clear roles, user stories with acceptance criteria, ruthless priorities, non-goals and open questions.

The most expensive words in software are "that's not what I meant." Most project problems I've seen don't start in the code. They start when a founder and a developer read the same sentence and picture two different things. A good product spec fixes that. It doesn't need to be long or formal; it needs to be clear enough that both sides agree on what's being built, what isn't, and how you'll know it's done. In this post I'll share the simple spec format my team and I use to scope MVPs, written so founders and developers can both understand it.

What a Good MVP Spec Is (and Isn't)

A spec for an MVP is not a hundred-page requirements document. Those take weeks to write, nobody reads them twice, and they're out of date by the first demo. It's also not a single sentence like "Uber for dog walkers," which leaves every important decision unmade.

A useful MVP spec is:

Short. A few pages that someone can read in one sitting.
Focused on problems and outcomes, not just a list of features.
Explicit about what's out of scope, which matters as much as what's in.
Testable, with acceptance criteria so everyone knows when something is done.
Living. It changes as you learn, with changes agreed on by both sides.

A spec is a shared understanding written down. If only one person understands it, it isn't doing its job.

Start With the Problem, Not the Features

The first section should describe the problem in plain language, before any feature is mentioned. I ask founders to answer these questions:

Who has the problem? Be specific about the type of user.
What are they doing today? Spreadsheets, email threads, a competitor, nothing at all?
Why is that painful? Time, money, mistakes, frustration.
What does success look like for them? Describe the outcome, not the interface.

When developers understand the problem, they make better small decisions every day without needing to ask. They also spot simpler solutions that a feature list would hide.

Define Your Users and Roles

Next, list the types of people who will use the product and what each can do. Even a simple app usually has more than one role, such as a customer, an admin, and maybe a team member with limited access. Getting roles and permissions clear early avoids painful rework later, because permissions touch almost every screen.

Write User Stories With Acceptance Criteria

User stories describe features from the user's point of view. The classic format works well because it keeps the focus on why:

As a clinic manager,
I want to see all of today's appointments on one screen,
so that I can spot gaps and double-bookings at a glance.

The story alone isn't enough, though. Acceptance criteria turn it into something testable. I like the Given, When, Then format because founders can read it and developers can turn it straight into automated tests:

Given I am logged in as a clinic manager
When I open the dashboard
Then I see today's appointments sorted by start time

Given two appointments overlap for the same practitioner
When I view the dashboard
Then both appointments are highlighted as a conflict

Given there are no appointments today
When I open the dashboard
Then I see a friendly empty state with a link to add one

Don't Forget the Edge Cases

Notice the last scenario. Empty states, errors, missing data and permission denials are where most misunderstandings hide. For each story, I ask: what happens when there's nothing to show, when something fails, and when the wrong person tries it?

Prioritise Ruthlessly

Every MVP starts with more ideas than time. A simple prioritisation method keeps the scope honest. I use a version of MoSCoW:

Must have. The product doesn't solve the core problem without it.
Should have. Important, but the first users could live without it for a few weeks.
Could have. Nice ideas to revisit once real users give feedback.
Won't have (for now). Explicitly out of scope for this version.

The discipline is in keeping the "must have" list short. A useful test is to ask: if we launched without this, would our first users still get value? If yes, it isn't a must.

Write Down the Non-Goals

The "won't have" list deserves its own section in the spec. Writing down that the MVP won't include, for example, a mobile app, multiple languages or third-party integrations prevents those assumptions from quietly creeping in. It also gives you a ready-made roadmap for later.

Cover the Parts Developers Need

Some sections matter mainly to the people building the product, but founders should still read and agree on them.

Key Flows

Describe the few journeys that matter most, step by step. For most products that means sign-up, the core action, and whatever makes money. Simple sketches or wireframes help enormously here, even rough ones.

Data and Integrations

List the main things the system stores, such as users, bookings or invoices, and how they relate. Note any external services like payments, email or a third-party API, including who owns the accounts. Integrations are often the least predictable part of a build, so calling them out early matters.

Constraints

Note anything that limits the solution: deadlines, budget ranges, compliance requirements, supported browsers or devices, and expected data volumes. These shape technical decisions far more than most features do.

Measure Success and Track Open Questions

The last two sections are small but powerful.

Success metrics describe how you'll know the MVP is working after launch. Choose a few that connect to the problem, like how many users complete the core action or come back the next week. This keeps everyone focused on outcomes rather than just shipping features.

Open questions is a running list of decisions nobody has made yet. It's far better to write "we don't know yet how refunds should work" than to leave it unstated and let a developer guess. Each question gets an owner and is resolved before its feature is built.

Open questions
1. Can a customer cancel within 24 hours of a booking? Owner: founder
2. Do we need invoices in PDF or is email enough for launch? Owner: founder
3. Which payment provider fits the target countries? Owner: dev team

Keep It Alive

Once building starts, the spec becomes a reference rather than a contract carved in stone. When you learn something that changes a story, update the spec and agree on the change together. A spec that matches reality is useful; one that doesn't is worse than none.

Wrapping up

A clear MVP spec starts with the problem, defines users and roles, writes stories with testable acceptance criteria, prioritises ruthlessly, names what's out of scope, covers flows, data and constraints, and ends with success metrics and open questions. It takes days, not weeks, and it saves far more than it costs. If you've got an idea and want help turning it into a clear spec and a working MVP, I'd love to build it with you and my team.

Tags: MVP, Product, Startups, Planning