What a Good Statement of Work Actually Contains

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

For: A UAE-based startup founder who has received a proposal and SOW draft from a development partner, is ready to sign, but has never commissioned bespoke software before and does not know which clauses protect them and which leave them exposed

A good software development statement of work does one job: it makes the moment of 'done' unambiguous to both sides. Everything else — payment milestones, IP assignment, warranty, termination — is downstream of that. If your SOW does not define, in testable terms, what the vendor has to deliver for you to owe them the next payment, you do not have a contract. You have a disagreement waiting to happen. This post walks through the clauses that matter in a software development SOW, the wording that protects you as the buyer, the wording that quietly does not, and the questions to put to your vendor before you sign. None of this is legal advice. Get a lawyer who has reviewed technology contracts in the UAE to read the final document.

Why this matters more than most founders realise: 40% of software projects fail to deliver on their original objectives, with unclear requirements (39%) and scope creep (33%) as the top two causes. The SOW is where you fix both of those, or where you fail to.

Start with the structural question: MSA plus SOW, or everything in one document?

Most serious development partners will give you a two-document structure. A Master Services Agreement (MSA) covers the terms that apply to the relationship regardless of what you build — IP, confidentiality, liability caps, dispute resolution, data protection, termination. The Statement of Work (SOW) covers this specific project — what gets built, by when, for what, and how you accept it.

If a vendor hands you a single 12-page document that bundles everything together, that is a flag. Not necessarily a dealbreaker on a small engagement, but you lose the ability to run multiple projects under one set of commercial terms, and the project-specific details tend to crowd out the terms that actually protect you. Ask for the MSA and SOW split.

The rest of this post focuses on the SOW itself.

The clause that causes most disputes: acceptance criteria

This is where to spend your review time. Over 30% of technology vendor revenue disputes trace back to acceptance testing mechanics, and acceptance clauses appear in roughly 82% of custom software agreements — so the frequency with which this clause blows up is not because it is rare, it is because it is almost always written badly.

Here is the specific failure mode. The vendor writes acceptance to mean 'the code is deployed to the staging environment and the listed features render without error.' You read acceptance to mean 'the thing works the way we discussed in the demo and my users can actually use it.' Both of you sign. Three months in, the vendor says the milestone is accepted, you say it is not, and now you are arguing about whether 'login works' means the login endpoint returns a 200 or whether a real customer can get into the app on a flaky 4G connection in Sharjah.

What protects you

Acceptance criteria that are:

• Written as testable statements, not features. Not 'user can place an order' but 'a signed-in user with a valid saved payment method can place an order of 1–20 items, receive an order confirmation email within 60 seconds, and see the order in their order history.'
• Attached to each milestone, not the project as a whole. If payment milestone 3 releases on 'completion of the checkout module,' then checkout has its own acceptance criteria list sitting next to that milestone.
• Give you a defined testing window. Something like 'Buyer has 10 business days from delivery to test against the acceptance criteria and submit defects in writing.'
• Define what a defect is, in severity tiers. Critical (blocks core function), major (degrades core function, workaround exists), minor (cosmetic). Payment should only be gated on critical and major defects being resolved.

What quietly does not protect you

Deemed acceptance clauses. These say that if you do not reject a deliverable within X days, it is automatically accepted. Thomson Reuters Practical Law data from 2024 shows deemed acceptance appears in roughly 74% of vendor-drafted technology agreements but only 48% of client-drafted agreements — a clean indicator of whose interest it serves. The clause itself is not evil. Vendors need protection against buyers who go silent and never pay. But the window needs to be realistic (10 business days minimum, more for complex deliverables), the clock should only start when you have working software to test, not when the vendor emails you a link, and the clause must exclude periods when you have raised defects that are being worked.

Vague language like 'substantially conforms' or 'materially complies.' Substantially is a word lawyers argue about for months. Replace it with the testable criteria.

Acceptance tied to the vendor's own test results. If the SOW says the vendor runs the tests and reports results, you have no independent verification. You run the tests, or you both run them side by side.

The question to put to the vendor

'Can we rewrite the acceptance criteria for milestone one together, right now, as a list of test cases I can execute myself?' If they resist, you have learned something important about how this relationship will go.

Scope, and how changes get priced

Scope creep causes an average budget overrun of 45% on IT projects, roughly $675,000 according to PMI data. A good SOW does not try to prevent scope change — that is impossible on any real project — it defines the mechanism by which scope changes get agreed and paid for.

What protects you

• A scope section that lists what is in and, explicitly, what is out. The 'out of scope' list is more valuable than the 'in scope' list. 'This SOW does not include: iOS or Android native apps, migration of legacy customer data, Arabic localisation, integration with any payment gateway other than Stripe, SOC 2 preparation.' If it is not written down as out, you will end up arguing about whether it was always implied to be in.
• A written change request process. Buyer or vendor can request a change. Vendor estimates the impact in writing (hours, cost, schedule). Buyer approves in writing before any work begins. No verbal change orders. No 'we'll just do it and sort it out later.'
• Pre-agreed change-order pricing. The SOW should state the hourly or day rate at which changes are priced, and it should be the same rate as the base engagement, or lower. If the vendor's SOW is silent on change rates, they will quote premium rates when you need them most — when you are already committed.

What quietly does not protect you

Language that lets the vendor unilaterally classify something as 'additional work.' Any clause that says 'the Vendor shall determine whether a requested change constitutes additional scope' hands them the pricing gun. Changes should be mutually agreed, with a defined dispute path if you disagree about whether something was already in scope.

Payment milestones

Milestones should be tied to acceptance of specific deliverables, not to time. 'Payment of 25% on completion of month 2' is a bad milestone because it pays the vendor whether or not they have delivered anything. '25% on acceptance of the authentication and user management module per acceptance criteria in Annex A' is a good milestone.

A reasonable structure for a fixed-scope engagement looks like: a mobilisation payment (10–20%) to get the team started, three to five milestone payments tied to accepted deliverables, and a final retention (10–15%) held until the end of the warranty period or until a defined set of post-launch stability criteria are met. The retention is the clause vendors push back on hardest and the one that most reliably protects you from a vendor who disappears at go-live.

IP assignment: who owns what

For bespoke software, the default position you should insist on is: all code, designs, documentation, and deliverables created specifically for you under this SOW are assigned to you on payment, with full ownership transferring on final payment. This includes model weights and fine-tuned models if the project involves AI.

The three carve-outs that are reasonable

• Vendor's pre-existing IP and tooling. If they built a reusable deployment framework three years ago, they keep owning it. They should grant you a perpetual, royalty-free licence to use it as embedded in your product.
• Open source components. Governed by their own licences, not assignable. The SOW should require the vendor to disclose all OSS components and their licences.
• General know-how. The vendor cannot un-learn how to build what they built for you. Reasonable.

What quietly does not protect you

'Vendor retains ownership and grants Buyer a licence to use.' This is the opposite of what you want for bespoke work. You paid for it, you own it. A licence can be revoked, limited, or get complicated at the vendor's acquisition or bankruptcy.

Also watch for IP assignment that is conditional on 'full and final payment of all amounts due' without defining what 'due' means. If there is any disputed invoice, your IP is in limbo. Tie assignment to payment of the specific milestone the deliverable belongs to.

Warranty and post-launch support

A fair warranty on custom software is 60–90 days from acceptance, during which the vendor fixes defects (not new features) at no charge. The SOW should define:

• What counts as a warranty defect (something that does not meet the acceptance criteria, discovered after acceptance).
• Response and resolution times by severity.
• How warranty differs from paid support, which starts after the warranty window.

What quietly does not protect you: warranty clauses that exclude 'issues arising from changes in third-party services or infrastructure.' Taken literally, this means the moment Stripe updates its API or iOS releases a new version, your warranty voids. Tighten this to exclude only material breaking changes that could not have been reasonably anticipated.

Termination and transition-out

You need to be able to leave. The SOW should give you a termination-for-convenience right with 30 days' notice, paying for work completed and accepted up to the termination date, plus a defined wind-down fee if any. You also need termination for cause with a cure period — if the vendor materially breaches, they get 15–30 days to fix it, and if they do not, you can terminate without further payment.

The transition-out clause is where many SOWs are weak. On termination for any reason, the vendor must:

• Hand over all code, credentials, documentation, and deployment configurations within a defined window (10 business days is reasonable).
• Provide reasonable transition support to a successor vendor at pre-agreed rates.
• Delete your data from their systems within a defined period and certify deletion in writing.

Without this clause, a termination dispute can leave your production system running on infrastructure you cannot access, with code you technically own but cannot deploy.

A note on cost and timeline in the SOW

Founders often ask whether the SOW should fix the price and the delivery date. The honest answer is: it depends on how well-defined the scope is. If you have a tight, written specification and you are building something the vendor has built shapes of before, a fixed price with a fixed timeline is reasonable and the risk sits mostly with the vendor. If the scope is still being discovered — which is true of most AI-first products and most greenfield startups — a fixed price with a fixed timeline is a fiction. One of three things will give: scope, quality, or the relationship.

The honest structure for a less-defined project is a time-and-materials engagement with a not-to-exceed cap per phase, a weekly burn rate you can see, and a clear exit point at the end of each phase where you can stop, change direction, or change vendor. This feels less safe than a fixed price but usually ends up costing less and delivering more, because nobody is incentivised to hide problems. For context on why fixed-price often disappoints: large IT projects run 45% over budget and 7% over time while delivering 56% less value than predicted, according to a McKinsey and University of Oxford study of 5,400 projects. Fixed-price contracts did not prevent that; they just moved where the pain showed up.

Whichever structure you choose, the SOW must state the two or three specifics that would move the number materially if they changed — number of integrations, whether existing data needs to be migrated, whether the vendor is also responsible for infrastructure, whether a specific compliance regime (DIFC, ADGM, PCI-DSS, HIPAA) applies. Those are the dials. Your lawyer should check that the SOW gives you visibility into them, not just the final number.

Data protection and sub-processors

If your product handles personal data of UAE residents, the SOW (or a linked DPA) must address the UAE Personal Data Protection Law. At minimum: the vendor processes data only on your documented instructions, lists all sub-processors (hosting providers, email services, analytics, any third-party AI APIs they call) and notifies you before adding new ones, implements defined security measures, and notifies you of any data breach within a specified window. Again — a lawyer with UAE data protection experience should review this. The SOW is not the place to improvise on compliance.

How CodeNicely can help

We work with founders in the UAE and across the GCC who are commissioning bespoke software for the first time, and we have been on both sides of SOW negotiations. When we built GimBooks, a YC-backed accounting SaaS, the SOW structure had to accommodate a product that was still finding its shape — fixed-scope would have been dishonest, so we worked in phased engagements with clear acceptance criteria at each phase and full IP transfer at every milestone. That is the model we recommend to most early-stage founders: smaller, well-defined commitments with real exit points, not a monolithic twelve-month fixed-price contract that nobody can realistically honour.

If you have a draft SOW from another partner and want a technical read-through before you sign — not legal review, but a practitioner's read on whether the acceptance criteria, scope boundaries, and change-order mechanics are set up to protect you — reach out to our Dubai team. We do this as a courtesy for founders in the region, including when the project is not going to us.

Before you sign: a short checklist

1. Can I execute the acceptance criteria myself, or do I need the vendor to run them?
2. Is there a deemed-acceptance clause, and is the window realistic?
3. Does the SOW list what is out of scope, not just what is in?
4. Is the change-order rate stated, and is it the same as the base rate?
5. Do payment milestones release only on accepted deliverables?
6. Is there a retention held until a defined post-launch stability point?
7. Does IP assign to me on payment of each milestone, not only on final payment?
8. Can I terminate for convenience, and does transition-out include code, credentials, and data deletion?
9. Is the data protection annex specific to UAE PDPL and does it list sub-processors?
10. Has a lawyer with technology contract experience actually read it?

If you cannot answer yes to all ten, the SOW is not ready to sign. That is not a reflection on the vendor; it is just how most first drafts come out. The useful thing is to send the vendor a redline rather than a rejection. A good partner will welcome the specificity, because the alternative — a dispute six months in — is bad for everyone.

Frequently Asked Questions

What is the difference between a proposal and a statement of work?

A proposal is a sales document. It describes what the vendor thinks they can do and roughly what it might cost, and it is not binding. A statement of work is a contract annex. It defines the specific deliverables, acceptance criteria, milestones, and payment terms, and it is enforceable once signed under the MSA. Never let a proposal substitute for a SOW, even on a small engagement.

How long should a software development SOW be?

Long enough to make 'done' unambiguous for every deliverable, and no longer. For a three-month MVP, a well-written SOW is usually 15–25 pages including annexes for acceptance criteria and the out-of-scope list. If it is under 10 pages, acceptance criteria are probably underspecified. If it is over 50, someone is padding.

Can I change the SOW after signing?

Yes, through the change request process defined in the SOW itself. Both parties agree the change in writing, the vendor estimates impact on cost and schedule, you approve, and the change becomes an amendment to the SOW. Never agree changes verbally or on Slack — if it is not in a signed change order, it did not happen.

What drives the cost of a custom software project in the UAE?

The main drivers are scope clarity (how defined the requirements are at signing), number and complexity of third-party integrations, whether you need existing data migrated, compliance scope (DIFC, ADGM, PDPL, PCI-DSS, HIPAA all add work), team seniority and location, and how much ongoing iteration you want after launch. The UAE IT services outsourcing market reached USD 6.045 billion in 2025 and is projected to hit USD 11.1 billion by 2033 at a 7.92% CAGR according to Grand View Research, which gives you a sense of the depth of supply — rates vary by an order of magnitude across that market. The two or three specifics that turn a range into a real quote are the ones listed above; a conversation with a partner who scopes properly will give you a number you can plan around.

Do I really need a lawyer to review the SOW?

Yes. Nothing in this post is a substitute for legal review by someone who knows UAE contract law and technology contracts specifically. The clauses this post covers are the ones most likely to cause operational disputes, but liability caps, indemnities, dispute resolution venue, governing law, and warranty disclaimers all have legal consequences that are not obvious to non-lawyers. A few hours of a technology lawyer's time before signing is cheap compared to the cost of litigating a bad SOW later.