A fixed price works when both sides can describe the finished work in writing before it starts. It fails when they can't. Most disputes over fixed-price software come from one side believing the scope was clear and the other side believing it wasn't.
What a fixed price actually does
A fixed price moves risk from you to the developer. You know the cost. The developer carries the chance that the work takes longer than planned.
Developers know this, so they respond in one of three ways. They add padding to the quote. They hold you tightly to the written scope and charge for every change. Or they cut corners to protect their margin. Each is a reasonable reaction to carrying risk, and each can cost you more than the quote saved.
When it works
Fixed price suits work that is small, well understood and easy to test.
- The scope fits on a few pages. A marketing site, a data import, a connection to a payment service or a single report are all examples.
- Someone has done it before. The developer has built close to the same thing, so the estimate rests on experience and not on a guess.
- You can say how you will accept it. "The export produces these columns for these records" is a test. "The dashboard feels fast" is not.
- You won't change your mind halfway. If requirements move, a fixed price turns into a series of change orders.
When these hold, a fixed price gives you a firm budget and a clear end date, and the developer has every reason to finish.
When it doesn't
Fixed price breaks down when the size of the job is unknown. Three cases come up often.
New products. Early on, you learn what to build by building it. A fixed price made before that learning forces you to guess, and the guess is usually wrong. Then every correction becomes a negotiation.
Work on existing code. Nobody can price a repair without reading the code. If the software keeps breaking, the cause may be a missing test, a poor database design or a server set up by hand. A quote written without looking at it is either padded heavily or too low, and a quote that is too low gets paid for later, with shortcuts.
Projects that are already stuck. If a project is late and over budget, the original scope is probably out of date. Fixing the price to a document nobody trusts leads to arguments about what "done" meant.
A way through for stuck projects
You can still cap your spending without pretending the unknowns are known. Split the work in two.
- Pay a fixed price for an assessment. The developer reads the code, lists what is wrong and writes down what it would take to fix. The deliverable is a document you own, so you can act on it with any team.
- Then price the repair in phases. Each phase has its own scope, test and price, or a time-and-materials budget with a ceiling the developer can't pass without your approval.
This keeps the useful part of a fixed price, which is a known limit on what you spend, and avoids the part that fails, which is a promise about something no one has yet measured.
Questions to ask before you sign
- What exactly will I have on the delivery date, and how will we check it?
- What happens when the work turns out to be larger than you estimated?
- How are changes priced, and who decides whether something is a change?
- Do I own the code, and can another developer take it over?
- What did you assume about the existing system, and how did you check it?
A developer who answers these plainly is worth more than one who offers the lowest number. Vague answers to the second and fifth questions are the usual sign that the price will move later.
If your project is stuck
If you have spent money on software that still doesn't ship or keeps breaking, the first step is an honest look at what you have, not a new fixed-price quote. Moosara is a software rescue practice, and you can talk directly with Robert Lara III about your situation and what fixing it would involve.