What it is: one agreed price for one agreed scope, set before work starts. If the work takes longer, the developer pays for it. If you want more, you pay for a change.
When it works: small, clearly defined jobs where you can write down exactly what "done" looks like, such as a landing page, one integration or a feature with a written specification.
The catch: the price is only fixed for the scope on paper. Early software estimates can be off by as much as four times in either direction, so developers pad fixed quotes for that risk, and every change after signing becomes a change request.
If your product will keep changing: time and materials fixes the hourly rate instead of the scope, and a development subscription fixes the monthly cost instead.
Fixed Price Software Development at a Glance
| What matters | Fixed price | Time and materials | Monthly subscription |
|---|---|---|---|
| What is fixed | The total, for a set scope | The hourly or daily rate | The monthly fee |
| Who carries the risk of overruns | The developer | You | The developer, one request at a time |
| Changing your mind | A change request, often a new price | Easy, it just adds hours | Another request in the queue |
| What you need before starting | A complete, written scope | A rough plan and a budget | Your first request |
| Best for | A small job that will not change | Work that cannot be estimated up front | A product that keeps changing |
| Main risk | Paying for padding, or arguing about scope | A total that keeps growing | Paying in months with little to send |
Before you sign a fixed price deal, check these four things:
- Check 1, "Is the scope written down screen by screen?" If you cannot describe every screen and rule, the developer is guessing, and the guess is priced in.
- Check 2, "How is a change priced?" Get the change process and the rate for extra work in writing before you sign.
- Check 3, "What counts as done?" Acceptance criteria for each milestone stop arguments about whether a payment is due.
- Check 4, "Who owns the code at each payment?" The code should be in your company's accounts from the first day, with the assignment in the contract.
Want a fixed monthly cost instead of a fixed scope?
A senior developer on subscription: $2,995 a month, as many requests as you like, each shipped within 2 business days, and your money back if the first 14 days don’t prove it.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
This guide is for founders deciding how to pay for software work. For who to buy it from, see agency vs freelancer and how to choose a software development company.
What Is Fixed Price Software Development?
In a fixed price project, you and the developer agree on three things before any code is written: what will be built, what it will cost in total and, usually, when it will be ready. You pay that price whether the work takes the developer half the time they planned or twice as long.
The US federal rules for government buying describe the same deal in plain terms. A firm fixed price contract has "a price that is not subject to any adjustment on the basis of the contractor's cost experience," and it places on the contractor "maximum risk and full responsibility for all costs and resulting profit or loss."
That risk is why a fixed price is rarely the cheapest price. A developer who could lose money on an overrun adds a buffer to the estimate. SmartDev, a software outsourcing firm, says suppliers pad fixed bids by 20% to 40% when requirements are unclear or poorly documented. The clearer your scope, the smaller the buffer needs to be.
Payment is usually split into milestones, such as a deposit, a payment when the designs are approved and the rest when the finished work passes the agreed acceptance tests.
How a Fixed Price Project Works
- 1
1. Discovery and specification
The developer works out exactly what you need: screens, user roles, rules, integrations. Some charge for this as a small fixed price project of its own. The written specification it produces becomes the scope.
- 2
2. Estimate and quote
They estimate the work, add a buffer for risk and give you one price, a timeline and a payment schedule.
- 3
3. Contract
The specification, milestones, acceptance criteria and change process go into the contract. This is where most of the protection for both sides lives.
- 4
4. Build to milestones
The developer builds toward each milestone. You review the work at each one and pay when it meets the acceptance criteria.
- 5
5. Change requests
Anything you want that is not in the specification is written up as a change, priced and approved before it is built. Expect several.
- 6
6. Acceptance and handover
The finished work is tested against the acceptance criteria, the final payment is made and the code is handed over. A good contract includes a period after this when bugs are fixed at no charge.
Pros and Cons of Fixed Price Development
What a fixed price gives you
- A known total for budgeting and fundraising
- The developer carries the risk of the work taking longer
- Little day-to-day management on your side
- A clear list of what you are getting and when
What it costs you
- A risk buffer priced into the quote
- Weeks of specification before anything is built
- Every change becomes a negotiation and a new price
- The developer gains from doing the minimum that meets the spec
- Disputes over whether something was in scope
The last point matters more than it looks. On a fixed price, every hour the developer saves is profit, and every extra hour is a loss. Most developers are honest about it, but the incentive pushes toward building exactly what the document says, even when you both learn halfway through that something else would work better.
Why Fixed Price Estimates Go Wrong
Software is hard to estimate before it is designed. Steve McConnell's "cone of uncertainty" puts estimates made at the idea stage anywhere from a quarter of the real effort to four times it. The range narrows only as decisions get made: once the product is defined, then once the requirements are written, then once the design is done.
The McKinsey and Oxford study looked at large projects, each with a starting budget over $15 million, so the exact figures do not carry over to a small build. The pattern does. Budgets and timelines set before the work is understood tend to be wrong, and the gap usually shows up as cost, delay or features quietly cut.
A fixed price does not remove that uncertainty. It moves it. Either the developer absorbs the overrun, or the quote was padded enough to cover it, or the scope gets argued down until it fits the price.
Fixed Price vs Time and Materials
With time and materials, you pay for the hours actually worked at agreed rates, plus any direct costs. It is the usual alternative when the work cannot be pinned down in advance. The federal rules say a time and materials contract "may be used only when it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work or to anticipate costs with any reasonable degree of confidence."
For a founder, the trade is simple. Fixed price buys certainty about the total and costs you flexibility. Time and materials buys flexibility and costs you certainty about the total. Upwork puts typical rates for software developers at $10 to $100 an hour, and most firms listed on Clutch charge $24 to $49 an hour, so on time and materials the size of the bill depends on how many hours the work turns out to need.
Many teams blend the two:
- Fixed price discovery, then time and materials. A small fixed price project writes the specification, and the build is billed by the hour once everyone understands it.
- Fixed price per milestone. Each short phase gets its own price, agreed once the previous one is done and the next is clear.
- Time and materials with a cap. You pay by the hour up to an agreed ceiling, and anything over it needs your approval.
The Agile Manifesto, written by a group of software developers in 2001, values "customer collaboration over contract negotiation." That is the root of the tension. A fully fixed scope and price for a whole product assumes you know everything up front, which is rarely true for a product that is still finding its customers.
When to Choose Fixed Price
A landing page, one integration, a feature with a written spec, or a first version whose screens are already designed. You get a known total and little to manage.
You can change direction freely, but someone on your side needs to track progress and the budget every week.
Fix the price of discovery or of each milestone, or cap the hours, so the risk is shared.
A flat monthly fee for requests worked one at a time. A change is another request rather than another quote. See developer as a service.
If you are not sure your scope is settled, it probably is not. Most first versions change once real customers use them. Our guide to MVP development services covers what a first version should include, and SaaS development cost covers the work after launch that most budgets leave out.
What to Put in a Fixed Price Contract
- The full specification, attached to the contract, so "in scope" has one meaning.
- Acceptance criteria for each milestone, and how many days you have to test before it counts as accepted.
- A change process: how you request a change, how it is priced, and the rate for extra work.
- A payment schedule tied to accepted milestones, not to dates.
- A bug fix period after delivery, with what counts as a bug rather than a change.
- A written assignment of all code and work to your company, with the code kept in your company's accounts.
- What happens if the work is late, and how either side can end the contract.
Red Flags in a Fixed Price Quote
- A price with no questions. A developer who quotes without asking about your screens, users and integrations is guessing, and the quote will be padded or the scope argued later.
- A low price and a vague scope. The gap is usually made up in change requests.
- No change process. If the contract does not say how changes are priced, every one becomes a negotiation.
- Payment by date, not by accepted work. You end up paying for milestones that do not work yet.
- The code stays in their accounts until the final payment. If the relationship ends early, you may not get it back.
How StackTie Fits
StackTie is a development subscription, not a fixed price project. The monthly fee is fixed, but the scope is not: you send requests, they are worked one at a time, and each one comes back in days as a pull request with a plain-English summary of what changed. There are no estimates, no change requests and no hourly billing, so changing your mind means sending a different request. One senior developer, Michael, leads every build. Big projects are split into smaller requests that ship one after another. Everything we build belongs to your company and lives in your own accounts, and there is a money-back guarantee if it is not a fit. It is not the right choice if you need native iOS or Android apps or a whole team working in parallel, and a fixed price may suit you better for one small, settled job. The price and what is included are on the homepage.
