Every large software project is bought under one of two contract models. Under time and materials you pay for effort: people, hours, days. Under a fixed price you pay for a result: a defined scope, delivered and accepted. The choice decides who carries the risk of the unknown, how much management the buyer has to do, and what a delay actually costs. This guide explains both models without a sales filter, shows where each one genuinely fits, and ends with the conditions under which a fixed price works on a large project rather than turning into a dispute.
What the two models really sell
A time-and-materials contract sells capacity. The vendor commits to providing people with certain skills at an agreed rate, and the buyer directs their work. An estimate is usually attached, but it is explicitly not a price. If the project takes longer, the invoice grows. If the buyer changes direction, the invoice grows. If the vendor's team is less productive than hoped, the invoice grows. The model is honest about one thing: the vendor does not promise an outcome, only effort.
A fixed-price contract sells an outcome. The vendor commits to delivering a defined scope for an agreed amount, by an agreed method of acceptance. The buyer's risk is capped at the price, plus whatever the buyer's own obligations cost. The vendor's risk is that the scope was underestimated. Because of that risk, a fixed price is only possible when the scope can be written down precisely enough to be priced and tested. That constraint is not a weakness of the model. It is the reason the model works: it forces both sides to agree on what "done" means before money is spent.
Who carries which risk
The clearest way to compare the models is to list the risks on a large project and ask who pays when each one materialises.
| Risk | Time and materials | Fixed price |
|---|---|---|
| The work takes longer than estimated | Buyer pays the extra hours | Vendor absorbs it |
| The scope was unclear at the start | Buyer pays for the clarification work | Both sides must clarify before pricing, or the vendor absorbs it |
| The buyer changes the requirements | Buyer pays, usually without friction | Change is priced and agreed in writing before it is built |
| The vendor's team is slow or inexperienced | Buyer pays | Vendor absorbs it |
| Quality problems surface late | Buyer pays for the rework | Vendor delivers to the acceptance criteria at its own cost |
| The project is cancelled midway | Buyer pays for hours used | Depends on the contract's milestone terms |
Under time and materials, nearly every risk lands on the buyer, and the buyer has to compensate by managing closely: tracking velocity, reviewing timesheets, attending stand-ups, and escalating when the burn rate looks wrong. Under a fixed price, the vendor has a financial reason to be efficient and to say no to vague requirements, and the buyer's management load drops to confirming scope and accepting deliverables.
Where time and materials genuinely fits
Time and materials is the right model when the work cannot be specified in advance. Exploratory research, an open-ended data-science investigation, or the early phase of a product nobody has built before are legitimate cases. It is also reasonable when the buyer wants to direct the work day to day and has the senior staff to do it well. In that situation the buyer is effectively renting a team and acting as its manager, and an hourly rate reflects that honestly.
The problems begin when time and materials is used for work that could have been specified. Then the model simply moves risk to the party that is least able to control it. A buyer who cannot see inside the vendor's process is asked to pay for whatever that process consumes. Many "failed" large projects are not failures of engineering at all; they are the predictable result of buying an unspecified outcome by the hour.
Where a fixed price genuinely fits
A fixed price fits when three conditions hold:
- The scope can be written down. Not every detail, but every outcome: what should exist when the work is done, and how both sides will know. A guide on how to write a scope for a fixed-price quote covers the format.
- Acceptance can be tested. For software this means tests that pass, behaviour that can be demonstrated, and documentation that exists. A fixed price with subjective acceptance is a negotiation waiting to happen.
- The vendor controls its own production method. A vendor that depends on hiring people it does not yet have cannot responsibly fix a price. A vendor with a repeatable production system can.
When those hold, a fixed price is strictly better for the buyer: known cost, known deliverable, less management, and a vendor that is motivated to finish rather than to continue.
Why large projects are usually bought by the hour anyway
If a fixed price is better for the buyer, why are most large projects still bought as time and materials? Three reasons, none of them good for the buyer.
First, specification is work, and many buyers postpone it. Writing down what should exist is harder than describing a vision in a meeting, so the project starts before the scope is clear, and the only model that can start without a scope is hourly.
Second, most vendors cannot carry the risk. A conventional team's output is uncertain enough that fixing a price on a large scope would be a gamble. Vendors therefore add large contingencies to fixed quotes, which makes them look expensive next to a time-and-materials estimate that is quietly open-ended.
Third, hourly billing is comfortable for the vendor. It rewards time spent. The commercial incentive is to continue, not to finish.
A buyer who recognises these reasons can address all three: do the specification work, choose a vendor whose production method is repeatable enough to price, and compare a fixed quote with the realistic end cost of an hourly engagement, not with its opening estimate.
How to make a fixed price work on a large project
A fixed price works when the contract is structured to remove ambiguity before it becomes a dispute. The following structure does that.
Fix the scope before the price
Insist on a written scope description before any quote. If a vendor offers a fixed price without one, the price contains either a large contingency or a future argument. The scope description should state outcomes, boundaries (what is explicitly excluded), acceptance criteria, and the inputs the buyer must provide.
Start with a bounded, real piece of work
A large scope is hard to price in one step, for both sides. The reliable approach is to take a real, bounded piece of the plan, fix its price, deliver it, and let the result calibrate the quote for the rest. This is not a demo or a proof of concept; it is production work that stays in the codebase. It shows the buyer the vendor's actual output on the buyer's own code, and it shows the vendor the buyer's codebase, review process and decision speed. Our own engagement model is built on exactly this step: a trial build at a fixed 9,900 euros, delivered within 72 hours of written scope confirmation, with the price deducted in full from the main project.
Define change control in writing
Scope will change on any large project. The question is only whether changes are priced before or after they are built. Agree that every change is described in writing, its effect on price and delivery is stated, and work on it begins only after written confirmation. Buyers sometimes fear this as bureaucracy; in practice it is a few paragraphs per change, and it keeps the price fixed in fact, not only on paper.
Tie acceptance to tests and documentation
Acceptance criteria should be things a machine or a reviewer can verify: the test suite passes, the documented behaviours work, the documentation describes the delivered system. Avoid criteria like "performs well" or "is user-friendly" unless they are given measurable definitions.
Receive the code at milestones, not only at the end
Delivery should arrive in stages: a written progress report every day, and at every milestone a working preview, a test report and the code as a package the buyer can run and audit. Staged delivery makes progress visible without status meetings, makes acceptance incremental, and removes the risk of a last-day surprise. It also settles the intellectual-property question early, which a separate guide on code ownership when outsourcing treats in detail.
Agree who is accountable for the architecture
On a fixed-price project, someone must own the architecture and the specification, because they are what the price is based on. Ask who that person is at the vendor and whether they write the specification themselves. A vendor that assigns architecture to whoever is available cannot hold a fixed price consistently.
The comparison in one paragraph
Time and materials is appropriate when the work cannot be specified or when the buyer wants to manage a rented team. For a large project with outcomes that can be written down and tested, a fixed price gives the buyer a known cost, a motivated vendor and far less management, provided the scope is fixed first, changes are controlled in writing, acceptance is testable and delivery arrives in verifiable stages. The way to find out whether a particular vendor can hold a fixed price is to buy a small, real piece of the plan from them at a fixed price and judge the result.
What this looks like with Ship in Hours
AIPOS OÜ sells fixed prices only. The engagement has two steps. Step one is a trial build: a genuine part of your development plan, confirmed in writing, delivered within 72 hours as tested and documented code with full intellectual property, for a fixed 9,900 euros. Step two is the main project: the whole confirmed scope at one fixed price, quoted in writing after the trial, with the trial price deducted in full. Every project is built on a software architecture and technical specification designed in-house by AIPOS OÜ — reviewed and agreed with you in writing before development begins. Every change is tested and reviewed by an independent review agent before it is committed in AIPOS OÜ's own environment; you receive a progress report every day and the code as a tested package at every milestone. All communication is written. The large software projects page describes the fit in more detail; the request form is the first step.
Frequently asked questions
Is a fixed price always more expensive than time and materials?
No. A fixed quote is compared, unfairly, with an hourly estimate, which is not a price. Compare it instead with the realistic end cost of an hourly engagement, including overruns, change requests and the buyer's own management time. A vendor with a repeatable production method can fix a price without a large contingency, which is why the vendor's method matters as much as the model.
What happens to a fixed price when the requirements change?
Each change is described in writing, its effect on price and delivery is stated, and it is built only after written confirmation. The original price stays fixed for the original scope. This is the normal mechanism, not an exception, and it is what keeps a fixed price fixed on a project that lasts weeks.
Can a very large project be fixed-priced in one quote?
It can, but it is better to start with a bounded, real piece of the scope at a fixed price and let the result calibrate the quote for the rest. Both sides learn what the specification looks like in practice, and the main quote is then based on evidence rather than on assumptions.
Who owns the code under a fixed-price contract?
That depends on the contract, which is why it must be explicit. Under our terms, full intellectual property in the deliverables is transferred to the client; the platform and methodology used to produce the work stay with us. Delivery takes the form of tested code packages at agreed milestones, in full after final payment.
How is acceptance decided on a fixed-price project?
By criteria agreed in the written scope: tests that pass, behaviours that can be demonstrated, documentation that exists. Subjective criteria should be avoided or given measurable definitions before the price is agreed.
Can we switch from time and materials to a fixed price mid-project?
Yes, and it is a common moment to do so, usually when the remaining scope has become clear. Write down the remaining scope with acceptance criteria, obtain a fixed quote for it, and move the engagement onto the new basis. Starting that transition with a bounded trial build on the actual codebase is the lowest-risk way to do it.