Most software disputes are not about bad code. They are about a sentence nobody wrote down: whether the second report was in scope, who owns the source code, what "finished" means, who pays when the client changes their mind in week nine. A contract that answers these questions in plain words protects both sides and, in our experience, makes projects calmer. This checklist is for UAE buyers reading a proposal or a draft agreement. It is general information, not legal advice, so have a lawyer review the final text.
1. Scope that can be tested
A scope written as "a complete ERP" cannot be tested. A scope written as a list of functions, each with a sentence on what the user can do, can. The best proposals attach a specification with screens or at least a feature list, and a short list of exclusions. If it is not in the specification, it is a change request. Our project brief template helps you write the starting document.
2. Change control
- Changes are requested in writing, estimated in hours or days and approved before work begins.
- The estimate states the effect on delivery date.
- Small clarifications that do not change the function are not charged, and the contract says what counts as small.
3. Acceptance
Define how a milestone is accepted: a set of test scenarios run by your team in a test environment, a fixed review period such as ten working days and a rule for what happens if you say nothing. Without a review period, nothing is ever accepted; without a deemed-acceptance rule, a vendor cannot close a milestone. Use the approach in user acceptance testing.
4. Payment tied to milestones
| Stage | Common arrangement |
|---|---|
| Start | An advance that funds discovery and setup |
| Delivered and accepted modules | Instalments released on acceptance of each module |
| Go-live | A final instalment after the system runs in production for a defined period |
| Retention | A small share held until the warranty period ends |
Compare models in engagement models and plan the money in how to budget for a software project.
5. Source code, ownership and licences
State clearly who owns the code written for you, whether you receive the source code and when, and what the vendor may reuse. Third-party libraries keep their own licences, so ask for a list. If the vendor retains ownership of a core product and licenses it to you, the licence should be perpetual for your use, cover your own company and affiliates as needed and not depend on a monthly fee for the system to run.
6. Warranty and support
Warranty usually covers defects in delivered functions for a period after go-live. Support is a separate service with response times and a price. Spell out both, together with hosting responsibilities, backups and upgrades. The reading guide in software maintenance contracts shows what a good support clause looks like.
7. Data, confidentiality and exit
- Your data belongs to you and can be exported in a standard format on request.
- The vendor keeps your information confidential and limits staff access.
- If the relationship ends, the vendor hands over code, documentation, credentials and a reasonable transition period.
- Where data is hosted and who can access it should be written down; see data residency.
Red flags
Be careful when a proposal is only a price and a delivery date; when the vendor refuses to name the people who will do the work; when payment is almost entirely in advance; or when source code access is offered only for an extra fee later. Ask us to review a proposal you received, and we will tell you what is missing.