The Agile Business Consortium's MoSCoW guidance says Must Haves should typically take no more than 60% of a project's effort, with around 20% kept as Could Haves that can be dropped if the deadline is at risk. An MVP brief that marks every feature as essential leaves no contingency, and a careful developer prices the missing contingency in as risk.
This page is a one-page MVP spec you can copy into a document: 12 fields, a filled-in example, and the reasoning behind each field. The structure borrows from Basecamp's Shape Up, the Agile Business Consortium, GOV.UK's service manual and Atlassian's requirements guidance; the field list and the example are ours, and we say where.
Why one page, and why before the quote
A developer quoting an MVP from a call and a pitch deck is guessing. The guess is not lazy; it is the honest state of the information. Barry Boehm's 1981 work on software estimation, which Steve McConnell later named the cone of uncertainty, put early estimates at up to four times or a quarter of the final effort. We read that figure on Wikipedia's summary rather than in the original book, so treat it as a well-known rule of thumb, not a measurement of your project.
The range narrows as decisions get made. A one-page spec makes the decisions that move a quote the most: who the user is, what the first version must let them do, what it will not do, which outside systems it touches and how much time the founder is willing to spend. It does not try to make every decision. Atlassian's requirements guidance lists the anti-pattern of a project specified in great detail before any engineering work begins, and the same warning applies here.
One page is a constraint, not a format preference. Eric Ries defined the MVP as the version that collects the most validated learning for the least effort. A spec that runs to twenty pages usually describes version three.
Appetite first. Basecamp's Shape Up makes the distinction that matters most for a quote. An estimate starts with a design and ends with a number. An appetite starts with a number and ends with a design. Shape Up's default is a six-week cycle for one designer and one or two programmers, with small-batch work at one to two weeks. A founder who writes "eight weeks, two developers" in the spec gets a scope that fits eight weeks. A founder who writes nothing gets a scope that fits the developer's reading of the deck.
The template: 12 fields
Copy the table into a document and replace the middle column with your answers. Each answer should fit in two or three lines. If one does not, it is either two features or an open question, and it goes in field 12.
| # | Field | What to write | Why the quote needs it |
|---|---|---|---|
| 1 | Problem | One paragraph: who has the problem today, what they do instead, and what that costs them | Sets what counts as solved |
| 2 | Primary user | One role, plus any second role that must exist on day one (for example, an admin) | Each role adds screens, permissions and tests |
| 3 | Appetite | Weeks and team size you are willing to fund, and the date that matters | Turns the quote into a fit test instead of an open estimate |
| 4 | Must Haves | The user stories without which the MVP is not worth launching | The fixed part of the price |
| 5 | Should and Could Haves | Stories you want, ranked, with Could Haves marked as first to cut | The contingency, roughly 20% of effort |
| 6 | Won't Haves this time | Features you have decided against for this version | Stops them returning as small changes |
| 7 | Acceptance criteria | For each Must Have, "it's done when..." in one or two lines | Defines finished, so testing can be priced |
| 8 | Data | What the app stores, which of it is personal data, and who can see it | Drives the database, roles, hosting region and privacy work |
| 9 | Integrations | Every outside system: payments, auth, CRM, email, files, AI models | Integrations are where estimates slip |
| 10 | Success metric | One number that says the MVP worked, and the event that measures it | Analytics is built in, not added later |
| 11 | Constraints | Platforms, browsers, accessibility level, languages, compliance, existing code | Each one changes effort |
| 12 | Open questions and rabbit holes | What you do not know yet, and what looks risky | Priced as discovery, or as an explicit assumption |
Source: Octo Agency template, drawing on Basecamp Shape Up, Agile Business Consortium MoSCoW and Atlassian's PRD guidance
Fields 4 to 6 follow the MoSCoW categories. The Agile Business Consortium defines Must Haves as the minimum usable subset without which the solution is not viable, Should Haves as important but survivable with a workaround, Could Haves as the first to go when the deadline is at risk, and Won't Haves as agreed out of scope for this timeframe. Writing the Won't Haves down is what keeps them out: the guidance says recording them prevents informal reintroduction later.
Field 12 borrows from Shape Up's pitch, which has five parts: problem, appetite, solution, rabbit holes and no-gos. Rabbit holes are the details the team should know about before it falls into them. In an MVP these are often things like "imports from a spreadsheet the customer edits by hand" or "the client wants it to work offline". They take one line to write and can change a quote by weeks.
Filling in the fields that move the price
Most of the template is quick. Five fields need more care, because they are where two developers reading the same page will price differently.
User stories (fields 4 and 5). GOV.UK's service manual uses the three-part format: who the user is, what they want to do, and why. It says the goal is the most important part, because it tells you whether you are solving the right problem. "As a client, I want to see my invoices so that I can pay them without emailing support" is quotable. "Invoice module" is not. Bill Wake's INVEST checklist from 2003 is a useful filter: each story should be independent, negotiable, valuable, estimable, small and testable. If a story fails estimable, it belongs in field 12.
Acceptance criteria (field 7). GOV.UK phrases them as "it's done when...". For logic that branches, the Given, When, Then structure from Cucumber's Gherkin reference works well: the starting state, the action, and the observable outcome. One criterion per Must Have is enough for a quote. The full set gets written during the build.
Data (field 8). List the records the app keeps, mark which contain personal data, and say who can see each. The ICO's guidance on UK GDPR Article 25 expects data protection to be considered from the design stage and throughout the lifecycle, and by default to use only the personal information needed for each purpose. Writing this down early changes the build: fewer fields collected, role-based access designed in, and a hosting region chosen on purpose. Note it if you serve EU or US users too, since that can change the hosting decision.
Integrations (field 9). Name the provider if you know it: Stripe, HubSpot, Google Workspace, a specific AI model. "Payments" can mean one checkout link or a usage-billed subscription with invoices and tax. Our post on The MVP Tech Stack We Recommend in 2026 covers the provider choices and their list prices; the spec only needs to say which jobs the integrations do.
Constraints (field 11). Accessibility is the one founders most often leave blank. W3C's current standard is WCAG 2.2, published in 2023 and updated in December 2024, with three conformance levels: A, AA and AAA. Writing "WCAG 2.2 AA" in the spec costs one line and avoids a retrofit when the first enterprise customer sends a procurement questionnaire.
A filled-in example
Here is the template filled in for an invented product, so you can see the length each answer should be. The company and numbers are illustrative, not a client.
| # | Field | Example answer |
|---|---|---|
| 1 | Problem | Clients email the firm for documents and invoice copies; two staff spend part of each day answering |
| 2 | Primary user | Client contact at a small business; second role: firm staff member who uploads and approves |
| 3 | Appetite | Eight weeks, two developers, live before the January filing season |
| 4 | Must Haves | Client logs in and sees their documents; staff upload and tag a document; client downloads invoices; staff invite a client |
| 5 | Should and Could Haves | Should: email notification on new document. Could: client uploads receipts; Could: e-signature |
| 6 | Won't Haves | Payments in the portal; mobile app; messaging; multi-firm accounts |
| 7 | Acceptance criteria | It's done when a client invited by email can log in, see only their own documents and download any of them |
| 8 | Data | Client names, emails, company details and tax documents: all personal or confidential; staff see all clients, clients see their own |
| 9 | Integrations | Existing practice-management system exports documents nightly; magic-link email login; transactional email provider |
| 10 | Success metric | 50% fewer document request emails within 60 days, measured by tagging the shared inbox |
| 11 | Constraints | Desktop and phone browsers; WCAG 2.2 AA; UK hosting; English only |
| 12 | Open questions | Does the nightly export include invoices or only documents? Who resets a client's access when a contact leaves? |
Source: Octo Agency, illustrative example
Two things in the example are doing most of the work. The Won't Haves rule out payments and messaging, which are each close to a project of their own. And the first open question in field 12 is the biggest pricing risk on the page: if invoices are not in the export, the portal needs a second integration, and the quote has to say so.
What the spec deliberately leaves out
The tech stack. Unless you have existing code or a team that will maintain it, leave the stack to the developer and judge their reasons. We build applications in Next.js and would say so in a quote, along with why it fits your product or does not.
Visual design. Wireframes help if you have them, but the spec is about behaviour. Atlassian's guidance links design explorations after the stories are fleshed out, not before.
The full backlog. Version two belongs in a separate document. Seibel's account of product cycles at Socialcam is a good model: each cycle had a goal, each item was specced and given an owner, and there was no roadmap past the current cycle. The MVP spec is the first cycle.
Cost targets disguised as features. If you have a budget, write it in field 3 as part of the appetite. Hiding it behind a feature list only makes the developer guess twice. For the ranges agencies publish, see MVP Development Statistics 2026, which collects them with their sources.
How a developer turns the page into a quote
The spec is useful only if each field maps to something a quote can price. This is how we would read it.
| Field | What it becomes in the quote | Signal that the price will rise |
|---|---|---|
| Appetite | The fit check: does the Must Have list fit the weeks and team | Must Haves alone fill the appetite, with no room for Could Haves |
| Must Haves and acceptance criteria | Fixed build and test effort | Stories without a goal, or criteria that say "works well" |
| Won't Haves | A line in the quote's exclusions | Empty field |
| Data | Database design, roles, hosting region, privacy notes | Personal or financial data with no stated access rules |
| Integrations | A line per integration, often with a discovery task | "Connect to our system" with no name or documentation |
| Success metric | Analytics events and a simple dashboard | No metric, so no definition of launched |
| Open questions | Discovery time, or a stated assumption with a price if it is wrong | More than five open questions on a one-page spec |
Source: Octo Agency, how we would read a spec
Two outcomes are healthy. The first is a quote that fits the appetite with the Could Haves as contingency, which matches the 60% and 20% shape in the MoSCoW guidance. The second is an honest "this does not fit", with the stories that would have to move to Won't Have for it to fit. A quote that fits a full wish list into a tight appetite without cutting anything is the one to question.
Ask for assumptions in writing. Every open question you leave becomes an assumption in a good quote. Read those first. They tell you what the developer understood and where a change request is likely.
Expect a range on discovery-heavy work. If field 12 is long, a fixed price for the whole build is either padded or brave. A short paid discovery that answers field 12, followed by a fixed build quote, is usually cheaper than paying for the uncertainty twice.
How to use this template
Fill in all 12 fields before your first call with any developer, in one sitting, and stop at one page. Send the same page to everyone you ask, so the quotes can be compared line by line. Then read each quote against fields 3, 6 and 12: does it fit the appetite, does it respect the Won't Haves, and what did it assume about the open questions. Speed is the point of holding the line: Stripe reported that 20% of Atlas startups in 2025 found a first paying customer within 30 days of incorporating, up from 8% in 2020, so the bar for a first version that someone pays for keeps getting shorter. We quote each MVP per project from a page like this one, and our web apps service page explains how we scope and build them.
