How to choose an AI development company in Dubai

Search for an AI development company in Dubai and you get lists. Every list is written by a company on it. None of them tell you how to tell the good ones apart, because that is not what a list is for.

This page is the other thing. Eleven questions to ask any company you are considering, including us, and what a real answer sounds like. Ask all eleven of three shortlisted companies and the decision usually makes itself.

Start by naming the job, not the technology

Before you speak to anyone, write one sentence: the thing that will be different in this business ninety days after this project is finished.

Not "we will use AI." Something like: "every enquiry gets a grounded reply within two minutes instead of four hours," or "the monthly board pack builds itself from the source systems instead of taking three days."

That sentence is your specification and your acceptance test. A company that cannot restate it back to you in their own words, with the systems it touches named, has not understood the job. Every question below is really a way of checking whether they can build to that sentence.

The eleven questions

1. What have you put into production, and what broke?

Demos are cheap now. Anyone can build one in a weekend. The distance between a demo and a system your staff use every Tuesday is where the money and the risk sit.

A good answer names a live system, says how long it has been running, and describes a real failure and what changed because of it. A weak answer is a portfolio of screenshots.

2. Who owns the accounts?

Every model provider account, cloud account, database and domain should be in your company's name, with your billing attached, from day one.

This is the single most expensive detail buyers skip. If the accounts sit with the vendor, you are renting your own system, and the switching cost is total. Ask for it in writing before work starts. It is much harder to unwind afterwards.

3. What is the monthly running cost, all of it?

An AI system has two bills: a build cost and a monthly running cost. Most quotes show the first and stay quiet about the second. The running cost has four parts: model usage, hosting, monitoring, and maintenance.

Ask for all four as numbers. Then ask where the spending cap lives and what happens when it is hit. A system with no cap has no ceiling on its monthly cost.

4. Where is the boundary between code and the model?

This is the question that separates engineering from prompting.

Any number a customer or a board sees should be computed by code, not generated by a model. The model's job is to explain and to write, not to do arithmetic. If a company cannot tell you where that line sits in their architecture, your numbers will eventually be wrong in a way nobody catches.

A good answer sounds like: "the figures come from a query, the model writes the sentence around them, and a test fails the build if a figure ever comes from the model."

5. What does the test suite check, and can we watch it run?

Ask to see it run on a call. Not the code, the run.

For anything customer-facing, there should be tests that actively try to make the system misbehave: quote a price that does not exist, promise a date it cannot meet, answer a question it has no grounds for. If the only tests are "does it start," the guardrails are decoration.

6. What watches it when nobody is looking?

The expensive failure is the quiet one. A provider account runs dry, every run fails, and a quiet Tuesday looks exactly like a working one.

A good answer describes alerting on the specific errors that mean an account is empty or a job has stopped, and names who receives that alert. A weak answer is "we monitor it."

7. How will you measure whether it worked?

Agree the measurement before the build, and agree where the number comes from. First-reply time read from the message table. Hours per month read from the process it replaced. Error rate read from the log.

If the measurement is invented after delivery, it will be invented to flatter the delivery.

8. What is the plan for the data that leaves the country?

Most model providers process data outside the UAE. That is workable and normal, and it is also something you should have decided on purpose rather than discovered later.

Ask which provider, which region, what is sent, what is stripped before sending, and what is retained. Anyone building for a UAE business should be able to answer without going away to check. If a free zone regulator, a bank or a healthcare licence is in the picture, that answer needs to exist in writing.

9. Who does the work, and where?

Ask who will actually be in your repository. Some companies sell a Dubai relationship and deliver through a rotating offshore bench, which is fine if it is disclosed and priced honestly, and expensive when it is not.

You want a named person who is accountable for the build, reachable in your working hours, and still there at handover.

10. What happens at handover?

At the end you should have: the code in your repository, the accounts in your name, a written runbook for the three things most likely to break, and a person on your side who has been shown how to change the parts that change often.

A weak answer treats handover as a support retainer. A retainer is a fine option. It should be a choice, not the only way to keep the system alive.

11. What would you tell us not to build?

The answer reveals whether you are talking to an engineer or a salesperson.

Plenty of projects that arrive asking for an agent are better served by a simple automation at a fraction of both bills. A company that has never once talked a client out of the larger project has not been paying attention to whether the projects worked.

The three red flags that cost the most

A fixed price with no written scope. The price is not the commitment. The scope is. A fixed price attached to a vague scope means the scope will be interpreted against you the moment the project gets hard.

Accounts in the vendor's name. Covered above, and worth repeating, because it is the one that is nearly impossible to fix later.

No running cost in the proposal. Either they have not thought about it or they would rather you did not. Both are reasons to keep looking.

A note on lists and rankings

Directory rankings mostly measure who filled in the directory's form and who paid for placement. They are a source of names, not a source of judgement. Use them to build a shortlist of three, then use the eleven questions to choose between them.

Reviews are more useful when you can see the reviewer's company and the year. Best of all is a reference call with a client who has been live for more than six months, because that is the client who has seen the running cost, the first incident, and the handover.

Where we sit

Decifer is a Dubai company. We build AI systems that run daily operations, and we run our own products on the same method, which is where the examples in the questions above come from. Our standing rules are the answers we give to questions 2, 4, 5 and 6: your accounts, code computes the numbers, guardrails have tests, and something watches the system when nobody is looking.

If you want the questions answered against your specific project rather than in general, the two-week assessment does that at a fixed fee and produces a scope, a build cost and a monthly running cost you can take to any company on your shortlist, including one that is not us.