How Payment Milestones Get Structured to Favor the Vendor

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

For: A pre-Series A founder in Dubai who has received a proposal from an offshore dev studio and is staring at a payment schedule that front-loads 40% before a line of code is written

If your proposal says 40% on signing, 30% at UAT start, 30% on go-live, you are not looking at a payment schedule — you are looking at a risk-transfer schedule, and almost all the risk is being transferred to you. The vendor collects the majority of the fee before any deliverable can be objectively tested, and the one milestone that could be tested (UAT) is almost certainly defined by language that lets the vendor declare completion unilaterally. This post walks through the specific wording to look for in the SOW, what the industry data says about where these contracts actually fail, and the questions to put to the vendor before you sign. This is not legal advice; a lawyer should review the final document, and for anything compliance-adjacent, so should an auditor.

Why milestone structure is where offshore contracts quietly fail

Outsourced delivery is now the default, not the exception. Deloitte's 2024 Global Outsourcing Survey found that around 76% of IT work is delivered by external providers or third-party delivery models, and the global offshore development market was valued at $122 billion in 2024, heading toward $283 billion by 2032. In the UAE specifically, the IT services outsourcing market generated $6.05 billion in 2025 and is projected to nearly double by 2033. So the volume of these contracts being signed by Dubai-based founders is large and growing.

The failure rate on them is also large. SmartDev's 2026 budget analysis found that roughly 35% of fixed-price offshore projects run into scope disputes, with change-order costs averaging 15–25% of the original contract value, and that 70% of projects exceed initial budgets by 27–45%. Nearly all of these disputes come back to the same two documents: the acceptance criteria and the payment milestones that depend on them.

What a milestone schedule is supposed to do

A milestone schedule in a software SOW does three things at once:

1. Allocates cash flow — when the vendor gets paid.
2. Allocates risk — who is holding the bag if the project stalls, and at what point.
3. Creates leverage — the unpaid balance is the only thing that keeps a vendor commercially motivated once they already have your signature.

A well-structured schedule keeps those three in balance: the vendor is paid in a rhythm that matches their burn, but the buyer always holds enough unpaid balance to make quality problems the vendor's problem, not the buyer's. A vendor-favoring schedule breaks that balance. It front-loads cash and back-loads the vendor's remaining obligations into a single, loosely-defined gate.

Red flag #1: the front-loaded deposit

The most common pattern is a 30–40% deposit on signature, often labeled "mobilization," "kickoff," or "project initiation." The justification is cash flow for team allocation. That justification is real for the vendor; it is not your problem to solve on the buyer side at that ratio.

LegalClarity's analysis of milestone payments is blunt on this: front-loading "gives the contractor a disproportionate share of the money early in the project, which leaves the client with little leverage if quality drops later" and in the worst case exposes the client to total loss if the vendor abandons work. Once a vendor has 40% of fee in hand for 5% of calendar effort, the economics of walking away from a difficult project tilt against you.

What the wording usually says

"40% of the Total Fee shall be due upon execution of this SOW as a non-refundable mobilization payment."

Why that quietly does not protect you

"Non-refundable" is doing most of the work in that sentence. If the vendor misses the first delivery entirely, you have no contractual mechanism to claw back the deposit — only an arbitration clause and a long road.

Buyer-protective wording

Cap the initial payment at 10–15%, label it refundable against a defined early deliverable (e.g., signed-off technical design document and sprint-0 environment), and tie refundability to a termination-for-cause clause that explicitly lists non-delivery of that first artifact as cause.

Questions to put to the vendor

• What specific deliverable corresponds to the mobilization payment, and when is it due?
• If that deliverable is not accepted, is the mobilization payment refundable or credited?
• Will you accept a 10–15% deposit against a signed design doc instead of 40% against signature?

Red flag #2: milestones tied to activities, not outcomes

Watch for milestones named like "Backend development complete," "Integration phase complete," or "QA phase complete." These are activity labels, not outcome definitions. "Backend development complete" is a statement about what the vendor's team has stopped doing, not about what works.

The University of Minnesota's analysis of software contracts puts the problem clearly: the absence of written acceptance criteria "introduces ambiguity and subjectivity, frequently leading to disputes over whether the developer has fulfilled its contractual obligations." If the milestone label is the only definition, the vendor's project manager is the only judge.

Buyer-protective wording

Every milestone attached to a payment must reference an Acceptance Criteria Schedule — an annex that lists, for each deliverable:

• The specific features or endpoints being delivered
• Measurable performance targets (e.g., "P95 API response under 400ms on staging under 100 concurrent users")
• The test cases that must pass, by name or ID
• Who runs the test, in which environment, and over how many business days
• What happens if a test fails — cure period, re-test, and the point at which the buyer may reject the milestone

SmartDev's budget data makes the economics of writing this annex obvious: detailed specifications cost 8–12% of budget but prevent the 15–25% hit from scope disputes. The acceptance criteria annex is where that spec work lives.

Red flag #3: the UAT clause that transfers risk the moment testing begins

This is the one most founders miss, and it is the most expensive.

An acceptance testing clause is, in commercial terms, a gate. Before acceptance, the vendor bears performance risk; after acceptance, the customer owes the milestone payment — typically 20–40% of total deliverable value — and remedies shift from rejection to the narrower warranty channel. ContractKen notes that over 30% of technology vendor revenue disputes trace back to how acceptance testing was defined and triggered.

The specific trap: many offshore SOWs contain a deemed acceptance clause. The wording looks innocuous.

What the wording usually says

"The Deliverable shall be deemed accepted upon the earlier of (a) Customer's written acceptance, or (b) ten (10) business days following delivery to Customer, unless Customer has provided written notice of material defect."

Why that quietly does not protect you

Three reasons. First, "material defect" is undefined — so if your tester logs twenty cosmetic bugs and one serious one, the vendor can argue the serious one is immaterial. Second, the ten-day clock starts on delivery, not on the moment a working test environment is actually available to your team. Third, if your QA lead is on leave for two weeks, you have deemed-accepted a deliverable you have never tested, and the next milestone payment is due.

The insight founders rarely spot: the moment you begin UAT, you have begun the clock on paying for it, even if the acceptance criteria were never written down. If the SOW says the UAT milestone is triggered by "Customer commencement of User Acceptance Testing," that payment is now owed when your QA lead opens the staging environment, regardless of what they find.

Buyer-protective wording

• Define "material defect" by reference to the Acceptance Criteria Schedule — a failure of any listed test case is a material defect, full stop.
• Start the UAT clock on delivery of a stable test environment, not on nominal delivery of code. Require the vendor to confirm environment stability in writing.
• Make the UAT period long enough for your team to actually test — 15 business days is reasonable for an MVP, longer for anything with integrations.
• Replace deemed-acceptance with a cure-and-retest loop: on failure, vendor has a defined cure period (e.g., 10 business days), after which the test is re-run. Three failed cures = buyer's right to terminate for cause with refund of unused prepaid fees.
• Payment is due on written acceptance, not on commencement of testing.

Questions to put to the vendor

• Is "material defect" defined in the SOW? If so, where?
• When exactly does the UAT clock start — on code delivery, environment delivery, or environment sign-off?
• Will you accept cure-and-retest in place of deemed acceptance?
• If we cannot test within the UAT window because of our own capacity, does the deemed-acceptance clock still run?

Red flag #4: the final milestone is too small

Look at the final payment. If it is 10% or less, the vendor's commercial incentive to fix post-launch issues drops to near zero the day they invoice the previous milestone. That final tranche is the only money that keeps them answering Slack during the stabilization window.

Buyer-protective wording

Hold back at least 15–20% until a defined stabilization period ends — typically 30 or 60 days of production use with agreed uptime and defect-rate thresholds. Separate this from the warranty clause; the warranty is a longer, narrower obligation, while the holdback is specifically about go-live quality.

A more buyer-fair milestone shape

Illustrative only — the exact split depends on project duration, team size, and integration complexity, none of which are scoped here. Treat this as a shape, not a template:

What this shape does: never more than ~30% unpaid balance evaporates in any single milestone, no milestone is triggered by a vendor-controlled activity label, and the stabilization holdback keeps real money in play through the window where most production issues surface.

The cost and timeline question founders actually want to ask

Reasonable question: "what does a milestone-fair MVP contract cost, and how long does negotiating it take?" Honest answer: the contract itself is a small line item relative to what it saves. The thing that moves cost and timeline is the quality of the Acceptance Criteria Schedule, which depends on how well the product is scoped before you sign.

What drives the number:

• Integration count. Each third-party dependency (payments, KYC, maps, messaging) adds a test surface and usually a milestone.
• Data migration. If you are moving off an existing system, acceptance criteria need to cover data integrity, not just functionality.
• Compliance scope. UAE PDPL, DIFC data rules, or sector-specific regulation (healthcare, lending) change what "acceptance" means and expand the test matrix.
• Decision latency on your side. The single biggest hidden cost driver — SmartDev's data shows buyers underestimate total offshore cost by 20–30%, and most of that gap is slow approvals and mid-build scope changes, not vendor pricing.

To turn a range into a real quote, three specifics need to be on the table: the feature list at a user-story level, the integration list with named providers, and the compliance posture you need at launch. Without those, any number — including any number in a proposal already in front of you — is a placeholder.

How CodeNicely can help

We have been on both sides of this document. The engagement that most resembles the Dubai pre-Series A situation is GimBooks, a YC-backed fintech where the contract structure had to protect a founder running on a defined runway, with acceptance criteria tight enough to survive investor diligence. The milestone structure there was built around named feature sets passing documented test cases, with a stabilization holdback through the first live tax cycle — the equivalent, for a UAE founder, of holding back through the first real customer cohort.

For founders scoping an MVP from Dubai, our UAE engagement page covers how we structure SOWs for the local market, including PDPL considerations in acceptance criteria. For AI-heavy builds where "acceptance" also has to cover model behaviour (not just functional pass/fail), the AI Studio page explains how we define acceptance for probabilistic outputs — which is a different and harder problem than UAT for a CRUD app.

Full IP assignment and no vendor lock-in are standard in our contracts, which matters here because milestone structure interacts with IP: in some offshore contracts, IP only transfers on final payment, meaning a dispute at the last milestone leaves the buyer without the code they already paid 85% for. That is a separate clause family worth reading carefully.

The short version

Before you sign, do five things. Cap the deposit. Attach an Acceptance Criteria Schedule to every payment-bearing milestone. Replace deemed acceptance with cure-and-retest. Start the UAT clock on environment sign-off, not code delivery. Hold back 15–20% through a defined stabilization window. Then send the redline back and see how the vendor responds — that response, more than anything in the original proposal, tells you who you are about to work with.

And then have a lawyer read it. None of the above substitutes for counsel qualified in the jurisdiction the contract will be governed by.

Frequently Asked Questions

Is a 40% upfront payment ever reasonable in an offshore dev contract?

Rarely, and almost never for a first engagement with a vendor you have not worked with before. A deposit in the 10–15% range tied to a refundable first deliverable (like a signed technical design doc) is more balanced. If a vendor refuses to move off 40% non-refundable, that itself is useful information about how they view risk-sharing.

What is "deemed acceptance" and why is it dangerous?

Deemed acceptance is a clause that says a deliverable is considered accepted — and the related payment becomes due — if the buyer does not formally reject it within a short window, typically 5–15 business days. It is dangerous because it shifts risk to the buyer the moment delivery is nominal, even if the acceptance criteria were never written down or the test environment is not actually usable. Replace it with a cure-and-retest loop tied to written acceptance.

How detailed do acceptance criteria need to be?

Detailed enough that two different engineers reading them would run the same tests and reach the same pass/fail verdict. That usually means specific endpoints or user flows, measurable performance targets, named test cases, and the environment the tests run in. Writing this up front costs around 8–12% of project budget and prevents scope disputes that typically run 15–25% of contract value, according to SmartDev's 2026 budget analysis.

Who owns the code if a dispute breaks out mid-project?

It depends entirely on how the IP assignment clause is written. In many offshore contracts, IP transfers only on final payment, which means a buyer who has paid 70% can end up with no legal right to the code. A buyer-protective version transfers IP progressively as each milestone is paid, or at minimum provides source-code escrow with defined release triggers. This is a clause to have a lawyer review specifically.

What should I ask a vendor before signing the SOW?

Four questions worth asking in writing: (1) What is the specific deliverable for each payment milestone, and is it defined in an acceptance criteria annex? (2) When does the UAT clock start and what happens if we cannot test within the window? (3) Does IP transfer progressively or only on final payment? (4) What is the holdback through the post-launch stabilization period? The quality of the written answers tells you more than the proposal document itself.