Most buyers check a software supplier by looking at their website, glancing at a portfolio, and forming an impression during a meeting where the supplier was at their most prepared.
That process filters for presentation. It does not test whether the company exists as claimed, whether the people in the room will do the work, or how the supplier behaves when a project goes badly, which is the only condition under which you will really find out what you bought.
Most of what follows takes an afternoon, and the first two checks take five minutes.
The five-minute checks
Verify the company exists. The UAE operates the National Economic Register, a federal platform run by the Ministry of Economy and Tourism together with nine local economic departments including Abu Dhabi's and Dubai's [1][2]. You can search by business name, licence number, economic register number or business activity, and it returns the licence details the government holds.
Check three things while you are there. That the entity exists. That the trading name matches the name on the proposal, and later the name on the bank details. And that the licensed activity actually covers software development rather than general trading or management consultancy. A supplier operating outside its licensed activity has a regulatory exposure that can quietly become your delivery problem.
If the supplier is registered in a free zone, it is licensed by that zone's authority rather than the local economic department, so ask which one and verify there. That is a normal structure for technology businesses and a question about where to look, not a warning sign.
Verify tax registration. The Federal Tax Authority provides a status check on its own portal [3]. Any supplier charging you VAT should hold a valid registration. If an invoice shows VAT and the number does not verify, that is a problem for your records as much as a question about them, and it is much better found before the first invoice than during an audit.
Neither check proves competence. Both eliminate a category of problem entirely, for almost no effort, and it is surprising how rarely they get done.
A portfolio proves less than you think
A portfolio establishes that somebody was involved in a piece of work. It does not establish that this company did it, that the people still there did it, or what "did it" means.
Agencies subcontract. Staff move between firms and take their portfolio with them, quite reasonably. A screenshot demonstrates that a product exists, which was never in doubt.
So treat the portfolio as a list of things to ask about rather than as evidence. For any piece that matters to you: who on your current team worked on this, what specifically did they do, what was the hardest problem in it and how was it solved, and would that client speak to me?
That last question does most of the work. It separates projects a supplier is proud of from projects they would rather you admired from a distance.
Reference calls, asked properly
The standard reference call is useless because the standard question is useless. Asking whether somebody was satisfied invites a polite answer, and you get one.
Two changes fix it.
First, ask for the right reference. Request a client whose project was comparable in size and type, and specifically one that went through something difficult rather than one that went smoothly. A supplier who can only produce their happiest client is showing you a curated view. One willing to introduce you to a project that hit trouble and recovered is showing you something considerably more valuable, and is also telling you something about their confidence.
Second, ask better questions:
What went wrong, and how did they handle it? What would you do differently if you started again? Were the people who pitched the people who did the work? Did the final cost match the quote, and if not, why? Would you use them again for something bigger?
The last one produces more honest answers than any general rating, because it asks for a decision rather than an opinion.
If every reference is glowing, ask what the low point was rather than concluding there wasn't one. Every real project has a difficult period, and a reference who cannot recall one has either forgotten or is not describing an engagement in much depth.
Will the people pitching do the work?
This is the most common disappointment in the industry and it is entirely visible in advance.
Ask directly, in writing: who will work on this, what are their names, and what share of their time do we actually get? Then ask to meet them before signing rather than at kickoff.
Treat reluctance as the answer. A supplier confident in their team will arrange it happily, because meeting good people helps them win the work. One who deflects into process and account management may be planning to assign whoever is free when you start. Fifteen minutes with the person who would write the code tells you more than an hour with anybody else in the company.
The question about one person
Headcount matters less than concentration. What you want to know is whether more than one person would understand your system.
Ask what happens if the person leading your project is unavailable for a month. A good answer names who else knows the work, describes how it is written down, and is honest about what would slow. A vague answer, or a promise that it will not happen, is the finding.
This applies to a fifty-person agency as much as to a freelancer. Large suppliers can have exactly the same concentration risk on your specific account, and it is less visible because the company is big enough to look safe.
If your supplier is a freelancer, this stops being one item on a list and becomes the whole conversation: where the code lives, who else could pick it up, what happens if they are unavailable. Freelancers can be an excellent choice. The arrangement needs different safeguards rather than fewer.
Will they still be here in two years?
You will not get audited accounts from a small firm, and asking for them is usually unrealistic. There are still fair questions.
How long has the company been trading? Is there other committed work, or would ours be most of it? What happens to our project if our next invoice is thirty days late?
That last question is more revealing than any financial statement, because it asks about dependency rather than solvency.
A new company is not a warning sign in itself. Many are formed by experienced people leaving somewhere else, and the individuals may have long track records even where the entity does not. What matters is whether those individuals have done this work, and whether the business could survive a slow quarter without your project becoming its lifeline.
Which raises the question people avoid: is it a problem to be a supplier's biggest client? It is a risk in both directions. You get attention and priority, which is real. You also become the client they cannot afford to disagree with, which is how a supplier stops telling you when you are wrong. That second effect is subtle, expensive, and almost never discussed until afterwards.
Ask about capacity rather than client names, since confidentiality is legitimate: how many active projects, how many people, and who else is working on yours at the same time. Suppliers rarely fail because they are incompetent. They fail because they accepted more than they could deliver and did not say so.
What you are actually buying
Worth stating plainly, because it reframes every check above.
You are not buying code. Code is the cheapest thing in the transaction and increasingly the most replaceable part of it. What you are buying is judgement applied to your problem over a period of months, by specific people, under conditions neither side can fully predict at signing.
That is why a portfolio is weak evidence and a reference from a difficult project is strong evidence. The portfolio shows you the output of good conditions. The difficult reference shows you what the supplier does when an integration turns out to be twice the work, when your own team goes quiet for three weeks, or when something they estimated confidently turns out to be wrong.
Every supplier is competent on a good day. The variation between them, and the variation that costs you money, is almost entirely in how they behave on the bad ones. Do they tell you early or late? Do they propose options or excuses? Do they absorb a mistake they made, or reclassify it as a change request?
None of that appears in a proposal, and no supplier will describe themselves inaccurately when asked directly. It only becomes visible through somebody who has already lived through it with them, or through a small piece of paid work where something goes slightly wrong and you get to watch.
That is the argument for spending your due-diligence effort on references and a trial rather than on studying documents. Documents describe intentions. The other two show you conduct.
The warning signs, ranked
A quote produced without any questions being asked. A refusal to name who will do the work. Reluctance to provide any reference at all. Pressure to sign quickly for a discount that expires. A portfolio that cannot be discussed in specifics. And, most tellingly, answers that become vaguer the more precisely you ask.
None of these is fatal on its own. Two or more together usually is.
The inverse is also true, and worth valuing when you see it. A supplier who asks searching questions about your business, your constraints, and what happens when things go wrong is trying to work out what you actually need. A supplier who produces a number without asking anything has either built this exact thing before, which they should say, or is guessing, and will discover the truth using your budget.
Test delivery, not description
Every check above verifies a claim. Only one tests behaviour: give them a small piece of paid work first.
Make it small enough to finish in days, real enough to matter, and specify it the way you would specify the real project. A genuine fix you need, a small feature you actually want, an integration you would have to do anyway. Pay properly for it rather than asking for free work, because what you are observing is how they behave when engaged, not how they behave when auditioning.
What you learn: how they scope it, what they ask before starting, whether the estimate held, what arrived against what was promised, and how they communicated when something was unclear. That is a fair preview of the project, and it costs a fraction of it.
Scaling the effort to the stake
Not every engagement justifies every check, and running all of them for a small piece of work signals the wrong thing about how you will be to work with.
For anything below the point where losing the money would be painful rather than merely annoying, the registry check and the tax check are enough. Five minutes, and they eliminate the failure mode where the entity is not what it claims to be.
Above that, add references and a conversation with the person who will do the work. Perhaps two hours of your time, and it addresses the two most common disappointments: a supplier whose real track record is thinner than the portfolio suggests, and a delivery team who turn out to be different people from the ones you met.
Where a wrong choice would cost you months as well as fees, add the paid trial. The arithmetic at this tier is obvious: a few thousand dirhams spent finding out how somebody actually works, set against a much larger decision otherwise made on impressions.
And for a long-term or business-critical dependency, add the contract terms below and the capacity questions above. At that level you are not choosing a supplier for a project. You are choosing who your business depends on, and how you would leave matters as much as how you start.
Before you sign
Four contract points are much easier to agree at the start than to negotiate once a relationship has soured: code ownership, access to accounts and infrastructure, what happens on termination, and what a handover has to include. Our guides on who owns your code and the accounts your business must own cover those, and changing your development agency covers what a handover should contain.
If the supplier is registered outside the UAE, none of the registry checks above apply. Find the equivalent public register in that jurisdiction and think carefully about which country's courts would hear a dispute. Our guide on Dubai agencies versus offshore teams covers that trade-off properly.
Scale the effort to the stake. The registry and tax checks take five minutes and are always worth doing. References and meeting the team are proportionate once losing the money would genuinely hurt. A paid trial makes sense when a wrong choice costs you months as well as fees.
We can review the technical side of a proposal, meaning whether the approach is sound, whether the scope matches the price, and what is missing that will surface in month three. That starts from around AED 1,500 with us and final pricing depends on scope. These are our own figures rather than a market survey.
If you only do one thing beyond the registry check, speak to a client whose project went wrong and recovered. Every other check verifies a claim. That one shows you how a supplier behaves under pressure, which is the thing you are actually buying.
References
- UAE Government, National Economic Register
- Ministry of Economy and Tourism, enquire about a commercial companies licence
- Federal Tax Authority, status check
- UAE Government, verify business licences
- SKIMBOX, who owns your code in the UAE
- SKIMBOX, the accounts your business must own
- SKIMBOX, changing your development agency in the UAE
- SKIMBOX, Dubai agency versus offshore team
- SKIMBOX, why app quotes vary in the UAE
Government services, registries and their access requirements change. Check the linked official pages directly rather than relying on this article for procedure. This is not legal advice.
