Choosing a development partner is a commercial decision with technical consequences. The wrong choice rarely fails immediately. It fails a year later, when the platform cannot be extended, the code cannot be handed over, or the supplier has become the only party able to maintain it.
The UAE market makes this harder to assess than it appears. Suppliers range from single-person studios to regional arms of international firms, proposals use different definitions of the same scope, and the visible evidence is often a portfolio of websites rather than the enterprise systems a buyer actually needs. A structured evaluation surfaces those risks before a contract is signed.
Start with the problem, not the portfolio
A portfolio tells you what a company has built. It does not tell you whether their approach fits your requirement. Ask instead how they would approach your specific constraint, and listen for whether the answer engages with the commercial objective or jumps straight to technology.
A supplier who asks about the operating process, the people who will use the system and what happens today is more useful than one who presents a similar-looking application and a price. The difference shows up later as change requests, because the supplier who understood the process priced the work that actually exists.
Technical experience that matches the requirement
Check depth in the specific area that matters. A team strong in marketing websites is not the same as a team that has built multi-tenant products, integrated ERP systems, or handled payment and settlement logic.
Useful questions:
- What comparable systems have you built, and what were the hardest parts?
- How do you handle permissions and multi-organisation access?
- What is your approach to testing, and can I see evidence of it?
- How do you manage deployment, and how often do you release?
- What would you do differently on a project like ours, having done it before?
The last question separates teams who have delivered from teams who have watched delivery. A specific, slightly uncomfortable answer is a better sign than a confident general one.
Commercial understanding
Development decisions have cost consequences that a purely technical team may not weigh. A supplier who understands your revenue model will question features that do not affect it, and will tell you when a simpler approach serves the business better.
Look for evidence that they will push back. A partner who agrees with everything in the first meeting is usually pricing the ambiguity later.
Architecture and maintainability
Ask how the system will be structured and why. You are listening for a documented approach to the data model, service boundaries and integration, not a list of frameworks.
Two practical checks. First, ask what the codebase will look like to another engineer in two years. Second, ask which decisions are expensive to reverse: tenancy model, identity provider, hosting region, database choice. A supplier who cannot name those decisions has not made them yet.
Security, data residency and data protection
Expect concrete answers rather than assurances. Which data will be stored, where, who can access it, how access is logged, how secrets are managed, what happens on a breach, and how backups are tested.
For UAE organisations there are specific dimensions worth raising early. The federal framework is Federal Decree-Law No. 45 of 2021 on Personal Data Protection, and financial free zones such as the DIFC and ADGM operate their own data protection regimes. The practical questions are where the data will physically reside, which regime the processing falls under, what processing terms the supplier will sign, and whether any part of the system sends data to a third-party model or analytics provider outside that arrangement.
A partner who cannot answer clearly at this stage will not answer clearly during an audit.
Ownership of source code and data
Confirm in writing. You should own the code, the data and the infrastructure configuration, and hold direct access to repositories, cloud accounts and domain records. Arrangements where the supplier retains the repository or hosts under their own account create leverage you do not want.
Also clarify the position on third-party components and licences, and whether any part of the system depends on the supplier's proprietary tooling. If a component is licensed rather than owned, the cost of that licence after handover belongs in the comparison.
Engagement models compared
The commercial structure matters as much as the technical capability. These are the three arrangements used most often for custom software:
| Model | How it works | Suits | Main risk |
|---|---|---|---|
| Fixed price | Scope and milestones agreed up front, paid per delivered phase | Well-specified work with stable requirements | Change requests become a negotiation each time |
| Time and materials | Paid for effort against a prioritised backlog | Evolving requirements and discovery-heavy work | Scope discipline depends on you |
| Dedicated team | Named team and monthly capacity retained | Long-lived products with continuous delivery | Requires internal product ownership |
Most first builds suit fixed price by phase rather than fixed price for the whole programme, because the later phases cannot be specified honestly until the earlier ones exist. Products that will keep evolving tend to move to a dedicated team once the core is stable.
An evaluation scorecard
Score candidates on evidence rather than impression. A workable set of criteria:
| Criterion | Evidence to request | Warning sign |
|---|---|---|
| Technical fit | Architecture of a comparable system, and the trade-offs taken | Framework list offered as an answer |
| Architecture thinking | Written data model and integration approach before build | Design deferred until after contract |
| Security and data handling | Access control model, logging, backup and restore test results | Verbal assurance with no documentation |
| Commercial judgement | Questions asked about the revenue model | Scope accepted without challenge |
| Delivery process | Release cadence, testing evidence, demo history | No demonstrable rhythm |
| Ownership and exit | Repositories and cloud accounts in your name, documented handover | Hosting held under their account |
Project scope and milestones
A credible proposal defines what is delivered at each stage and what constitutes acceptance. Be wary of a single lump-sum figure covering an undefined scope, and equally of an open-ended time-and-materials arrangement with no milestones.
Phased delivery with defined outcomes keeps both sides honest: you see working software, and the supplier is paid for what has been demonstrated. Acceptance criteria should be written in terms of behaviour a user can observe, not documents produced.
Maintenance and support
Ask what happens after launch. Who fixes defects, how quickly, and at what cost? How are dependency and security updates handled? What happens if you want to move to another supplier?
A confident answer includes documentation and a defined handover, not a renewal proposal. Ask for the support terms in the contract, with response expectations stated for severity levels rather than a general commitment to respond promptly.
Pricing considerations
Compare proposals on the basis of what is included, not the total alone. A lower figure that excludes migration, testing, deployment or support is not comparable with one that includes them.
Reasonable things to ask: what is the cost of a change request, what is the day rate behind a fixed price, and what would cause the price to move. A supplier who cannot explain their own pricing has not modelled the work. Extend the comparison across three years, including hosting, licences and support, because a lower build cost with higher running costs is not a saving.
How to run the selection process
- Write a requirements brief: users, workflows, constraints, systems to integrate, compliance position and the commercial outcome.
- Shortlist three to five suppliers with demonstrable depth in your category of system, not general capability.
- Hold a technical conversation with the person who will architect the work, not only with sales.
- Require a written proposal with phases, acceptance criteria and explicit exclusions.
- Take reference calls with clients whose systems resemble yours, and ask what went wrong.
- Agree ownership, intellectual property, data processing and exit terms before the first invoice.
Two to three weeks spent on that sequence is usually cheaper than the first change request on a badly matched engagement.
A practical vendor checklist
- Written scope with defined acceptance criteria per phase
- Named team, with clear roles and who is accountable
- Architecture documented before build starts
- Source code, data and infrastructure in your accounts
- Evidence of testing and a release process
- Security and data handling described concretely
- Defined support arrangement after launch
- Change control process for scope
- Handover and documentation commitment
Red flags
A guaranteed price before any discovery. No interest in the business outcome. Reluctance to put ownership terms in writing. A single person responsible for everything with no documentation. Refusal to show previous work in detail.
Frequently asked questions
What is the difference between a software development company and a technology consultancy?
A development company builds to a specification. A consultancy defines what should be built, tests whether the specification is right, and can assess the technical work of others. Engagements where the requirement is still forming usually benefit from the second before committing to the first.
Should we choose a UAE-based company or an offshore team?
The practical considerations are time zone overlap, contractual enforceability, data residency and the cost of senior attention. A local team is easier to hold to a delivery rhythm; a distributed team can be better value at scale. What matters most is whether the architect is directly involved rather than passing work down a chain.
How much does custom software development cost in the UAE?
Cost follows scope, integration count and the amount of change the business expects after launch. We set out the drivers and how to compare proposals in our guide to custom software development costs in Dubai.
What contract terms matter most?
Ownership of code and data, acceptance criteria per phase, change control, data processing terms, support commitments and an exit clause that obliges documentation and handover.
How long should an evaluation take?
Two to three weeks for the sequence above. A longer process rarely improves the decision; the constraint is usually evidence, not time.
What if we already have a partner and want a second opinion?
A technical assessment of the architecture, the codebase and the delivery plan is often enough to identify whether the current approach will hold. That is standard work for our technology and business consultancy practice.
Key takeaways
Evaluate for technical fit, commercial judgement, ownership and post-launch clarity. Insist on phased scope with defined outcomes, confirm in writing that you own the code, the data and the accounts it runs in, and check that the supplier can describe where your data sits and under which regime it is processed.
Next step: if you want a second opinion on an approach or a proposal, our technology and business consultancy covers technical assessment and partner due diligence. For delivery itself, see custom software development and how we build SaaS platforms. You can also speak to Sardo Group directly.