The gap between a demo and a system
A working demo and a production system are separated by most of the actual engineering.
A demo needs a model that performs well on a curated dataset. A production system needs data pipelines that survive upstream schema changes, monitoring that catches quality drift before users do, a rollback path for when a new model version is worse than the old one, latency low enough for the interface it sits behind, and a fallback for the cases the model handles badly.
Candidates who have only done the first often interview extremely well. They can discuss architectures, cite recent papers, and show impressive notebooks. The distinguishing question is not what they have built but what they have operated: what broke after deployment, how they found out, and what they changed.
What to actually assess
Production experience over credentials
Ask for a system that has been live and serving real users, then ask what went wrong with it. Every genuinely deployed system has a failure story. A candidate with no failure story has either not deployed anything or is not being straight with you.
Certifications and course completions indicate exposure, not capability. We have written elsewhere about certifications versus real projects; the short version is that a portfolio of shipped work outranks any credential.
Knowing when not to use machine learning
The most valuable trait in an AI developer is the willingness to say a problem does not need AI.
A large share of business problems presented as machine learning problems are better solved with a database query, a rules engine, or a well-designed form. An engineer who reaches for a model in every case will build you something expensive, opaque, and harder to maintain than the alternative it replaced.
In an interview, describe a problem that plainly does not need ML and see whether the candidate says so.
Data reality, not data ideals
Qatari organisations rarely have the clean, large, English-only datasets that public benchmarks assume. Real data here tends to be bilingual, inconsistently structured, smaller than textbook examples require, and subject to confidentiality constraints that rule out sending it to a third-party API.
Ask candidates what they would do with three thousand mixed Arabic and English records rather than three million clean English ones. The good answers involve careful evaluation design, transfer learning, synthetic augmentation, and honest scoping. The weak answers assume the data problem is somebody else's.
Evaluation design
Ask how they would know the system is working. A candidate who answers only with accuracy has not thought hard enough. Production evaluation involves choosing metrics that match the business consequence, understanding the cost asymmetry between false positives and false negatives, and building a way to measure quality on live traffic rather than only on a held-out set.
Communication
An AI system that stakeholders do not trust does not get used, regardless of its metrics. The developer needs to explain to a non-technical executive what the system does, where it is unreliable, and what it should not be relied on for. This is a core competency here, not a soft skill, and we have covered it separately in communication skills in AI teams.
Local hire, remote hire, or engaged team
Qatar's AI talent pool is genuinely small. Pretending otherwise leads to a search that runs for months and ends in a compromise hire.
Local hire gives you someone in your timezone who can sit in the room, understands the local business context, and is available for the informal conversations where requirements actually surface. The constraint is availability and cost; the candidates worth hiring have options.
Remote hire widens the pool enormously and is entirely workable for engineering roles, provided there is genuine overlap in working hours and clear written communication. We have covered the practicalities in hiring remote AI developers. The risk is that a remote individual contributor with no local context can build something technically correct that does not fit how the organisation works.
Engaged team suits organisations that need a system delivered rather than a permanent capability built. It removes the hiring risk and the single-person dependency, at the cost of the knowledge living partly outside the organisation. It is the right choice when the AI work is a project with an end, and the wrong choice when AI is becoming central to how the business operates.
There is no universally correct answer. The question to settle first is whether you are building a capability or delivering a project, because that determines which of the three makes sense.
The confidentiality constraint
One consideration specific to Qatar, and to regulated sectors anywhere: a significant amount of AI work here involves data that cannot be sent to a foreign API.
Legal documents, medical records, financial data, and government correspondence often carry contractual or regulatory restrictions on cross-border processing. An AI developer whose entire toolkit assumes calling a hosted model over the internet will be blocked by this, or worse, will not notice the constraint until after the data has left.
Ask candidates directly how they would build a system where document content cannot leave the organisation's infrastructure. The answer requires knowledge of locally-run models, which is a distinct skill set from prompt-driven API integration. It is the same constraint that led us to build ForeThought with an on-device assistant rather than a cloud one.
Frequently asked questions
QWhat does an AI or ML developer cost in Qatar? A: It varies widely with production experience, and the gap between someone who has deployed and maintained systems and someone who has completed courses is large enough that a single figure would mislead. Judge cost against the alternative of a failed project, which is the more expensive outcome by a wide margin.
QIs a computer science degree necessary? A: No. Demonstrated production work matters more. Some of the strongest practitioners come from mathematics, physics, or engineering backgrounds, and some come from none of those.
QShould I hire a data scientist or an ML engineer? A: A data scientist typically analyses and models; an ML engineer typically builds and operates the systems that serve models. If you need something running in production, you need the engineering skill set, either in one person or across two.
QCan one developer handle an AI project end to end? A: For a contained project, sometimes. For anything that needs to stay running, a single-person dependency is a serious operational risk, because the knowledge leaves when they do.
QHow long before an AI project delivers value? A: A well-scoped project on data you already hold can show useful results in weeks. A project that requires new data collection, labelling, or infrastructure runs to months. Anyone promising transformation in days is selling a demo.
QWhat if my data is confidential and cannot leave Qatar? A: That constrains the architecture but does not prevent the project. It means locally-run models rather than hosted APIs, which is a narrower but entirely viable set of options. Raise it at the start, because it changes the design.
QDo I need AI at all? A: Often not, and a developer worth hiring will tell you so. Many problems presented as AI problems are better served by conventional software.
Working with us
Louis Innovations builds and operates AI systems in Doha, including systems constrained to run entirely on local infrastructure where data cannot leave the organisation. We have written extensively on AI implementation in Qatar and on what separates AI developers from general software engineers.
If you are deciding whether to hire, engage a team, or whether the problem needs machine learning at all, we are willing to give you a straight answer on the last question even when it costs us the work. Contact us at info@louis-innovations.com.
Louis Innovations is Abtikarat Louis Trading and Services (CR No. 173808), based in Doha, working across software, AI, and infrastructure.