A software proposal is typically twelve pages long, and about five sentences in it decide what happens if things go wrong. Those five sentences are rarely the ones in bold.
The rest of the document describes what you will get, which is the part everybody reads and the part least likely to be contested. Nobody argues about whether the proposal promised a booking screen. They argue about whether the booking screen is finished, what happens to it now the relationship has ended, and who pays for the change that was obviously always needed.
This article is about the clauses that settle those arguments in advance. A sibling covers why quotes vary so widely, which is about the number rather than the document.
Two things this article will not do. It will not give legal advice, and it will not give you contract wording. We explain what to look for so you can have a better conversation with a qualified UAE lawyer, and with the supplier who wrote the proposal.
Acceptance criteria, the clause whose absence causes most disputes
A proposal with no written definition of done leaves every other clause in it unenforceable in practice.
Without acceptance criteria, finished is a matter of opinion. Your opinion is that the feature does not work the way you expected. The supplier's opinion is that it does exactly what was described and what you are now asking for is a change. Both positions are sincere, neither can be settled by re-reading a feature list, and the party holding the remaining money loses that argument slowly.
What to look for is a statement, per deliverable, of what will be demonstrated, against what, and who signs it off. Useful criteria are specific enough that two people who disagree could still both apply them: a person can do this, on this, and this is the expected result. Unhelpful criteria say the system will function correctly.
Two related details worth finding. The review window, meaning how long you have to accept or reject. And deemed acceptance, where work counts as accepted if you do not object within that period. Deemed acceptance is not unfair in principle, because suppliers do need protection against clients who never respond. It is worth knowing it exists and checking the window is not so short that a busy fortnight costs you your say.
Our QA guide covers what to agree before testing starts, which is the operational layer under this clause.
Ownership, and the gap that opens at exactly the wrong moment
The IP clause should assign the rights in the delivered work to you, and UAE law is specific about what an assignment must contain. Our code ownership guide sets that out properly.
The pattern worth checking for here is assignment conditional on final payment, with nothing said about what happens if the relationship ends before that point. That is extremely common and usually not sinister: a supplier is protecting itself against non-payment. But it leaves a gap at precisely the moment ownership matters most, which is a project ending badly with an invoice in dispute.
Ask what you hold if the engagement stops before completion. A proposal that has considered it will have an answer.
Check the source code clause separately, because it is a different question from ownership. Repository access with history, delivered continuously, is a different deliverable from a zip file at the end, and both get described as source code delivery. Look for the format, the timing, and whether documentation and build instructions come with it.
On subcontracting, what matters is not whether it happens, because it usually does and that is fine. It is whether the supplier stays accountable for the whole, and whether the rights assigned to you actually flow through from whoever did the work.
Payment structure, and the leverage you are about to give away
Milestones tied to deliverables pay for progress. Milestones tied to dates pay for time passing. On a short project the distinction is academic. On a longer one, a schedule can slip while payments continue on the calendar, and you notice only when you compare the two.
The more important number is the last one. The final payment is the only leverage you retain once the work is done, and handover is the least glamorous part of any project. A final payment of five per cent buys very little attention during the fortnight when you need documentation written, accounts transferred and questions answered.
Make it meaningful, and tie it to acceptance plus delivery of the code and documentation rather than to a date. That single change does more for handover quality than any clause you could add.
Warranty, support, and the difference between them
A warranty fixes what was wrong at delivery. Support keeps the thing running afterwards. They are separate commitments with separate prices, and a proposal that quietly treats one as the other is understating what you will pay in year one.
On the warranty, check three things. What counts as a defect, because the useful definition is work that does not meet the agreed criteria and the less useful one excludes anything arguable as a change. How long it runs. And whether it starts at delivery or at go-live, which on a project with a delayed launch can be months apart.
On support, check for a response time and an exclusions list. Support included with neither is a word rather than a commitment. Our app maintenance guide covers what ongoing support actually costs, so you can tell whether a proposal has priced it or absorbed it.
Termination, the clause everyone reads too late
What happens to the deliverables, the accounts and the money.
Specifically: what you receive on termination, whether work in progress is handed over and in what state, what notice each side must give, and how sums already paid or outstanding are settled. Our guide to changing agency covers the process; this is the paperwork that governs it.
The asymmetry is worth naming. A missing termination clause is felt almost entirely by the buyer, because the supplier retains the code, the accounts and the knowledge by default, and you retain a receipt.
A pattern we see. A project ends amicably enough. The client asks for the repository, the documentation and the account transfers. The supplier is willing but busy, the contract says nothing about any of it, and there is no money outstanding to focus anyone's attention. Six weeks later the client has some of what they asked for. Nobody behaved badly. The document simply never contemplated the ending.
Fixed price or time and materials
Neither is more honest. They allocate risk differently, and the mismatch to avoid is applying either one to the wrong situation.
A fixed price transfers risk to the supplier, who prices for it. The consequence is that every variation becomes a negotiation, because their margin depends on it. That is not adversarial behaviour, it is arithmetic. Fixed price suits a scope both sides genuinely understand.
Time and materials keeps flexibility and moves risk to you. It works when it comes with visibility: an agreed rate, a regular report of what was actually done, and a cap or review point both sides respect. Without those it becomes an open cheque, which is why it has the reputation it has.
The genuinely bad combination is a fixed price on a scope nobody has defined. It is either padded to cover the unknown, in which case you overpay, or fragile, in which case it collapses into variations. If the scope is not written down, fix that before choosing a pricing model.
The language that signals a difficult year
None of these mean bad faith. All of them defer a conversation to a point where you have less leverage.
- An estimate presented as a fixed price. Ask which it is, in writing
- Industry standard used where a definition belongs
- A scope described only as features, with no acceptance criteria attached to any of them
- Support included with no response time and no exclusions
- Best efforts attached to something you are relying on
- No exclusions section at all. The absence of one does not mean nothing is excluded
- No assumptions listed. Every proposal assumes things about what you will provide and how fast you will decide. The ones that write them down are protecting both sides
What UAE law does and does not require
We found no requirement that a private commercial software contract contain acceptance criteria, particular IP wording, a warranty of any length, or specific confidentiality terms. These are buyer-protective practices, not legal mandates.
That is worth knowing precisely because it means nobody supplies them by default. If you want them, you ask.
On the law itself, one thing has changed that is worth knowing before anyone quotes you provisions. The Civil Transactions Law that governed contracts for decades has been replaced by Federal Decree-Law No. 25 of 2025, in force since 1 June 2026 [1]. A contract signed before that date may still be governed by the previous law, so establishing which regime applies to your agreement comes before anything else. We could not load the primary text to verify article-level detail, so we cite no article numbers, and we would treat any article that confidently does with caution unless it is very recent.
On arbitration, UAE arbitration is governed by Federal Law No. 6 of 2018, which requires an arbitration agreement to be in writing [2]. Whether a particular clause achieves what it intends, and whether a foreign governing law or offshore seat will hold up, we are not going to tell you. The UAE government portal also indicates that mediation or conciliation is required ahead of many civil and commercial court cases [3], which is useful context for how a dispute would actually unfold. We are not quoting a value threshold for that, because we could not confirm one.
All of which routes to the same place: for anything material, have a qualified UAE lawyer read it.
The cost-of-fixing-it-late claim, which you should ignore
You will encounter the argument that a defect found late costs ten or a hundred times more than one found early, usually deployed to justify a larger up-front phase.
The figures in circulation trace inconsistently to several different sources and do not hold up as a stable, citable multiplier. We are not going to repeat them, in the same way our QA guide declined to repeat the claim that half a budget should go on testing.
The underlying point survives without the number: it is cheaper to decide something before it is built than after. That is true and it does not need a fake multiplier attached.
Two reviews, not one
A lawyer can tell you whether the contract protects you. A lawyer cannot tell you whether the scope is coherent, whether the deliverables are things that can actually be demonstrated, whether the acceptance criteria are testable, or whether the price and the timeline are consistent with the work described.
A technical review of a proposal starts from around AED 1,500 with us, and covers exactly those questions. These are our own figures rather than a market survey. We will review a proposal from another supplier and tell you if it looks sound, because a review that always concludes you should hire us instead is a pitch with a fee attached rather than a review.
Most of the time the useful output is a short list of questions to put back to whoever wrote it, and quite often they can close the gaps in an email.
What to do with a proposal you cannot fully assess
Three cheap moves improve your position when you cannot fully assess a document: ask the supplier to walk you through their own terms, ask what usually goes wrong, and send the same three questions to everyone you are considering. That is an awkward position and there are three cheap moves that improve it.
Ask the supplier to walk you through the document. Not the solution, the contract terms. A supplier who can explain their own acceptance and termination clauses in plain language has thought about them. One who defers to a template they did not write is telling you the clauses may not survive contact with an actual dispute.
Ask what usually goes wrong. Any supplier with experience has a list: clients who cannot get sign-off, content that arrives late, scope that grows at the edges. A candid answer tells you what they will manage well, and a claim that nothing goes wrong tells you either they are new or they are selling.
Send the same three questions to every supplier you are considering. When is something finished, what happens on termination, and what is the final payment tied to. The variation in how those get answered is more informative than the variation in the prices, and it costs you one email each.
None of that requires expertise. It requires asking the awkward question before signature rather than after, which is a habit rather than a skill.
The five-minute version
If you do nothing else with a proposal in front of you right now:
- Search it for when something is considered finished. If that sentence is not there, that is the finding
- Find what happens on termination, to the code, the accounts and the money
- Find what the final payment is tied to, and whether it is large enough to matter
- Check whether IP assignment survives the relationship ending early
- Check whether support has a response time and an exclusions list
- Look for the assumptions and the exclusions. Their absence is informative
Then send one email asking about whatever you could not find. How that email is answered tells you as much as the document did, and often more, because a proposal is written for everybody and a reply is written for you.
If you would like a technical read on a proposal before you sign it, contact us.
References
[1] UAE Federal Decree-Law No. 25 of 2025 on Civil Transactions, in force 1 June 2026. uaelegislation.gov.ae
[2] UAE Federal Law No. 6 of 2018 on Arbitration. moet.gov.ae
[3] The Official Portal of the UAE Government, mediation and conciliation in civil and commercial disputes. u.ae
