Fixed price vs time and material for business software projects

A fixed-price contract pays for a defined result: a written scope, a price and a date. A time-and-material contract pays for effort: a rate per day or hour, billed as work happens, with scope allowed to move. For a business system whose workflow you can describe, fixed price is the better contract. For work nobody can define yet, time and material is the honest one. The mistake is using the wrong one and pretending it is the other.

What does each contract actually reward?

Contracts shape behaviour. Under a fixed price the vendor is rewarded for finishing, so they push to close scope, write things down and say no to drift. Under time and material the vendor is paid for hours, so nobody is rewarded for finishing early and every extra meeting is billable. Neither side is being dishonest. The incentives are simply different, and you should pick the ones that point at what you want.

When is fixed price the right choice?

Fixed price works when the work can be described. If you can walk a vendor through the workflow, name the screens and list the systems it must talk to, the scope can be written and priced. Most business software is like this. A hospital's front desk, a lab's sample flow, a distributor's order-to-invoice cycle: these are known processes with known exceptions. The vendor's job is to find the exceptions during discovery, and a good one will.

The condition is that the scope document is real. A two-page proposal is not a scope. A scope names every screen, every field, the data model, the integrations with direction of data, and a list of what is excluded. Our Define step exists to produce exactly that, and we do not quote a price until it is done.

When is time and material honest?

Some work cannot be scoped because the answer is not known yet. A proof of concept for an AI feature, where the question is whether the model is accurate enough on your documents. A migration from a database nobody has documentation for. A product team that will keep building for years and needs a steady pace, not a finish line. In these cases a fixed price would be a fiction, and a vendor who offers one is either padding heavily or planning to renegotiate.

Time and material needs its own discipline. A monthly budget cap, a weekly demo, and a written list of what was done for the hours billed. Without those, it is a retainer with no output.

Where does each one go wrong?

• Fixed price with a vague scope. The vendor fills gaps with the cheapest interpretation and you fill them with the most generous one. Every gap becomes a dispute.
• Fixed price with free changes. If the vendor absorbs changes to keep you happy, they cut corners elsewhere to stay whole. Changes should be priced, openly, as changes.
• Time and material with no cap. The bill is a surprise every month and there is no moment where anyone has to say the project is over.
• Time and material with no working builds. Hours are billed against slide decks and status reports. Insist on something you can click every week.
• Either contract with third parties out of scope. App store review, template approval on WhatsApp and certification by a regulator sit on someone else's clock. The contract should say what happens while you wait.

How do we handle change under a fixed price?

Change is not a failure of the scope. It is the normal result of people seeing working software and thinking harder. What matters is that change is visible and priced. On our projects a change request is a short written note: what changes, what it costs in days and rupees, and what it does to the date. You approve it or you do not. Nothing is absorbed quietly and nothing is hidden in the next invoice. Weekly working builds make this easier because changes are small and caught early.

Some vendors dislike change requests because they feel like bad news. We think a project with zero change requests is a project where nobody was paying attention.

A plain rule for choosing

1. If you can describe the finished system well enough for a stranger to test it, ask for a fixed price with a written scope.
2. If you cannot, ask for a short fixed-price discovery, then a fixed price for the build.
3. If the work is open-ended by nature, use time and material with a monthly cap, weekly demos and a written log.
4. Whatever you choose, ask what happens to schedule and money when a third party such as App Store review or WhatsApp template approval is slow.
5. Separate the build contract from the running contract. Hosting, backups and support are a different agreement with its own price.

Frequently asked questions

Is a fixed price always more expensive?

Not in total. A fixed price includes the vendor's allowance for risk, so the number can look higher than an hourly estimate. The hourly estimate, though, is not a price. It is a starting point that grows. On defined business systems the fixed price is usually the smaller final bill, and it is the only one you know in advance.

What if the vendor quotes a fixed price after one phone call?

Treat it as a range, not a commitment. Without a screen list, data model and integration list there is nothing to price, so the number is a guess with margin on top. Ask how the figure was built. If the answer is a rate multiplied by a guess at months, it is time and material wearing a fixed-price label.

Can a contract switch from one model to the other?

Yes, and it is a good pattern. Run a short fixed-price discovery to write the scope, then a fixed price for the build, then a monthly support agreement that behaves like time and material with a cap. Each phase has the contract that fits it. What does not work is switching in the middle of a build without a written reason.