A fixed price works when you can describe the finished software before anyone writes code. It fails when you can’t: the requirements are still forming, you plan to learn from users during the build, or rules outside your control will change halfway through. In each case every change reopens the price, and the vendor protects itself by charging more or building less.
We sell fixed prices ourselves, for scopes small and clear enough to describe up front. This post gives you a test to run on your own project, six signs that it fails the test, and what to use instead. The other two parts of this series cover when a fixed price works and how to set one up and how time and material contracts work.
The rule of thumb isn’t ours. The US government is rewriting its Federal Acquisition Regulation, and the new Part 16, published as model text in September 2025 and revised in 2026, says a firm-fixed-price contract suits work bought “on the basis of clearly defined” specifications, when a fair price can be set at the outset (FAR Part 16, Revolutionary FAR Overhaul text). After that, the price is “not subject to any adjustment” for how the work actually goes.
So the question for your project is plain. Can you define the work clearly enough today to put one price on it? If two or more of the signs below fit, the honest answer is no.
If you can’t say, feature by feature, what a user must be able to do for the work to count as done, the vendor fills the gaps with its own reading of the brief. Unclear requirements hurt teams on any model. In the Stack Overflow Developer Survey 2026, “unclear priorities or requirements” was the most common reason developers gave for their job getting harder, at 16.6% of 18,214 answers. On a fixed price, each gap turns into an argument about whether something is a bug or a change.
An MVP exists to find out what users do once they have the product. If your plan is to watch the first users and adjust, the scope will move by design, and a fixed price charges you for every adjustment.
Platforms and providers change their requirements on their own schedule. Since 28 April 2026, Apple requires App Store uploads to be built with Xcode 26 or later (Apple upcoming requirements). From 31 August 2026, Google Play requires new apps and updates to target Android 16, API level 36 (Android Developers). Payment providers and AI services change their APIs too. On a long fixed-price project, each of these becomes a change request.
Ask a fixed-price vendor how changes get priced. If the answer is vague, one of two things is likely: the price already carries a margin for unknowns that you can’t see, or the vendor will build the narrowest reading of the spec. Either way, you pay. A good fixed-price offer states the rule in writing. On our engagement models page the fixed-price scope is “agreed before work starts. Changes get a new estimate.”
When all three are locked and something goes wrong, quality is the only thing left to give: fewer tests, skipped reviews, shortcuts in the code that you pay for after launch. If your date can’t move because of a launch or an investor meeting, keep the scope flexible instead.
Fixed prices cluster around small, short pieces of work. 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, a median midpoint of $13,125 and an upper timeline of 8 weeks. The 18 that state a price but no billing model start at $25,000, sit at a $61,250 midpoint and quote up to 13.5 weeks (Rocketech MVP Price Index 2026). The longer the work runs, the more the scope moves before the end.
| Your situation | What goes wrong on a fixed price | What fits better |
|---|---|---|
| The scope is unclear today | Gaps become disputes over bugs and changes | A short paid discovery step, then a fixed price for a scope you can now describe |
| You will learn from users as you build | Every adjustment is a change request | Time and materials with a monthly cap |
| The date is fixed, the scope isn’t | Quality gets cut to hit the date | A fixed budget and date, with the scope ordered by priority |
| The backlog will run for months | Each new piece needs a new quote | A dedicated team |
| The product depends on outside rules | Each rule change reopens the price | Hourly work for updates, agreed in advance |
The third row is how we ran Traza, a booking app for tattoo artists. The client had a budget under $20k and a launch date it had already promised. We worked as a dedicated team sized to the budget, in weekly cycles, and the client could change priorities every week. When the custom calendar grew bigger than planned, we cut it to a first version and moved push notifications and booking creation forward, because artists needed those more.
You can also move between models as the work changes. Hays started with us on a fixed price for a tool that formats CVs, then moved to a dedicated team as the tool grew into a larger system.
Sometimes you need one number for a board or an investor. Then shrink the unknowns before you sign. Our discovery sprint is a fixed $3,000 for one week: a written scope, the main user flow in a clickable prototype, a technical plan, a backlog with hours and a fixed price for the build. It counts toward the build if you build with us, and the files are yours either way.
After that, price one release at a time rather than the whole product. A small first release with written acceptance checks is the kind of work a fixed price was made for.
An estimate tells you how much of your scope is known, which is the question a fixed price depends on.
It takes about four minutes to see what your idea costs to build.
Because the price is set before the scope is really known. Every unclear requirement, user finding or platform change becomes a change request, and the vendor either charges more or builds the narrowest reading of the spec. The longer the project, the more of these pile up.
Not by default. A vendor who carries the risk of its own estimate prices that risk in. A fixed price is cheapest when the scope is small and clear, so there is little risk to price. For a moving scope, hours with a monthly cap let you pay for the work actually done instead of a price that has to cover the vendor’s risk.
Time and materials with a monthly cap, a dedicated team for a backlog that runs for months, or a fixed budget and date where the scope flexes by priority. A short paid discovery step can also turn an unclear project into one you can fix a price for.
Yes. Hays started with us on a fixed price for one tool and moved to a dedicated team as the tool grew into a larger system. Agree on the switch at a release boundary, so the finished part is accepted and paid before the new model starts.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.