On a time and material (T&M) contract you pay for the hours actually spent, at an agreed hourly rate. You set the priorities and can change them as you learn, so the scope stays open. The price of that flexibility is that the budget risk moves to your side. A monthly cap, a goal for every sprint and a weekly hours report give you most of that control back.
This guide explains how the bill is built, why even governments put a ceiling on T&M, five controls that keep it in check, and when it’s the wrong choice. The other two parts of this series cover when fixed price fails and when a fixed price works and how to set one up.
Three numbers make up the bill. The rate is an hourly price per person, sometimes one rate for everyone and sometimes one per role. The hours are what the team logs against tasks. The invoice, usually monthly, is hours times rate, plus any costs you approved in advance, such as a paid service the product needs.
Who runs the work depends on the deal. In a T&M project with us, we run the project, and you set the priorities and can change them as you learn. Our rate is $39-55 an hour. The same rate applies to staff augmentation, but that model works differently: our people join your team, work in your process and report to your lead. If you have a lead who can run developers, augmentation fits. If you don’t, a T&M project where the vendor runs the work fits better.
Here is the arithmetic for illustration only. If two people log 120 hours each in a month, that’s 240 hours, and at $39-55 an hour the invoice comes to $9,360-13,200. Your real hours depend on the work.
The US government is rewriting its Federal Acquisition Regulation, and its new Part 16 (model text from September 2025, revised in 2026) is strict about T&M. Agencies may use it only when “it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work.” The contracting officer must first record that no other contract type fits, and the contract “must include a ceiling price that the contractor exceeds at its own risk” (FAR Part 16, Revolutionary FAR Overhaul text).
You don’t need the paperwork, but the two ideas carry over well. Use T&M when the work can’t be estimated well yet. And give it a ceiling anyway.
| Control | What it protects | How to set it up |
|---|---|---|
| A cap per month or per phase | The budget | The vendor can’t pass it without your written OK. Set it from the top of your estimated range |
| A goal and a demo every sprint | Value for the hours | Each sprint ends with working software you can click, not a status report |
| A weekly hours report | Visibility | Hours per task and per person, with new work and fixes shown apart |
| One ordered backlog | Priorities | One product owner orders it, and the team works from the top |
| An early warning | Surprises | The vendor tells you when, for example, 80% of the month’s cap is used |
Write the rates into the contract too, per role, for a fixed period. Then the only number that moves is the hours, and you can see them every week.
On T&M you pay for every hour, including the ones spent waiting or redoing work. Watch for two leaks.
The first is unclear direction. In the Stack Overflow Developer Survey 2026, “unclear priorities or requirements” was the most common reason developers gave for their job getting harder, at 16.6% of 18,214 answers. On a fixed price the vendor absorbs some of that cost. On T&M you pay it. Keep one product owner, answer the team’s questions within a working day, and don’t change priorities in the middle of a sprint without a reason.
The second is review and rework of AI-assisted code. Google’s 2025 DORA report, based on nearly 5,000 technology professionals, found that 90% use AI at work and that AI adoption goes with higher delivery throughput but also with lower delivery stability (Google Cloud, DORA 2025). More code gets written, and more of it needs checking. Ask that the weekly report show hours on new features apart from hours on fixes and review, so you can see if the second number keeps growing.
T&M fits when you want to start now and shape the scope as you go: a product that is already live, integrations whose effort nobody can judge yet, or the months after a first release when users tell you what to build next.
It doesn’t fit in three cases:
Few agencies publish them. In our study of 95 agencies, only six publish an hourly rate, from $20 to $100 (Rocketech MVP Price Index 2026). Ask every vendor for its rates in writing, per role, and ask what each rate includes. A lower rate that leaves out QA or project management can cost more per finished feature than a higher one that includes them.
The estimate gives you a starting point for the cap.
You can get a free project estimate in about four minutes.
A contract where you pay for the hours the team actually spends, at agreed hourly rates, plus any costs you approved in advance. You set the priorities and can change them as you learn. The budget is open unless you add a cap.
Set a cap per month or per phase, ask for a working demo every sprint and a weekly hours report by task, and keep one person in charge of priorities. Ask the vendor to warn you before the cap is reached.
No. Both are paid by the hour, and with us both cost $39-55 an hour. In a time and material project, the vendor runs the work and you set the priorities. In staff augmentation, the vendor’s people join your team, work in your process and report to your lead.
When the scope can’t be described well enough today to put one price on it: a live product with a changing backlog, integrations with unknown effort, or the months after a first release. For a small, clear scope, a fixed price is usually the better fit.
Time and material works when scope will change and you can review progress often. If the work will last for months, compare it with a dedicated team, where you pay for a stable group of people rather than for each task. Explore dedicated development team and the Livetag case study.
Compare time and material with a dedicated team
Start with an AI-assisted project brief covering scope, budget, market assumptions and risks. Review its hypotheses before making a commitment.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.