"Can you give me a fixed price?" is a useful question when planning a project. The answer depends on how clearly the work can be defined. 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
With time-and-materials pricing, fees generally follow the work performed at the agreed rates. More time can mean a higher total, subject to any budget cap or approval rules. The agreement should explain how spending is tracked and when further work needs approval.
With a fixed price, the provider estimates the effort and uncertainty within a defined scope. Extra effort on that agreed work may sit with the provider, while scope changes or unmet assumptions may require a revised agreement. Read the actual terms to understand which risks each party accepts.
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. An estimate may depend on a payment provider having a sandbox, an export being available, or content arriving by an agreed date. Record those assumptions and the process for reviewing cost or timing if they change.
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 more discovery may help
A fixed build price may be premature when important questions remain open, for example:
- 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
One option is a separately scoped discovery phase to investigate the questions that matter most. Its fee, outputs, ownership, and permission to share those outputs with another provider should be agreed before it starts. Discovery may support a build estimate, or show that more investigation is needed; it does not automatically commit either party to development.
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.