Mehedi Hasan · Senior Software Engineer Fixed Scope vs Time and Materials Software Development: How to Choose
Fixed scope or time and materials? Where each contract model actually puts the risk, what it costs you, and how to pick one before you sign an SOW.
The fixed-scope versus time-and-materials debate is usually framed as a pricing question. It is not. It is a question about who carries the risk of being wrong about the requirements — and that answer should drive which model you sign.
Under fixed scope, the agency carries estimation risk: if the build takes 40% longer than they thought, that is their margin. Under time and materials, you carry it: every hour of their learning curve, rework, and discovery lands on your invoice. Neither is inherently fairer. They suit different situations.
What each model actually commits to
Fixed scope locks a defined deliverable to a defined price and date. The Statement of Work names the features, the acceptance criteria, and the exclusions. Changes go through a written change order with its own price.
Time and materials bills for hours worked at agreed rates, usually with a monthly cap or a not-to-exceed ceiling. Scope stays open; direction can change sprint to sprint.
The critical detail people miss: fixed scope does not mean fixed effort, it means fixed scope. The protection you are buying is the boundary around the work, not a guarantee about how hard it was.
| Fixed scope | Time and materials | |
|---|---|---|
| Who carries estimation risk | The agency | You |
| Budget predictability | High — the number is the number | Low to moderate — depends on the cap |
| Cost of a mid-build direction change | A change order, priced and signed | Absorbed into the next sprint |
| Discovery effort before signing | High — requirements must be specific | Low — you can start vague |
| Typical padding in the price | 15–30% contingency built in | None, but no ceiling either |
| What the agency optimizes for | Shipping the named scope efficiently | Staying engaged |
That last row is the honest one. Every incentive structure has a failure mode. Fixed scope pushes an agency toward delivering exactly what is written and no more — so a vague SOW gets you a technically compliant, useless build. Time and materials pushes toward longevity — so a project with no forcing function can drift for quarters.
When fixed scope is the right call
Fixed scope works when the outcome is knowable in advance. That is more often than founders assume:
- You can describe done. A B2B customer portal that syncs orders with NetSuite, a React Native inventory count app, an internal dashboard with named metrics — these have testable acceptance criteria before anyone writes code.
- The budget is a hard constraint. If you raised a specific round and the build has to fit inside it, an open-ended hourly meter is a runway risk, not a flexibility benefit.
- You are buying a replacement for a known process. Anything replacing a spreadsheet or a manual workflow already has its requirements documented — in the spreadsheet.
- You need to hold someone accountable to a date. A fixed date with a signed scope gives you a real conversation when it slips. An hourly contract gives you a longer invoice.
The prerequisite is honest discovery. A fixed-scope SOW written from a two-paragraph brief is a fixed price on a guess, and it will end in change orders or a fight. Expect to pay for a short, separate discovery phase — one to three weeks — that produces the spec the fixed-price build is quoted against. Paying for discovery separately is a feature, not a markup: it is what makes the fixed number trustworthy.
When time and materials is the right call
- The requirements genuinely cannot be known yet. Pre-product-market-fit experimentation, or research work where the next step depends on what the last one found.
- You are augmenting your own team. If you have engineers and a technical lead directing the work, you are buying capacity, not an outcome. Fixed scope adds contract overhead for no benefit.
- The work is open-ended maintenance. Support, incident response, and iterative improvement have no “done” to fix a scope around.
- The scope will demonstrably change every few weeks. Change orders every sprint is worse than just billing hours.
How do the two models compare side by side?
| Factor | Fixed scope | Time and materials |
|---|---|---|
| Budget | One number up front | Varies with hours; needs a buffer or a cap |
| Scope | Written, with exclusions; changes via change orders | Flexible; features added or dropped week to week |
| Risk | Delivery risk sits with the vendor | Burn risk sits with you |
| Your involvement | Heavy in discovery and sign-off, lighter after | Ongoing prioritisation and sprint decisions |
| Hidden costs | Under-scoped IAM, monitoring or polish | Hours with nobody saying no; experiments that never end |
| Best for | Portals, internal tools, mobile apps, landing zones | AI research, unvalidated workflows, unknown legacy APIs |
Which model fits SaaS, mobile, AI and DevOps work?
Fixed scope fits SaaS shells, distributor portals, field apps and bounded Terraform setups when the integrations (NetSuite, Business Central, Shopify, Stripe, HubSpot) already exist and work today. Time and materials — or a short paid discovery followed by a fixed build — fits open-ended RAG or agent work, evaluation metrics that are still being invented, and workflows users have not validated yet. Match the model to the uncertainty, not to the vendor’s preference.
The hybrid most builds actually want
In practice the best structure for a first build is usually neither pure model:
- Paid discovery, fixed price, one to three weeks. Output is a spec, acceptance criteria, architecture, and a fixed quote for the build.
- Fixed-scope build against that spec, with a named change-order process and price.
- Time-and-materials retainer afterwards for iteration and support, once the thing exists and you are learning from real users.
This puts the fixed price where requirements are knowable and the hourly meter where they are not.
What to check in the contract either way
Whichever model you sign, these clauses decide how it actually goes:
- Acceptance criteria per deliverable, written as things that can be demonstrated, not adjectives. “Order sync completes within 5 minutes and surfaces failures in the admin log” — not “reliable sync”.
- The exclusions list. In fixed scope this matters more than the inclusions. Data migration, third-party licence costs, and content are the three most common surprise exclusions.
- Change-order mechanics — who can request, who prices, how long a quote is valid, and what happens to the timeline.
- IP assignment on payment, and a repo you own from day one rather than at handoff.
- Handoff definition. Source code, infrastructure as code, environment variables documented, and a runbook. “We’ll hand over the code” is not a handoff.
- Under T&M specifically: a not-to-exceed ceiling, weekly burn reporting, and the right to stop at any sprint boundary.
FAQ
Can I switch from time and materials to fixed scope mid-project?
Yes, once requirements stabilise: run a short re-discovery, rewrite the acceptance criteria and sign a new fixed SOW with a freeze date and an exclusions list. Switching without re-scoping is how disputes start.
What is the biggest contract mistake founders make?
Pricing screens and forgetting non-functional work: IAM, CI/CD, monitoring, cost alerts and — for AI features — datasets, evaluation harnesses and versioning. Put latency and uptime targets in the SOW or they become open-ended hourly work.
When should I avoid fixed scope entirely?
When the stack is experimental, user research is still choosing between core flows, or the compliance rules for AI output are undefined. Start with capped discovery, write down what you learned, then fix the price on the proven slice.
The short version
Choose fixed scope when you can describe done and the budget is real. Choose time and materials when you are buying capacity or exploring. Do not choose fixed scope to avoid doing discovery — that just moves the cost to change orders, and moves the argument to month three.
Work with us
We build under fixed-scope SOWs, and we run a paid discovery phase first so the number we quote is one we can hold. If you want to see how we would scope your build before committing to it, get in touch.
Need this built? Our team does fixed-scope how fixed-scope works — scoped, priced and delivered in weeks.