Fixed Price MVP Scope: 8 Essential Parts of a Scope That Holds Its Price

Why the fixed price MVP scope matters more than the price

When founders compare offers for a fixed price MVP scope, they usually compare totals. But a total means nothing on its own. Two agencies can quote the same first version very differently simply because one assumed an admin panel and payments and the other did not. The fixed price MVP scope is where those assumptions become visible.

For the agency, the fixed price MVP scope defines the risk it is accepting. For you, it defines what you are buying. When it is precise, the fixed price works as intended: everything written is delivered for the agreed number, and anything new is priced separately before it is built. When it is vague, both sides read their own expectations into it, and the difference surfaces as a dispute in the last weeks of the project, which is the most expensive moment to have it. The general idea of tying deliverables to a defined boundary is what project managers call scope; in a fixed price project it also becomes the commercial contract.

That is why we treat the scope as the main deliverable of discovery. How we run that step is described in our app discovery workshop, and how the scope becomes a price on our fixed price app development page.

8 essential parts of a fixed price MVP scope

These eight parts appear in every fixed price MVP scope we sign. The order matters: each part narrows the next, so by the time you reach acceptance criteria there is little left to interpret.

• The goal of version one. One or two sentences on what the first release must prove, and for whom. Every later item is checked against this goal, which is the simplest way to keep extras out.
• User roles. Each type of user named, with what they can and cannot do. Two roles and four roles are very different projects, so the number belongs on paper.
• User actions and screens, counted per role. For each role, the actions it can take, written as outcomes: "a provider sets weekly availability and blocks single days". The screens follow from the actions.
• Data and integrations. What the system stores, what it imports or sends, and to which outside services: payments, maps, email, accounting. Each integration is a line item with its direction and trigger.
• Platforms and the admin side. iOS, Android, web, or a subset, plus what the admin panel lets your team do on day one. The admin side is the part most often missing from offers.
• Exclusions. A named list of what is not in version one, even if it was discussed. This list is the main protection against misunderstandings.
• Acceptance criteria. For each part of the scope, what has to work for it to count as done, and how the final acceptance is signed.
• Client responsibilities. Who provides store accounts, content, test data, access to third party services and decisions, and by when.

A fixed price MVP scope with all eight parts is usually a short document, often fewer than ten pages with screen sketches attached. Length is not the goal; countability is.

Vague vs countable: how to write a fixed price MVP scope

The single most useful habit when writing a fixed price MVP scope is rewriting verbs into outcomes. Here is the same intention written two ways, taken from the kind of lines we see in scopes founders bring to us.

Notice that the countable versions are not longer because they are padded. They are longer because they make decisions. Every decision written into the fixed price MVP scope is a decision that will not have to be made in a hurry during the build, when it costs the most.

An example: one role written for a fixed price MVP scope

To make the eight parts concrete, here is how one role might look in a scope for a simple services marketplace, where clients book local specialists. The format matters more than the product; the same structure works for an internal tool or a subscription app.

Written like this, the role is easy to estimate, easy to test and easy to discuss. A founder reading it can immediately say "packages must be in version one", and that conversation happens before the price is fixed rather than in week eight. That is exactly the point of a fixed price MVP scope: moving every important disagreement to the cheapest possible moment.

The same pattern repeats for each role, and then for the admin side. When all roles are written this way, the screen count, the integration list and the acceptance walk through almost write themselves, because they follow directly from what each person can and cannot do.

Exclusions: the part of the fixed price MVP scope founders skip

Founders rarely enjoy writing down what they will not get. But the exclusion list is what makes a fixed price MVP scope fair. Without it, anything discussed once in a call can later be read as included, and the agency will either refuse, argue or quietly cut quality somewhere else to absorb it.

A good test: after reading the exclusions, you should feel a little uncomfortable, and you should still be confident that version one proves what it needs to. If you feel no discomfort, the list is probably too short. Our article on MVP scope creep shows what happens to projects without one.

Acceptance criteria inside the fixed price MVP scope

Acceptance criteria answer one question per item of the fixed price MVP scope: how will we both know this works? They do not need to be technical. "A customer can book a free slot and receives a confirmation email within a minute" is a perfectly good criterion. "Booking works" is not.

Writing them before the build changes the conversation at the end. Instead of a subjective review of the whole app, acceptance becomes a walk through a list. Items that pass are accepted; items that fail are fixed within the agreed scope; new wishes that appear during the walk are noted as changes. The final step is a signed acceptance protocol, and on larger contracts the warranty period starts from that date. How this works in practice is in our guide to fixed price app acceptance.

Common mistakes in a fixed price MVP scope

• Copying a big product. Scopes that describe a well known app feature by feature end up long, expensive and slow. The first version needs the core value, not the full product of a company with years of development behind it.
• No admin side. A scope that covers only the user app leaves the office without a way to fix records, approve things or issue refunds. It usually returns as a change request in week two after launch.
• Payments as one line. Payments are several flows: charging, refunds, failed payments and sometimes payouts. In our experience the payment model changes during the project more often than any other part, so it deserves the most precise wording.
• No owner for accounts and content. Store accounts opened late and content that arrives in the last week are among the most common reasons a launch date moves, even when the price holds.
• Leaving change to goodwill. A scope without a written change process forces both sides to improvise when the first new idea appears, which it always does.

Each of these is cheap to fix in the fixed price MVP scope and expensive to fix in code. The process for the last one is described in fixed price change requests.

How to review a fixed price MVP scope before you sign

When the agency sends the scope, read it as if you were the person who will accept the finished app. These four passes take less than an hour and catch most problems before they reach the contract.

• Read it as each user. Go through the scope role by role and imagine a normal day. If you cannot find the action that person takes most often, it is missing.
• Read the exclusions out loud. Anything on that list you are not willing to live without for three months should move back into the scope now, with its price.
• Check every integration twice. For each outside service, confirm the direction of data, who owns the account and who provides access. Integrations are where hidden work lives.
• Ask how you will test it. For three random items, ask how acceptance will be checked. If the answer is vague, the item is too.

A good agency welcomes this review, because every question you ask now is a dispute that will not happen later. If the answers change the fixed price MVP scope, the price may move too, and that is exactly when it should move: before anything is built.

From fixed price MVP scope to contract

In our projects the path from the first call to a signed contract usually takes about two weeks. We start with conversations about the problem and the users, write a first scope to estimate against, run a workshop of one to three days that produces the product document and screen sketches, and only then fix the final price. The signed fixed price MVP scope becomes an annex to the contract.

If you want to understand what drives the number that comes out of this process, our guide to MVP app cost explains it without quoting amounts, and fixed price MVP development covers the model as a whole. When you are ready to scope your own first version, our MVP app development page describes how we work.

FAQ

Related guides