Originally published at https://axentis.tech/how-to-scope-a-fixed-scope-mvp/.
Most fixed-scope MVP disputes are not really about code. They start with a scope document that let the founder and the delivery team picture two different products, and they surface weeks later as change orders, a slipped date and a strained relationship. If you are a founder or CTO in the US, UK, Canada or Australia preparing to brief an outside engineering team, the way you write the scope will shape your cost and timeline more than any line on the proposal.
This guide shows how to scope a fixed scope MVP that both sides can deliver against: one core user journey, explicit in-scope and out-of-scope lists, written assumptions, testable acceptance criteria and change control that stays flexible. It also covers when fixed scope is the wrong model, and the cost drivers to understand before you ask anyone for a number.
Why fixed-scope MVPs fail: moving targets and fuzzy "done"
When a fixed-scope MVP goes wrong, the warning signs are usually visible in the original brief:
- "Done" was never defined. "Users can manage their orders" can mean a read-only list or a full editing workflow with audit history. Both sides sign, then discover the gap at acceptance.
- The scope is a feature list, not a journey. Forty bullet points with equal weight give nobody a way to decide what matters when time runs short.
- Assumptions stayed in people's heads. Who supplies designs? Is the payments sandbox available? Does the partner API actually support the call you need? Unwritten assumptions become change orders.
- No single decision-maker. If three stakeholders can add requirements and nobody can say no, scope grows by default.
- The estimate came before the thinking. A firm figure produced from a two-paragraph brief is either padded for risk or quietly ignoring it.
Fixed scope vs time and materials: choose deliberately
Fixed scope is not automatically safer. It works when the outcome can be described precisely in advance; it fights you when the main job is discovery. Use this as a rough guide:
| Your situation | Better fit | Why |
|---|---|---|
| One clear user journey, known integrations, designs largely settled | Fixed scope | The outcome is testable up front, so a fixed boundary protects both sides. |
| Problem understood, solution still being explored with users | Time and materials | You want to change direction weekly without renegotiating a contract. |
| Your own engineering lead will direct the day-to-day work | Time and materials or staff augmentation | You are buying capacity, and you own the prioritisation. |
| New partner, real but bounded outcome, trust not yet established | A short fixed-scope pilot first | You test delivery on real work before choosing a longer model. |
Many teams combine the two: a fixed-scope first release, then time and materials or a sequence of fixed slices once the product is in users' hands. If you are still deciding who should direct the engineering, our comparison of staff augmentation vs project outsourcing walks through that choice by stage.
Start from one core user journey, not a feature list
The most useful scoping question is: what is the one thing a real user must be able to do, end to end, for this MVP to be worth releasing? Write it as a short narrative. For example, for a B2B operations tool: "An operations manager signs in, uploads a CSV of orders, sees rows with errors flagged, corrects them in the browser and exports a clean file."
Every candidate feature is then judged against that journey. Sign-in, upload, validation, inline editing and export are in. Team invitations, saved templates, a reporting dashboard and SSO are valuable, but they are not required for the journey, so they wait. This turns arguments about preferences into a single question: does this step serve the journey?
The same logic applies across lanes. A mobile MVP should be a release slice: one core job working on real devices, distributed to testers through TestFlight or Google Play internal testing, with a public store launch planned as a separate step. Our mobile app development work is scoped that way. If the MVP includes an AI feature, keep it assistive, with a person approving outputs before they take effect, and scope it with the same discipline we describe in how to scope an AI pilot.
Write in scope, out of scope and assumptions explicitly
A good MVP statement of work has three lists, and the second and third matter as much as the first.
In scope
List each journey step and what it includes, plus the non-functional basics: supported browsers or devices, the sign-in method, the environments that will exist (for example staging and production), and any security or accessibility requirements that apply to this release.
Out of scope
Name the things people tend to assume are included: an admin panel, more than two user roles, payments, email or push notifications, localisation, SSO, data migration from an old system, public app store submission, and ongoing support after handover. Writing "not in this release" next to each one prevents most acceptance-day surprises.
Assumptions and dependencies
Record what the delivery team is relying on: API access and sandbox credentials by a given date, whether designs are supplied or included, who provides copy and test data, how quickly your product owner will answer questions, and which third-party accounts will be created in your company's name. When an assumption breaks, the conversation is about the assumption, not about blame.
What actually drives MVP cost and timeline
Rather than comparing quotes in isolation, understand the factors that move effort up or down. Most of them are scoping decisions you control:
- User roles and permissions. Each additional role multiplies screens, rules and test cases.
- Integrations. Every third-party API brings its own documentation quality, sandbox limits and failure modes. Unknown APIs deserve a short technical spike before the estimate is fixed.
- Platforms. Web only, web plus one mobile platform, or web plus iOS and Android are very different builds.
- Design maturity. Finished, tested designs reduce rework; "we'll figure out the UX as we go" belongs in time and materials.
- Data migration and quality. Importing messy legacy data is often its own project.
- Compliance and security requirements that change architecture, hosting or audit logging.
- Decision speed on your side. Slow answers and late feedback stretch timelines as much as any technical problem.
A partner who gives a firm figure without asking about these is either pricing the risk in or not seeing it.
Acceptance criteria both sides can test
Acceptance criteria turn "done" from an opinion into a check. Write them before any code, tied to journey steps. A simple format works:
Given a signed-in operations manager, when they upload a CSV with missing order IDs, then those rows are highlighted with a reason, and the export button stays disabled until they are fixed or removed.
Also agree who accepts each item, how many business days they have to review it, what happens if they do not respond, and the difference between a defect (the build does not meet a written criterion) and a change (a new or different criterion). That last definition removes a lot of friction.
Change control that stays flexible without blowing up the scope
New ideas will appear, especially once you see working software. That is healthy. The goal is to absorb them without destroying the date:
- Park first. New ideas go into a visible "next release" backlog by default.
- Swap, don't stack. If something must come in now, something of similar size comes out, agreed in writing by your named product owner.
- Price the change. Anything that cannot be swapped gets a short change note stating its effect on effort and date before work starts.
- Review weekly. A short scope check during the weekly walkthrough of work in progress keeps drift visible while it is still small.
From a scoped MVP to the next release
A fixed-scope MVP should end with a handover, not a cliff. Your company should already own the repositories, cloud accounts and credentials. You should receive setup notes, deployment steps and a list of known issues. Then use real usage to reprioritise the parked backlog and decide the next model: another fixed slice, time and materials, or bringing the work in-house.
How Axentis scopes a fixed-scope MVP
Our Launch Pilot follows the structure in this guide: private scoping around one outcome, written in-scope and out-of-scope lists, acceptance criteria agreed before build, client-owned repositories from day one and a clear decision at the end. Delivery runs as a Product Build Sprint with short cycles and regular walkthroughs of working software, across custom software, mobile release slices, assistive AI and DevOps. For the wider reasoning behind starting small, read our guide to paid pilot projects.
FAQ
What is a fixed scope MVP?
It is a first product release with a written boundary: a defined user journey, explicit in-scope and out-of-scope items, documented assumptions and acceptance criteria. Changes go through an agreed process instead of being added informally.
Is fixed price or time and materials better for an MVP?
Fixed scope suits a clearly defined journey with known integrations. Time and materials suits exploratory work where you expect to change direction often. Many teams use a fixed-scope first release and switch models once the product is in users' hands.
How can I judge MVP cost before I get a quote?
Look at the drivers: number of user roles, integrations, platforms, design maturity, data migration, compliance needs and how quickly your team can make decisions. Reducing any of these in the first release usually reduces effort and risk.
What should happen when a new idea comes up mid-build?
Park it in the next-release backlog by default. If it must be included now, swap out work of similar size, or agree a written change note covering the effect on effort and date before anyone starts on it.
Ready to scope your MVP?
If you have a core user journey in mind and want it scoped with clear boundaries before you commit, discuss a Launch Pilot with Axentis. We will review your brief privately, help you separate the first release from the backlog and agree acceptance criteria before any build starts. Prefer to start with a conversation? Talk to an expert.
If you are planning a first engagement, see how a scoped Launch Pilot from Axentis works, or read more product and engineering notes on the Axentis blog.
Top comments (0)