Fixed-Price vs Time and Materials: How to Structure a Software Development Contract
Fixed price or time and materials? How to choose the right contract model for your software project, and the clauses on scope, ownership and handover that protect you either way.
Before a single line of code is written, one decision shapes how your software project will feel: the contract model, and the choice between fixed price vs time and materials is the biggest part of it. Choose well and both sides stay aligned. Choose badly and you get months of change-request arguments, a creeping budget, or a product nobody can maintain.
This guide explains when each model fits custom software, and lists the clauses worth negotiating whichever one you pick. It is written for founders and business owners commissioning software, not for lawyers; have a qualified lawyer review the final agreement.
Fixed price vs time and materials: the short answer
Use fixed price when the scope is small, well understood and unlikely to change. Use time and materials (T&M) when you are still discovering what to build, such as an MVP, an AI feature or a new internal system. For most real projects, a hybrid works best: a fixed-price discovery phase, then milestone-based delivery with a capped budget.
Fixed price: how it works and where it breaks
The agency quotes one price for a defined scope. You know the cost up front, and the vendor carries the estimation risk.
Where it works
- A marketing website or landing page with approved designs
- A WordPress theme or plugin with a clear feature list
- An integration between two systems whose APIs are documented
Where it breaks
- Unclear scope. Every gap in the brief becomes a “change request”, and every change request becomes a negotiation.
- Hidden padding. Vendors price in the uncertainty, so you often pay a risk premium for work that turns out simple.
- Corner-cutting. When the budget is fixed and the work runs long, quality is the only variable left to flex.
Time and materials: how it works and where it breaks
You pay for the hours actually spent, usually at an agreed rate. Scope can evolve, and you only pay for what is built.
Where it works
- MVPs and new products where learning from users changes the plan
- AI agents and RAG systems, where results depend on testing against your real data
- Long-running products with a continuous backlog
Where it breaks
- No natural ceiling. Without a cap or regular reporting, costs drift.
- Weak incentives. The vendor is paid for time, so you need transparency to confirm that time is well spent.
Side-by-side comparison
| Factor | Fixed price | Time and materials |
|---|---|---|
| Budget certainty | High, if scope holds | Lower, unless capped |
| Flexibility | Low; changes cost extra | High |
| Best for | Small, well-defined work | Evolving or exploratory work |
| Main risk | Scope disputes, rushed quality | Budget drift |
| Upfront effort | Detailed specification needed | A clear goal and priorities |
The hybrid model most teams should consider
- Paid discovery (fixed price). One to two weeks to define scope, user flows, risks and a technical plan. You keep the output even if you part ways.
- Milestone delivery (T&M with a cap). Work is split into short milestones with a demo at the end of each and a not-to-exceed budget.
- Review gates. After each milestone you can continue, change direction or stop.
This pairs the predictability of fixed price with the flexibility of T&M. A good starting point is a written brief; our guide to writing a software project brief shows what to include, and our MVP development guide explains how to phase a first release.
Clauses to negotiate under any model
1. Ownership of the code
The contract should state clearly who owns the source code and other deliverables, and when ownership transfers (typically on payment). Copyright rules for commissioned work vary by country, so do not assume you own it by default; get it in writing.
2. Access to repositories and infrastructure
Code should live in a repository under your account, with hosting, domains and third-party services registered to your company. This single habit removes most lock-in risk.
3. Acceptance criteria
Define what “done” means per milestone: features working, tests passing, documentation delivered. Vague acceptance is the root of most payment disputes.
4. Change process
Agree how changes are estimated, approved and invoiced before they happen.
5. Warranty and support
Ask for a bug-fix period after launch, then a clear arrangement for ongoing work. Our article on software maintenance cost covers what to budget.
6. Documentation and handover
Setup instructions, environment variables, deployment steps and architecture notes should be part of the deliverable, not an optional extra.
7. Confidentiality and data protection
If the project touches customer data, specify how it is handled, where it is stored and who can access it.
Why large projects go wrong: a reality check
A well-known McKinsey and University of Oxford study of more than 5,400 IT projects found that large projects (initial budgets above $15 million) ran on average 45 percent over budget and 7 percent over schedule, while delivering 56 percent less value than predicted (McKinsey). Small business projects are a different scale, but the lessons carry over: unclear requirements, big-bang delivery and little visibility cause overruns. Short milestones and regular demos are the cheapest insurance.
How to decide in five minutes
- Can you list every feature and screen today? Fixed price may fit.
- Will user feedback change the plan? T&M or hybrid.
- Is the budget a hard limit? Use milestones with a cap.
- Do you need the product to keep evolving after launch? Plan a retainer.
Frequently asked questions
Is fixed price always cheaper than time and materials?
No. It is more predictable, not necessarily cheaper. Vendors often include a buffer for uncertainty, and changes mid-project are usually billed at a premium.
Can I switch from T&M to fixed price later?
Yes. Many teams start with T&M to discover the scope, then fix the price for a well-defined next phase.
What should a software estimate include?
Scope assumptions, what is excluded, a breakdown by milestone, team roles, timeline, and how changes are handled. See our custom software cost guide for typical ranges.
Do I need a lawyer?
For anything beyond a small job, yes. This article is general information, not legal advice.
Plan your project with a clear contract
At Shkulaku we build custom software, SaaS products, AI agents and integrations from Tirana, Albania, with transparent scope, milestone demos and code that belongs to you. If you are weighing how to structure your project, request a consultation and we will help you choose a model and outline a realistic plan.
I take on a small number of projects at a time. Tell me what you are building and I will tell you honestly whether I am the right person for it.
Get in touch →
1 comment