"Can you give me a fixed price?" is the most common question we get, and the answer is almost always yes. But it is worth being precise about what you are buying, because a fixed price is not a discount. It is a transfer of risk, and someone is paying for it either way.
Where the risk actually sits
On a time-and-materials contract, you carry the risk. If the work takes 30% longer than anyone expected, you pay 30% more. In exchange, you pay nothing for uncertainty that never materialises.
On a fixed-price contract, we carry it. If the work runs long, that is our problem. In exchange, the number includes a buffer for the things that might go wrong — because a studio that does not price in that buffer goes out of business on the first project that surprises them.
Neither model is dishonest. What is dishonest is a fixed price quoted against a scope nobody wrote down.
What makes a fixed price safe to sign
Three things, in order of importance:
A written scope. Not a feature list — a description of what the software does, who uses it, and what it connects to. Ambiguity in a scope document becomes a dispute in month three.
Stated assumptions. Every estimate rests on things we believe but have not verified: that your payment provider has a sandbox, that the data export exists, that content will arrive by a certain week. We write those down. If one turns out to be wrong, we both know immediately which number moves and why.
A change process. New ideas during a build are a good sign, not a problem. The problem is discovering their cost on the final invoice. Anything outside scope gets a price and a date before anyone starts on it, and you decide.
When we will not quote fixed
We say no to a fixed price when the unknowns are large enough that the honest buffer would be insulting. That usually means:
- Integrating with a system nobody can document or access yet
- Research-shaped work where the outcome is genuinely unknown
- Products where the requirements are still being discovered by talking to users
In those cases we propose a small paid discovery phase — a fixed price on its own — that ends with a scope solid enough to quote against. You can take that scope to anyone, including a studio that is not us. That is the point of paying for it, and we write it to be worth the money on its own.
The number is not the deliverable
The most useful thing a good estimate gives you is not the total. It is the breakdown. When you can see that authentication is a fifth of the budget, you can ask whether you need custom auth at all. When you can see the admin panel costs as much as the customer-facing app, you can decide whether a spreadsheet would do for six months.
Estimates are a design tool. Treat them as one.