What a T&M Cap Actually Protects — and What It Doesn't

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A UAE enterprise COO or VP Technology who pushed back on a fixed-price quote and accepted a T&M-with-cap structure instead, and is now three months in, watching the burn rate approach the ceiling with scope still incomplete

A time-and-materials not-to-exceed cap protects your budget, not your deliverable. The ceiling tells the vendor how much they can invoice; it does not tell them they must finish the scope before stopping. Unless your MSA and SOW explicitly pair the cap with a completion-of-defined-scope obligation and a written suspend-or-continue election at the ceiling, the moment the burn hits 100% your vendor has a lawful right to down tools — and you have a half-built system with no contractual lever to force completion. This post walks through the clause language that closes that gap, the wording that quietly does not, and the questions to put to your vendor before you sign the next SOW.

This is editorial guidance, not legal advice. Any clause language here should be reviewed by qualified counsel familiar with UAE contract law and your specific MSA before you rely on it.

Why the cap feels like protection and isn't

You pushed back on fixed-price for sensible reasons. Fixed-price quotes in enterprise software are built on padded assumptions — the vendor has to price in every unknown, so you overpay for certainty you don't actually get when scope shifts. T&M-with-cap looked like the clean middle path: you pay for real hours worked, you get flexibility to change direction, and the ceiling means you can't be surprised at month-end.

The structure works as intended on the money side. What it does not do — and what most enterprise MSAs in the region are silent on — is bind the vendor to a defined deliverable. A fixed-price contract is a contract for a result. A T&M contract, even with a cap, is a contract for effort. The cap is a billing limit layered on top of an effort-based obligation. If the effort runs out before the result exists, the vendor has performed their contract. You have not received yours.

This is not a theoretical risk. PMI's 2024 data shows T&M software projects exceed original budget by 23% on average, and 52% of software projects experience scope creep, running an average of 27% over budget. McKinsey's study with Oxford of 5,400 large IT projects found initial budgets over $15M run 45% over budget on average and deliver 56% less value than predicted. In a market the size of the UAE's — USD 5.88 billion in 2024, projected to USD 12.88 billion by 2033, with large enterprises accounting for the majority of spend — the aggregate exposure from poorly drafted T&M caps is substantial.

What the standard NTE clause actually says

Open your MSA. Find the not-to-exceed language. It almost certainly reads something like this:

"The total fees payable by the Client under this Statement of Work shall not exceed [AED X] (the 'Cap'). The Vendor shall notify the Client when fees reach 80% of the Cap. The Vendor shall not be obligated to perform services in excess of the Cap without a written amendment executed by both parties."

Read the last sentence twice. It is a one-way door. The vendor is not obligated to continue past the cap. There is no reciprocal obligation to complete the scope within the cap. If the ceiling arrives at 70% feature-complete, the vendor's contractual duty is: notify you, stop work, present a change order. Your options are: (a) sign a cap increase, (b) accept a partial delivery, (c) terminate and sue — expensively, slowly, and with uncertain outcome under UAE Civil Code principles around substantial performance.

This is not vendor malpractice. It is the clause working exactly as written. U.S. federal procurement rules — probably the most heavily lawyered contracting environment on earth — are explicit about this: under FAR 16.601 and 2 CFR 200.318(j), the contractor "exceeds [the ceiling] at its own risk". The ceiling is a billing limit. Nothing more.

The four things the cap does not protect

1. Scope completion

Nothing in a standard NTE clause ties the ceiling to a defined output. The vendor can burn the cap on the first 60% of features and legitimately stop.

2. Quality at the ceiling

As the burn approaches the cap, there is a quiet incentive to prioritize visible progress over hardening. You may hit 100% of the cap with a demo-able but un-productionable system.

3. Timeline

The cap is a money ceiling, not a time ceiling. Hours can be stretched across more calendar time if the team is partially allocated, pushing your go-live without triggering the cap conversation until too late.

4. Transition and IP state at stop-work

If the vendor exercises their right to stop at the ceiling, what is the state of the code, the model weights, the environments, the documentation? A silent MSA means you receive whatever exists on the day work stops — which may not be deployable, documented, or legally cleanly assigned.

The clause language that closes the gap

Four paired provisions turn a one-sided cap into a mutual commitment. Your lawyer will phrase these properly for UAE enforceability — the point here is the structure, not the exact wording.

a) Completion-of-Defined-Scope obligation

Tie the cap to a specific, acceptance-tested deliverable set listed in the SOW. The clause reads, in substance: "The Vendor shall complete the Defined Scope set out in Annexure A within the Cap. If the Vendor's good-faith estimate at any point indicates that completion will exceed the Cap, the Vendor shall notify the Client no later than at 70% burn and the parties shall invoke the Election Mechanism in Clause [X]."

What this does: it converts the engagement from pure effort-based to hybrid. The vendor is still billed on time and materials, but is on the hook for a result within the ceiling, with an early-warning trigger well before the money runs out.

What it costs you: the vendor will price in more buffer, or will negotiate the Defined Scope down to something they are confident fits. That is fine — that negotiation is exactly where the scope-risk conversation should happen, before signature, not at 95% burn.

b) Suspend-or-Continue Election Mechanism

At the 70% notification, the client has a written election with defined options and defined vendor obligations under each. For example:

• Option 1 — Increase cap: client approves a specified cap increase; vendor continues under original terms.
• Option 2 — Reduce scope: parties agree in writing which items drop; vendor commits to deliver the reduced scope within the original cap.
• Option 3 — Suspend: work stops, vendor delivers a defined transition package (see below) within [N] business days, and client retains the right to resume within [M] months at the same rates.

The election mechanism matters because without it, hitting the ceiling triggers a renegotiation from a position of maximum weakness — the vendor knows you cannot walk away from a half-built system cheaply. A pre-agreed menu removes that leverage.

c) Transition-Out package

Define, in the SOW, exactly what the vendor must hand over on any form of stop-work — scheduled completion, ceiling-hit suspension, or termination. At minimum: current source code in a specified repository state, build and deployment scripts that actually run, environment configuration, any model weights and training data artefacts, up-to-date architecture and API documentation, a credentials handover protocol, and a defined number of hours of knowledge-transfer time to your team or a successor vendor. Price this transition package into the cap from day one so it is not a negotiating chip at the end.

d) IP assignment that vests on payment, not on completion

Many MSAs assign IP to the client only on "full completion of the SOW" or "full payment of all amounts due." If the project stops at the ceiling before completion, you may own nothing — or own it only under a dispute. The clean wording vests IP in the client progressively, on payment of each invoice, for all work product delivered up to that point. This way, if work stops, you own what you paid for and can hand it to another vendor without a chain-of-title fight.

The wording that quietly does not protect you

Watch for these phrases in draft MSAs. Each sounds reasonable; each is a trap.

• "The Vendor shall use commercially reasonable efforts to complete the Services within the Cap." "Commercially reasonable efforts" is a famously weak standard. It is not a completion obligation. Reject it; require a hard completion commitment tied to the Defined Scope.
• "Any work beyond the Cap shall be subject to a mutually agreed change order." This gives the vendor a veto. Replace with the Election Mechanism above, where the client holds the election.
• "The Cap excludes third-party costs, infrastructure, and expenses." Fine in principle, but require those excluded categories to have their own sub-caps and a monthly reporting line, or they become an uncapped parallel bill.
• "The Vendor retains ownership of pre-existing IP and general know-how." Standard and acceptable, but add: "and grants the Client a perpetual, royalty-free, worldwide, sublicensable licence to use such pre-existing IP to the extent embedded in the Deliverables." Without the licence-back, you own the custom code but cannot run it.
• "Acceptance shall be deemed to occur if the Client does not object within [5] business days." Deemed-acceptance clauses with short windows are enterprise poison. Require active, written acceptance against defined criteria, with a reasonable testing window — typically 15–20 business days for anything non-trivial.
• "The Vendor may suspend Services for non-payment of any undisputed invoice after [5] days." Short suspension triggers combined with a cap mechanism create cascading risk. Negotiate longer cure periods and require written notice.

The questions to put to your vendor before signing

Send these in writing. Keep the answers. If a vendor cannot answer them crisply, that is itself the answer.

1. If the cap is reached and the Defined Scope is incomplete, what specifically happens on day one after the ceiling is hit? Walk me through it.
2. At what burn percentage will you give me written notice, and what will that notice contain?
3. Which specific line items in the SOW are you most confident fit within the cap, and which are you least confident about? Show me your estimation ranges.
4. If I elect to suspend at the ceiling, what is in the transition package, how long does it take to deliver, and is that time inside or outside the cap?
5. If I bring in a second vendor to finish the work, what is your contractual position on cooperation, documentation handover, and IP licence-back for your pre-existing components?
6. At the moment of ceiling-hit, what IP do I own, what do I licence from you, and what do I own only after further payment?
7. Show me a project in the last 24 months where you hit the NTE cap before completion. What happened? How was it resolved?

The last question is the one most vendors will dodge. The honest answer is "yes, it has happened, here is how we handled it." The warning sign is "it has never happened" — which either means they have never done enough T&M-cap work to matter, or they are not being candid.

Where you are right now: three months in, approaching the ceiling

If this post found you late — three months in, 80% burn, scope incomplete — the clauses above are what you wish you had. Here is the shorter-term play.

First, get the current state of the system in writing from the vendor today, not at ceiling-hit. Specifically: what percentage of the SOW's Defined Scope is complete, what is in progress, what has not been started, and what is their revised estimate to completion in hours. Put it in email. Their reluctance to commit to this estimate is diagnostic.

Second, read your termination-for-convenience clause. Most enterprise MSAs include one with 30–60 days notice. This is your leverage — not because you intend to use it, but because the vendor's incentive calculation changes if they know you could.

Third, before you sign a cap-increase amendment, insist on retrofitting the four provisions above into the amendment itself. The amendment is a new contract moment. You will not get a second one.

Fourth, if the relationship is damaged beyond repair, start the transition conversation early. McKinsey's data notes that every additional year of planned project duration increases cost overruns by 15%, and 17% of large IT projects go badly enough to threaten the business. The cost of switching vendors mid-project is real but finite; the cost of continuing with a vendor who has lost the plot compounds.

The structural lesson for the next SOW

T&M-with-cap is a legitimate contracting structure. It is the right choice when scope is genuinely uncertain and both parties need flexibility to adapt. It is the wrong choice when you treat it as fixed-price with a flexibility option — because it is not. It is effort-based contracting with a billing ceiling, and the ceiling without a completion obligation is a one-sided protection.

Done properly — with Defined Scope, Election Mechanism, Transition Package, and progressive IP vesting — the structure gives you most of the flexibility of pure T&M and most of the predictability of fixed-price, at the cost of a longer and more honest pre-contract scoping conversation. That conversation is where the real risk gets priced. If your vendor resists having it, you have learned something important before you have spent any money.

For UAE enterprises evaluating software partners under these structures, the pre-contract scoping conversation — the one where Defined Scope gets negotiated honestly — is where the whole engagement is won or lost. If you are mid-structure on an engagement and want a second read on the clause mechanics, our Dubai software team and enterprise practice have worked through this contract pattern on both sides.

Frequently Asked Questions

Is a T&M not-to-exceed cap enforceable under UAE law?

Yes, in general — UAE Civil Code recognises freely negotiated commercial terms between sophisticated parties, and NTE caps are routinely used in UAE enterprise IT contracts. The enforceability question is not whether the cap binds, but what it binds the vendor to do: standard NTE wording binds them not to bill above the cap but does not bind them to complete the scope within it. Have UAE-qualified counsel review your specific MSA; this post is editorial guidance, not a legal opinion.

How does a capped T&M contract compare to fixed-price for cost certainty?

Fixed-price gives you the strongest completion obligation but at a premium — vendors build in buffers of 20–40% for risk they cannot see. Capped T&M typically runs cheaper on the base rate but, per PMI's 2024 data, exceeds original budget by 23% on average, so the realised cost often converges. The real differentiator is not price — it is which party carries scope-uncertainty risk. Fixed-price puts it on the vendor; uncapped T&M puts it on you; capped T&M splits it, imperfectly, at the ceiling.

What should the notification threshold be — 70%, 80%, 90% of the cap?

Earlier is better. 70% gives you meaningful runway to negotiate scope reduction, cap increase, or orderly suspension before the vendor's stop-work right crystallises. 80% is the industry default and is usually too late on anything but short engagements. 90% is a notification, not a negotiation window. Push for 70% with a mandatory written status report, and a second notification at 85% with a revised completion estimate.

Who owns the code if the cap is reached before the project is complete?

Depends entirely on your IP clause. If assignment is tied to "full completion" or "full payment of all SOW amounts," you may own nothing of what has been built. If assignment vests progressively on payment of each invoice, you own what you have paid for. This is one of the most important clauses to get right at MSA stage, and it is almost always drafted in favour of whoever wrote the first draft — usually the vendor. Have your lawyer rewrite it to vest progressively.

What drives the cost of properly scoping a T&M-with-cap engagement upfront?

The main drivers are the depth of discovery (how many user flows, integrations, and data flows need to be mapped before scope can be defined), the number of stakeholders who must sign off on the Defined Scope, the maturity of your existing systems and documentation, and the regulatory environment (financial services and healthcare require materially more upfront compliance scoping). The range is wide because these factors stack multiplicatively. To turn a range into a real estimate, three specifics are needed: the system boundary and integration list, the regulatory regime that applies, and whether you have a product owner internally or need the vendor to supply one. A scoping conversation with a prospective delivery partner is the fastest way to narrow it.