Pick the Engagement Model Before You Write the Scope
Custom software is bought in three fundamentally different ways, and choosing wrongly costs more than choosing the wrong supplier. A fixed scope contract suits work that is genuinely well understood, such as replacing a system whose behaviour you can document line by line, and it prices the supplier's risk into the number. Time and materials suits work where discovery is part of the job, and it transfers that risk back to you, which only works if you have someone able to steer it weekly. A dedicated team arrangement suits a long programme where you want continuity and are effectively renting capacity.
Say which model you want in the request, and be honest about whether you have the internal capacity the model assumes. Most disputes trace back to a fixed price signed against a vague specification, then reopened as a change request every fortnight. If the requirements are not stable, do not buy certainty you cannot describe.
Where the Engineers Sit Changes the Risk You Carry
Many software firms selling here hold a client facing team locally and run delivery from an engineering centre in another country. That is a legitimate and often excellent model, and it changes what you should check. Ask how many of the named people in the proposal are employees of the company you are signing with, which are contractors, and how many hours of overlap your teams will share each day. Ask whether documentation and code comments are maintained in English.
Staff continuity deserves specific attention. Much of the technical workforce is here on employment sponsored residency, so a resignation is often a departure from the country rather than a move down the road. Require notice of any change to named staff, a handover period, and a replacement of equivalent seniority at no additional cost. Ask what the company's own attrition looked like over the past year and how knowledge is retained when someone leaves.
Put the Intellectual Property Assignment in Writing
Do not assume that paying for development makes you the owner of everything delivered. Assignment needs to be explicit, it needs to cover subcontractors and individual developers rather than only the contracting entity, and it needs to survive termination. Where a supplier brings its own framework or accelerator, you need a clear, perpetual, transferable licence to keep running and modifying it, or you need it excluded from the build.
Ask for an inventory of open source components with their licences before the final payment, because permissive and reciprocal licences impose very different obligations if you later distribute or resell the product. For systems your operations depend on, consider a source code and deployment escrow arrangement with defined release triggers. Also confirm that you own the data, the schema and the integrations, not just the application code.
Security Review Starts Earlier Than Software Buyers Expect
If your customers include banks, insurers, healthcare providers or government linked entities, their security teams will review your supplier's practices, not only yours. Recognised information security certification, documented secure development practices, background checked staff, and clear answers on where source code and customer data are stored become qualifying criteria rather than nice to have.
Build the review into the plan: a threat model at design stage, secrets management from the first commit, an independent penetration test before go live with a retest after remediation, and agreed handling for any finding rated critical. Federal data protection rules and the stricter regimes inside the financial free zones also shape architecture decisions such as hosting region and cross border transfer, so raise them at the design workshop rather than during user acceptance testing.
Integration With What You Already Run Is the Real Scope
Very little enterprise software is built on empty ground. The finance system, the customer records, the payroll and human resources platform, the point of sale, the warehouse system and whatever spreadsheet quietly runs a critical process all have to connect. Interfaces, data migration and reconciliation routinely take longer than the new functionality, and they are the part most often left out of a proposal.
Inventory the systems in the brief, note which vendors control each interface and whether their licences permit access, and ask candidates to price integration and migration as named line items. Tax compliant invoicing and reporting requirements belong in that list. Ask who is responsible for cleaning the legacy data, because the answer is usually you and the effort is usually underestimated. Agree as well how the two systems will run alongside each other during cutover, how long that parallel period lasts, and which set of records is authoritative while it does, since an undecided answer to that question is what turns a switchover weekend into a month of reconciliation.
Acceptance Criteria Prevent the Slow Ending
Custom software projects rarely fail loudly. They drift toward a state where the supplier considers the work delivered and the client considers it unfinished, and neither position is written down anywhere. The cure is dull and effective: testable acceptance criteria per deliverable, a defined user acceptance period with named testers from your side, defect severity classes with fix times attached, and a warranty window after go live.
Tie payment milestones to acceptance rather than to elapsed time or code delivery, and agree what performance under realistic load means before the load test is run. Keep a written change process with a small standing budget for adjustments, since pretending nothing will change produces a worse outcome than planning for it.
Read the Contracting Entity, Not the Logo on the Deck
The company pitching is not always the company that signs. Groups operating here often hold several licensed entities, some in free zones and some on the mainland, alongside offshore delivery subsidiaries, and the one named in your agreement determines who is actually liable, which activities it is licensed to perform, and how easily you can enforce anything. Check that the entity on the contract is the one whose references and certifications you reviewed.
Settle the commercial mechanics in the same pass. Agree the currency and the payment terms, confirm that invoicing meets your tax reporting requirements, and be explicit about which jurisdiction governs the agreement and how a dispute would be resolved, since local courts, the free zone courts and arbitration are all common choices with very different timelines and costs. Tie any advance payment to a deliverable rather than to signature, and hold a meaningful portion until acceptance.
Software Buyers in Dubai Choose Between Two Supplier Pools
At one end sit international consultancies and systems integrators with regional offices, strong governance, formal procurement processes and prices that reflect all of that. They fit multi year programmes with heavy compliance and multiple stakeholders. At the other end sit independent software firms, many of them licensed in the technology free zones, with smaller senior teams, direct access to the people writing the code and far more flexibility on how the work is shaped.
The mistake is comparing a proposal from one pool against a proposal from the other on price alone. They are priced for different risk. Decide first how much governance your project genuinely needs, then shortlist within one pool and compare like with like. Check the trade licence activity, ask for two references on projects of comparable size, and call them.
Sending One Brief to Several Firms
A comparable tender needs the same inputs for everyone: the business problem, the systems to integrate, the compliance constraints, the engagement model you intend to use, the acceptance approach and the support expectation after launch. Ask each supplier to propose a team with named roles and to state what it would do in the first month. Vague staffing in a proposal becomes vague staffing on the project.
Where the deliverable is mainly a customer facing product, compare against application developers and web engineering firms, whose pricing for that shape of work is usually lower. If the hard part is a model rather than a workflow, talk to machine learning specialists as well. Verified profiles, licences and client references for software companies are listed on Edvido, and you can issue a single brief to a shortlist so the proposals arrive in a form you can actually score.