Fixed-Price vs Time-and-Materials Contracts for Web Apps

When you commission a web application, the contract structure you agree with a supplier shapes how the project is managed, where risk sits and what happens when requirements change. The two most common models are fixed-price and time-and-materials, and neither is universally better. The right choice depends on how well the scope is defined, how much you expect it to evolve and where you want the financial risk to land.

Choose the model around uncertainty

How fixed-price contracts work

Under a fixed-price arrangement, the supplier reviews the requirements and quotes an agreed figure for the stated scope. The supplier will normally carry the additional effort needed to deliver that scope, subject to the contract, assumptions and exclusions. If the business changes the scope, the effect is handled through the agreed change-control process and may be priced separately.

The appeal is budget certainty — at least for the scope as written. The trade-off is that the supplier must price in contingency to cover the unknowns, and the scope itself must be defined precisely enough for both sides to agree what is and is not included. Vague requirements make fixed-price contracts risky for everyone.

How time-and-materials contracts work

Under a time-and-materials (T&M) arrangement, you pay for the actual hours or days the supplier's team spends, typically at agreed day rates. There is no single guaranteed total. Instead, the supplier provides estimates, and you control spend by approving work in stages, setting a not-to-exceed cap or managing a running budget.

The appeal is flexibility. If you discover partway through that a workflow needs to change, the team can adapt without renegotiating a contract. The trade-off is that the financial risk of underestimation sits with you, and you need a reliable way to track progress and spend.

Where uncertainty and financial risk sit

Both models ultimately pay for the same work. The difference is where uncertainty is priced and who bears the cost when estimates are wrong. Fixed-price bundles uncertainty into the quote. T&M makes it visible as it happens. Understanding which type of uncertainty your project carries — and how much of it you can tolerate — is the basis for choosing between them.

When fixed-price tends to work well

• Clearly defined scope. If you have a detailed specification, agreed acceptance criteria and little expectation that requirements will shift, fixed-price gives you a predictable cost.
• Procurement or compliance requirements. Some organisations are required by internal policy or funding rules to agree a fixed budget before work begins.
• Third-party or grant-funded projects. Where you must submit a firm budget in advance and cannot easily go back for more, a fixed-price quote supports that process.
• Small, bounded pieces of work. A specific integration, a single portal module or a well-understood data-migration task can be scoped tightly enough for fixed-price to be straightforward.

When time-and-materials tends to work well

• Evolving requirements. SaaS products, internal tools being built for the first time and systems where users will only know what they need once they start using a working version all involve significant discovery during build.
• Discovery and prototyping phases. When the purpose of the work is to figure out what to build, fixing a price for an unknown scope is contradictory. T&M allows the team to investigate, test assumptions and produce a proper specification for later phases.
• Ongoing development and support. Retainers, maintenance periods and iterative feature development are naturally suited to T&M because the workload varies month to month.
• Trusted, long-term supplier relationships. If you have worked with a team before and have confidence in their estimates and reporting, T&M carries less perceived risk.

Hybrid approaches

Many projects use a combination rather than picking one model for everything. A common pattern is a fixed-price discovery phase that produces a detailed specification, followed by a T&M build phase where the scope is now well enough understood to estimate accurately in sprints or milestones. Another pattern is a fixed-price core application with T&M for subsequent enhancements. The key is that each phase's contract structure matches what is actually known at that point.

Mistakes that cause problems under fixed-price

• Agreeing a fixed price on a vague specification. If the document does not define processes, roles, data fields, error handling and acceptance criteria in enough detail, both sides will interpret the scope differently. Disputes then become likely.
• Assuming "fixed price" means "no more spending". Change requests are standard under fixed-price contracts. If your requirements evolve — and they often do — you should expect additional costs. The question is whether the change-control process is clear and fairly priced, not whether changes will happen.
• Ignoring what is excluded. A fixed-price quote may deliberately exclude hosting, data migration, third-party licence costs, training or post-launch support. If you do not check what sits outside the quoted scope, your actual total will be higher than the headline figure.

Mistakes that cause problems under time-and-materials

• Starting without estimates or a budget frame. T&M does not mean open-ended. You still need the supplier to provide estimates for each stage or sprint, and you need an internal budget ceiling so you can make informed decisions as the project progresses.
• No visibility of hours spent. Under T&M, you should receive regular timesheets or sprint reports showing who did what and how many hours were consumed. If the supplier cannot or will not provide this, you are effectively working blind.
• Confusing flexibility with lack of accountability. T&M still requires defined acceptance criteria for each piece of work. The team should not be able to bill indefinitely without demonstrating completed, accepted deliverables.

What neither contract model solves

Neither contract structure compensates for poor requirements. If the specification does not accurately reflect your business processes, data flows and user roles, the delivered system will have problems regardless of how you pay for it. The contract model governs financial risk, not quality of outcome.

Both models also depend on a clear definition of "done". Without agreed acceptance criteria — specific, testable conditions that must be met before a piece of work is signed off — disputes arise under both fixed-price and T&M arrangements.

Contract controls to settle before signing

• Change-control process. Under fixed-price, how are changes requested, estimated, approved and documented? Is there a minimum charge per change request? How long does approval take?
• Reporting and transparency. Under T&M, what reports will you receive, how often and in what format? Can you see hours at a task level, not just a summary?
• Acceptance criteria. Regardless of model, are acceptance criteria written into the specification or agreed before each piece of work begins? Who decides whether they are met?
• Scope boundaries. Exactly what is included and what is explicitly excluded? Are hosting, infrastructure, third-party API costs, data migration and training addressed?
• Termination and handover. If the contract ends partway through — under either model — what do you receive in terms of source code, documentation, access credentials and data? This should be specified rather than left to goodwill.
• Contingency and caps. For fixed-price, is the quote itemised enough to understand where contingency sits? For T&M, is there a not-to-exceed cap or a milestone-based approval process that prevents runaway spend?

The contract model is a tool for managing risk and uncertainty, not a substitute for clear requirements, honest communication or proper acceptance processes. Choose the structure that matches what you actually know about the project at the point of signing, and make sure the surrounding terms — change control, reporting, acceptance and handover — are written down before work begins.

Commercial checks before signature

• Define what is included, excluded and assumed.
• Agree how progress and spend will be reported.
• Set the change-control or reprioritisation process.
• Link payment to evidence of progress rather than the passage of time alone.
• Make acceptance, ownership and handover obligations clear under either model.