Fixed Price Model: How It Can Benefit Your Business, and How to Set It Up

A fixed price benefits you when the scope is small and clear. You know the cost and the date before work starts, the vendor carries the risk of its own estimate, and you don’t have to manage the team day to day. That fits a narrow first version of a product, a one-week discovery step, a code audit or a design package. It doesn’t fit work whose scope you can’t describe yet.

This guide covers what a fixed price gives you, the five conditions it needs, what to leave out of it, and how we price fixed work ourselves. The other parts of this series explain why fixed price fails when the scope can’t be fixed and how time and material contracts work.

What a fixed price gives you

A fixed price is one price for an agreed scope, set before work starts. The US government’s rewrite of its acquisition rules describes a firm-fixed-price contract as one whose price is “not subject to any adjustment” for how the work actually goes, and says it suits work with clearly defined specifications (FAR Part 16, Revolutionary FAR Overhaul text). If the vendor underestimated, that’s the vendor’s problem.

For a business that means four things:

• A known budget, one number you can put in front of a board, an investor or your own bank account.
• A known date, because the vendor plans the team and the work to hit it.
• Less management on your side. The vendor runs the people, and you review results.
• A small, safe way to test a new vendor. If the first fixed-price project goes well, you can move to a longer model with someone you’ve already seen work.

Hays, a recruitment company, started with us on a fixed price for a tool that formats CVs. When the tool grew into a larger system, the work moved to a dedicated team. Formatting one CV went from up to 2 hours to 2 minutes.

Five conditions for a fixed price that works

Check your project against these before you ask for one price:

1. The first release does one main job. Sign-up, payments and admin screens are there to support that job, not to compete with it.
2. You can write acceptance checks for every feature: what a user can do when it works.
3. One person on your side makes decisions and accepts the work.
4. The riskiest technical question is answered, or gets tested first, before the price is final.
5. The exclusions are written down: what the price doesn’t cover.

If you can’t meet the second or the fourth condition, buy a short discovery step first. If you can’t meet the third, fix that first, whatever the pricing model.

Write down what the price leaves out

A fixed price covers only what’s written down, so list what it doesn’t cover. These are the usual gaps.

Start with store review. For a mobile app, the build finishes when the app is submitted, and review happens on Apple’s and Google’s side. Apple says it reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours, and that over 40% of unresolved issues relate to guideline 2.1, App Completeness (Apple App Review). A rejection adds a round. That’s why store review time comes on top of our 2-4 week MVP timeline.

Next come updates after launch, because platform rules keep moving. From 31 August 2026, Google Play requires new apps and updates to target Android 16, API level 36 (Android Developers). A fixed price for a build doesn’t cover next year’s rule changes. Agree a rate for them now.

Then the smaller items: content and copy, migrating old data, hosting and third-party fees, and the number of change rounds on designs.

Our fixed-price work

These are the pieces of work we sell at a fixed price, with the prices published on our site.

Work	Price	Time	What you get
UX audit of a live product	$2,500	1-1.5 weeks	Main flows reviewed, problems ranked by what they cost, sketched fixes for the top ones
Discovery sprint	$3,000	1 week	Written scope, main user flow in a clickable prototype, technical plan, a 1-day test of the riskiest question, backlog with hours, a fixed price for the build; counts toward the build
Code and architecture audit	$3,500	5 working days	What you own, the state of the code, security findings, keep, fix or rebuild, a takeover plan with hours
MVP design and clickable prototype	$5,000-11,000	3-5 weeks	About 15-25 screens, a prototype tested with people from your audience, Figma files; counts toward a build with us
MVP development	$5,000-15,000	Typically 2-4 weeks, plus store review	A first version real users can try, the designs, the written scope and a backlog for the next release

The MVP is a fixed price when the scope is clear. When it will move, we bill the same work at $39-55 an hour instead.

How the market prices fixed-price MVPs

Fixed prices sit at the cheaper, faster end of the market. In our study of 95 agencies, the 20 that sell their own MVP at a fixed price or in fixed packages have a median start of $8,200 and an upper timeline of 8 weeks. Of the nine agencies that sell an MVP for under $5,000 or promise one in four weeks or less, eight sell at a fixed price (Rocketech MVP Price Index 2026).

Low prices and short timelines usually come with a narrow scope. When you compare fixed-price offers, compare what each one includes and excludes before you compare the numbers.

How changes work on a fixed price

Scope will still change a little. On a fixed price, a change gets a new estimate before anyone works on it. Ask the vendor for that rule in writing, and keep a short log of every approved change with its price and its effect on the date.

Two habits keep the log short. Swap rather than add: when a new idea comes up, ask whether it can replace a feature of the same size. And park the rest in the backlog for the next release, which can have its own price.

How we would estimate it before you ask for a price

Before a range becomes one price, you need to know what’s in it.

1. Our project estimate turns your brief into user stories. You confirm what’s in scope, and every hour in the budget traces back to a story you kept.
2. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. It’s a planning range, not a fixed quote. A discovery sprint turns it into one price.
3. The unit economics show how many customers pay for the build and in which month it’s paid back. You can change any starting number and the math updates.
4. For a new product, the estimate also suggests customer groups with a TAM, SAM and SOM for each. Treat them as hypotheses to test, not verified demand.

Here is an example run of our estimate’s math with sample inputs for an online store with a mobile app: catalogue, cart, checkout and an orders admin. Every input is an assumption. Only the arithmetic is ours.

Starting number (assumption)	Value	Result	Value
Spend a month per customer	$45	Budget range for the build	$5,900-12,300
Margin	35%	Timeline	5 weeks
Months a customer buys	10	Lifetime value	$160
Cost to win a customer	$25	Customers who pay for the build	68
New customers a month	200	Payback month	4

A range like this is the starting point for a fixed price, not the price itself. You can estimate your MVP’s cost and timeline in about four minutes.

What we would do

1. Cut the first release to one main job, and park the rest in a backlog.
2. Write acceptance checks for every feature you keep.
3. Name the one person who decides and accepts.
4. Test the riskiest technical question first, in a discovery step if needed.
5. List the exclusions: store review, updates after launch, content, data, fees.
6. Ask for one price, the change rule in writing, and payments tied to working software.

FAQ

What is a fixed price model in software development?

One price for an agreed scope, set before work starts. The vendor carries the risk of its own estimate, and changes to the scope get a new estimate before anyone works on them.

When should you choose a fixed price?

When the scope is small and clear: you can write acceptance checks for every feature, one person decides, and the riskiest technical question is already answered. A narrow first MVP, a discovery sprint, an audit or a design package fit well.

What does a fixed price usually not include?

Store review time for mobile apps, updates for new platform rules after launch, content and copy, data migration, hosting and third-party fees. Write the exclusions into the contract so nobody argues about them later.

Is a fixed price more expensive than paying by the hour?

It can be, because the vendor prices in the risk of being wrong. For a small, clear scope that risk is small, so the price stays close to the hours. For a scope that will move, paying by the hour with a cap usually fits better.