What to Ask Before Hiring an AI Development Agency in 2026 (Gulf Founders Guide)
53.8% of software projects suffer scope creep. In the Gulf, where most founders lack technical backgrounds, the wrong AI agency can cost you 12 months and your Series A story. These 10 questions change the outcome.
What to Ask Before Hiring an AI Development Agency in 2026 (Gulf Founders Guide)
In 2024, a founder we will call Maciej hired an AI development agency that came highly recommended. The website was polished. The case studies looked impressive. The discovery call lasted 90 minutes and covered all the right topics. By month three, the team had consumed $300,000 of his seed round and delivered a system that crashed under load, had no tests, and used an architecture that the next agency quoted $150,000 to rebuild from scratch.
Maciej is not unusual. GoodFirms' industry survey documents that 53.8% of software development projects experience scope creep — meaning more than half of all engagements deliver less than what was promised, cost more than was quoted, or both. The average AI project engagement runs 4.5 months and costs $36,000 at the mid-market level. The agencies that blow those numbers are not always bad actors. Many of them simply lack the engineering depth their marketing implies.
In the Gulf markets — Saudi Arabia, UAE, Qatar — where the majority of founders do not have technical backgrounds and the AI agency landscape has exploded with agencies of wildly varying capability, the selection problem is acute. This guide is for non-technical Gulf founders who need to evaluate AI development agencies without being able to read their code.
Part 1: The Agency Landscape — Real Capability vs. Rebadged Services
The first thing to understand about the 2026 AI agency market is that it has two distinct populations separated by a quality gap that is invisible from the outside.
Population 1: Genuine AI engineering firms have teams who understand machine learning fundamentals, have built systems that use LLMs in production at scale, can reason about context windows and hallucination failure modes, and have encountered and solved the hard operational problems — rate limiting, cost management, latency, output validation — that only emerge when AI systems handle real user traffic. These firms usually have open-source contributions, technical blog posts written by engineers (not marketers), and case studies that include failure stories alongside successes.
Population 2: Rebadged web development shops learned to include "AI" in their service descriptions after 2022. They can build a frontend that calls the OpenAI API. They may deliver something that works in a demo. They will not have solved the production engineering problems. They will tell you their system "uses GPT-4" as if that were an architectural statement rather than a vendor selection. When you ask about their agent orchestration approach, they will describe prompt engineering. When you ask about state management in their agent systems, the conversation will stall.
The Gulf context makes this harder to navigate than, say, London or Singapore. The trust networks that normally filter agency quality — word-of-mouth from founders who have been through the same process, shared technical communities, visible open-source contributions — are thinner and younger here. A startup ecosystem that has been growing at its current pace for only five to seven years does not yet have the density of experienced founder peers who can give you reliable referrals.
There is a third category worth naming: international agencies with Gulf-specific practices. These are firms headquartered in Vietnam, Eastern Europe, or Southeast Asia that have dedicated teams serving Gulf clients and have invested in understanding Gulf-specific requirements — Arabic language support, local payment gateway integrations, Sharia-compliance patterns for fintech products. ODSEA is in this category, with offices in Ho Chi Minh City and experience delivering for Saudi, UAE, and Qatar clients. We are not the only firm in this category, and you should evaluate us by the same standards this guide recommends applying to any agency.
Part 2: The 10 Questions for Every Discovery Call
These questions are designed to surface answers that a non-technical founder can evaluate. They do not require you to understand code. They require you to listen for specificity, humility, and evidence.
Question 1: Walk me through a project that failed. What went wrong and what did you change?
This is the most important question in the set. Every agency has projects that did not go as planned. The question is whether they can talk about them honestly. An agency that claims a perfect track record is either very new or not being truthful. What you are listening for: a specific project (not a vague "we once had a client who..."), a clear description of what went wrong, an explanation of their role in the failure, and a concrete change they made to their process as a result.
Question 2: What does your team look like, and are they employees or contractors?
This matters for two reasons. First, an agency whose "team" is a network of freelancers assembled per project will have wildly variable quality and no institutional knowledge that carries forward. Second, and more importantly for Gulf clients: is the team actually working on your project, or is the agency a sales front that outsources delivery to another party? Many Gulf founders have paid "agency A" only to discover their work was being done by "freelancer collective B" that the agency had no visibility into.
What to listen for: specific names, titles, and years of experience. How many engineers are full-time employees? What is the average tenure? Can you meet the actual team members who will work on your project before signing?
Question 3: How do you handle Arabic language requirements?
If you are building for a Gulf market, Arabic is not optional. It affects UI layout (right-to-left rendering), database design (Unicode handling, collation rules), search functionality (Arabic morphology is dramatically different from English), and AI feature behavior (LLM quality in Arabic is meaningfully worse than in English for most models). An agency that has not thought carefully about Arabic in production will give you a vague answer about "using UTF-8" or "setting the direction attribute." An agency with real Gulf experience will talk about RTL CSS frameworks, Arabic font rendering, LLM prompt engineering for bilingual outputs, and the specific challenges of Arabic search indexing.
Question 4: What is your discovery process and what does it cost?
Legitimate agencies offer a structured discovery process before quoting a project. Discovery involves analyzing your requirements, identifying ambiguities, producing a technical specification, and estimating scope. It takes time and expertise. It should cost something — typically $1,500 to $5,000 depending on project complexity. An agency that skips discovery and quotes from a one-hour meeting is either very experienced with your specific problem type (ask them to prove it with references) or is planning to scope-creep you later. The GoodFirms data showing 53.8% scope creep is largely attributable to inadequate discovery.
What a good answer looks like: "Our discovery phase takes two to three weeks, produces a technical specification and wireframes, and costs $X. That cost is deducted from the project fee if you proceed with us. If you do not proceed, you own the specification and can take it to any other agency."
Question 5: Show me the GitHub or GitLab history for a recent project.
You do not need to understand the code. You need to see whether there is code. A project with real engineering work will have hundreds or thousands of commits, meaningful commit messages, pull requests with review comments, and a timeline that shows continuous work rather than bursts of activity at the beginning and end. An agency that cannot show you a sanitized version of a real repository — one with sensitive information removed but the commit structure and code quality visible — is not operating with the transparency you need.
Question 6: How do you test your work, and what does your test coverage look like?
This question surfaces the difference between agencies that ship code and agencies that engineer software. An agency with a real quality process will have automated test suites, a CI/CD pipeline that runs tests before any code is merged, and a staging environment that mirrors production. They will be able to tell you their test coverage percentage for a recent project and explain what types of testing they use (unit, integration, end-to-end). An agency that describes their testing as "we review the code before delivery" is telling you something important about their quality standards.
Question 7: What payment terms do you use, and how are milestones structured?
The right answer: milestone-based payments tied to demonstrable deliverables, with a structure that ensures you are never more than one milestone payment ahead of received value. A common structure is 20-25% deposit, then payments tied to specific working features — not time elapsed. Agencies that require large upfront payments or that tie payments to vague deliverables like "Phase 1 complete" rather than specific working features are structuring the engagement in their favor.
Ask specifically about escrow. Some agencies use third-party escrow services for milestone payments, which protects both parties. This is a trust signal.
Question 8: Who owns the code, and what happens to it if our relationship ends?
The answer should be unambiguous: you own everything. Source code, documentation, deployment configurations, database schemas, and any intellectual property developed specifically for your project. You should be named in the contract as the owner, and the code should be in a repository under your organization's account — not under the agency's. An agency that hedges on ownership or structures IP rights to retain leverage over you is a counterparty you do not want.
Ask also about what happens on day one of the relationship: is code pushed to a repository you control from the first commit?
Question 9: What are your Gulf-specific payment integrations?
Saudi Arabia's payment landscape requires integrations with SADAD (the government-owned bill payment infrastructure), mada (Saudi Arabia's domestic debit network with 18+ million cards), and increasingly Tabby and Tamara for BNPL. UAE has different requirements. Qatar has its own payment rails. An agency that has never built for these markets will require significant discovery time to understand the integration requirements, and their estimates will have high uncertainty. An agency with Gulf experience will talk fluently about the specific API documentation, sandbox environments, and merchant onboarding requirements for each of these payment providers.
For fintech specifically, ask about Sharia-compliance architecture. Islamic finance prohibits riba (interest) and requires specific contract structures for financial products. This affects database design, transaction processing logic, and product terminology. A real Gulf fintech developer will have a view on how to structure this at the architectural level.
Question 10: What is your NDA policy and what do you protect?
A legitimate agency will sign your NDA before any detailed technical discussion. They will have their own NDA template for projects involving sensitive business logic. They will have clear data handling policies and be able to tell you specifically where your data lives, what access controls exist, and who within their team has access to production credentials. An agency that resists NDAs or is vague about data handling is flagging a risk you should not accept.
Part 3: Red Flags That Override Everything Else
Some signals are so reliable that encountering them should end the evaluation, regardless of how good everything else looks.
Red flag: The CEO is the only technical person. If the founder is technical but all their described team members are project managers, designers, and "AI specialists" with no specific engineering backgrounds, the delivery model is contractor-based. This is not automatically disqualifying but it means there is no institutional quality standard.
Red flag: The case study is the client's testimonial, not a technical description. Testimonials are easy to obtain. A case study that describes the technical architecture, the problems encountered, the specific technologies used, and the performance outcomes achieved under real load is evidence of real work.
Red flag: They cannot describe what they would NOT build. Agencies with genuine engineering expertise will tell you when a proposed approach is wrong. They will recommend against features that are premature or over-engineered. An agency that enthusiastically agrees with every idea you describe is either telling you what you want to hear or does not have the technical confidence to push back.
Red flag: Their AI expertise is entirely based on API calls to OpenAI. Building an AI product in 2026 involves choices about LLM selection, context management, prompt engineering, evaluation frameworks, vector search, fine-tuning, and deployment architecture. An agency whose entire approach is "we use the ChatGPT API" has not engaged with the field seriously.
Red flag: No dedicated Gulf client support. Gulf business culture operates differently from Western markets. The communication cadence, relationship expectations, and meeting norms are different. An agency with no experience serving Gulf clients will have a learning curve that you pay for.
Part 4: Contract Structure for Gulf AI Projects
Once you have selected an agency, the contract is your primary protection. These are the provisions that matter.
IP assignment clause. All work product, including code, documentation, designs, and any derivative works, is assigned to you upon payment. No retained licenses for the agency. No "proprietary methodology" carve-outs that obscure what they are actually keeping.
Milestone definition and payment structure. Each milestone should define: specific deliverables (with acceptance criteria), the payment amount (typically 15-25% of project total per milestone), a review period (typically 5-10 business days), and a process for handling disputes about whether deliverables meet acceptance criteria.
Escrow for first-time engagements. On a first project with a new agency, consider requiring milestone payments to be held in escrow and released upon your acceptance of each milestone. This costs something (escrow fees) but substantially reduces your risk exposure.
Change order process. The contract must define how scope changes are handled. Every scope change should require a written change order, signed by both parties, that specifies the additional work, the additional cost, and the revised timeline. "Verbal agreements" are where $300,000 disappears.
Code quality standards. Specify that code must have automated test coverage above a defined threshold (70-80% is common for production-grade work), must pass a defined linting standard, and must be reviewed by a second engineer before delivery. Include a provision allowing you to have code quality independently reviewed by a third-party technical advisor at any milestone.
Continuation rights. If the agency relationship ends for any reason, you have the right to continue development with any other party. No lock-in through proprietary frameworks, undocumented configurations, or access controls that require the original agency to transfer.
Part 5: Evaluating a Portfolio Without Technical Knowledge
Non-technical founders often feel they cannot evaluate code quality. You can evaluate more than you think.
Ask for a working demo of a project in a similar domain. Not a video, not screenshots — a live application. Interact with it. Notice whether it handles edge cases (what happens if you enter bad data?). Notice the response time under interaction. Notice whether it works on mobile. Notice whether it feels finished or prototype-like.
Ask for the deployment architecture diagram. Any agency that has delivered a production application should be able to draw you a diagram showing where the application runs, how it scales, what happens if a component fails, and where the data is stored. You do not need to understand every component — you need to see that they have thought about it. A diagram that is a single box labeled "server" is a signal.
Ask for a code review from an independent technical advisor. Before signing a contract or at the first milestone, spend $500-1,000 to have a senior engineer review the code produced by the agency. This is the most reliable quality signal available to a non-technical founder. Technical communities in the Gulf, including ODSEA's network, can recommend independent reviewers for this purpose.
Check their open-source contributions. Real engineering teams build tools and share them. GitHub organization profiles show contribution history, public repositories, and engagement with the broader engineering community. An agency with zero public open-source presence is not necessarily bad, but an agency with genuine engineering talent typically has some public evidence of that work.
Part 6: Gulf-Specific Requirements Checklist
Before finalizing any AI agency relationship for a Gulf market product, verify coverage for each of these areas:
Arabic language support: RTL layout, Arabic font rendering, bilingual LLM prompt engineering, Arabic search indexing.
Payment integrations: SADAD (Saudi bill payments), mada (Saudi debit), Tabby (BNPL Saudi/UAE), Tamara (BNPL Saudi/UAE/Qatar), Stripe MENA configurations, local bank transfer rails.
Regulatory compliance: Saudi SAMA licensing requirements, QCB sandbox eligibility criteria, UAE CBUAE FinTech regulatory sandbox, DIFC and ADGM regulatory frameworks for UAE entities.
Sharia compliance architecture: Murabaha and Ijara contract structure patterns, riba-free product design, Sharia-compliant escrow and milestone payment models, shareholder agreement structures that pass Sharia board review.
Data residency: Saudi PDPL (Personal Data Protection Law) requirements for data stored in Saudi Arabia, UAE PDPL requirements, Qatar data protection framework. Gulf data protection laws are newer and faster-evolving than GDPR but are increasingly enforced.
Government system integrations: Absher (Saudi digital identity), Nafath (Saudi national ID verification), UAE Pass, QIYAS (Qatar), GOSI (General Organization for Social Insurance, Saudi Arabia), Mudad (Saudi payroll). A Gulf market product that requires user verification or HR integration will touch these systems.
Part 7: The ODSEA Model for Comparison
We are a Vietnam-based AI development studio with teams in Ho Chi Minh City and client coverage across the Gulf. Our model differs from the typical agency model in ways relevant to this guide.
We have a permanent team, not a contractor network. Engineers who worked on project A are available for ongoing support. We have a Tamara-specific development track because their Vietnam engineering office gave us early access to their sandbox documentation. We include discovery at cost (deducted from project fee if you proceed). Our standard contract includes the IP assignment, milestone payment, and continuation rights provisions described above. We are transparent about what we are not: we do not have a physical office in Saudi Arabia or the UAE, which matters for clients who need local presence for government procurement.
We are willing to be evaluated by every criterion in this guide. We encourage you to apply it rigorously.
Getting the Evaluation Right
The GoodFirms data is discouraging — 53.8% scope creep means the majority of software engagements underdeliver. But it is not evenly distributed. The projects that run cleanly share characteristics: thorough discovery before any code is written, milestone-based payments with clear acceptance criteria, IP rights clearly assigned from day one, and ongoing code quality verification.
The 10 questions above are not exhaustive. They are the minimum filter. An agency that answers all 10 well may still not be the right fit for your specific project. But an agency that cannot answer any of them clearly is not a risk worth taking.
If you want an honest assessment of whether ODSEA is the right fit for your project, the discovery call is free. We will tell you if we are not.
Start your discovery call with ODSEA →
What to Ask Before Hiring an AI Development Agency in 2026 (Gulf Founders Guide)
In 2024, a founder we will call Maciej hired an AI development agency that came highly recommended. The website was polished. The case studies looked impressive. The discovery call lasted 90 minutes and covered all the right topics. By month three, the team had consumed $300,000 of his seed round and delivered a system that crashed under load, had no tests, and used an architecture that the next agency quoted $150,000 to rebuild from scratch.
Maciej is not unusual. GoodFirms' industry survey documents that 53.8% of software development projects experience scope creep — meaning more than half of all engagements deliver less than what was promised, cost more than was quoted, or both. In the Gulf markets — Saudi Arabia, UAE, Qatar — where the majority of founders do not have technical backgrounds and the AI agency landscape has exploded with agencies of wildly varying capability, the selection problem is acute.
This guide is for non-technical Gulf founders who need to evaluate AI development agencies without being able to read their code. The 10 questions below are designed to separate genuine AI engineering capability from rebadged web development shops that learned to put "AI" in their service descriptions.
The Gulf Context: Why Agency Selection Is Harder Here
The Gulf startup ecosystem is producing founders at a pace that the local technical talent supply cannot match. Vision 2030 in Saudi Arabia, the UAE's Golden Visa programs, Qatar's National Vision 2030 — each of these initiatives is deliberately accelerating entrepreneurship in markets where domain expertise is deep but technical founding teams are scarce.
The result is that Gulf founders disproportionately need external technical execution partners. And the agency market has responded to that demand with volume, not necessarily quality.
A specific dynamic makes the Gulf market harder to navigate than, say, London or Singapore: the trust networks that normally filter agency quality — word-of-mouth from founders who have been through the same process, shared technical communities, visible open-source contributions — are thinner and younger here. A startup ecosystem that has been growing at its current pace for only five to seven years does not yet have the density of experienced founder peers who can give you reliable referrals.
This means you need to be able to evaluate agencies using explicit criteria rather than social proof. The questions below are that criteria.
The 10 Questions — And What the Answers Tell You
Question 1: Can You Show Me a Live Production AI System Built for a Client in the Past 12 Months?
This is the most important question and the one most agencies fail at.
A "production" AI system means a system that real users interact with at meaningful volume — not a demo environment, not a prototype, not an internal tool with a handful of users. The "past 12 months" qualifier matters because AI development practices have changed dramatically. An agency showing you work from 2022 or 2023 is showing you pre-LLM-native work.
What good looks like: The agency names a specific live product, provides the URL, and can walk you through the architecture. They know the traffic numbers. They can describe what happens when the LLM API is unavailable and how the system handles that gracefully. They know their uptime SLA.
What bad looks like: "We have several projects in stealth." Or a portfolio that is all mockups and screenshots with no live URLs. Or a live URL that returns a demo login page.
The follow-up: "Can I talk to the client directly?" Real agencies with legitimate production work will facilitate a reference call without hesitation. Agencies that rebadge others' work, or show case studies that exaggerate their role, will find reasons this is complicated.
Question 2: What Does Your Team Actually Look Like — Who Will Work on My Project?
The gap between the team shown in a pitch deck and the team that works on your project is one of the most consistent complaints in developer marketplace reviews. Senior engineers close deals; junior contractors do the work.
What to ask specifically:
- How many engineers are on your current team, and how many are dedicated to AI vs. traditional web development?
- Who specifically would work on my project — can you name them?
- What is their experience with the specific AI frameworks my project requires (LangGraph, LangChain, LlamaIndex, Autogen)?
- Are they employees or contractors?
What good looks like: The agency can name specific engineers, show you their GitHub profiles, and describe what they have built. The AI engineers have demonstrable experience with the current generation of tooling, not just a stated familiarity.
What bad looks like: "We will staff appropriately based on project needs" (translation: we do not have a stable team). Or a team that describes itself as "AI experts" based primarily on using OpenAI's API to build a wrapper.
Question 3: Show Me Your Error Handling — What Happens When the LLM Fails?
This question separates production-grade AI engineers from demo builders faster than almost anything else.
In production AI systems, LLM APIs fail. They rate-limit. They return malformed JSON. They produce plausible-sounding but factually wrong outputs. They are slow. Every robust production AI system has explicit error handling for all of these scenarios.
What good looks like: The engineer can describe their retry logic (exponential backoff with jitter is standard), their fallback strategy when the primary model is unavailable (a cached response, a degraded mode, a secondary model), and their approach to validating LLM outputs before using them downstream.
What bad looks like: "We have not had any issues" (translation: they have not run the system under real conditions). Or a technical answer that amounts to "we just call the API and use whatever it returns."
Question 4: How Do You Handle Prompt Injection and Model Jailbreaking?
If the AI system you are building will process user-provided input — which most useful systems do — prompt injection is a real production security concern. It is also the question that most agencies are not prepared for.
Prompt injection is the AI equivalent of SQL injection: a malicious user provides input that causes the AI to ignore its instructions and follow the attacker's instructions instead. In a customer-facing AI system, this can mean leaking private data, bypassing access controls, or producing harmful outputs that damage your brand.
What good looks like: The agency has a clear answer about input sanitization, output validation, and their approach to designing prompts that are resistant to injection. They know about OWASP's LLM Security Top 10 (published 2023, updated 2025). They can describe how they have tested for injection vulnerabilities.
What bad looks like: A blank look. Or "we use system prompts so users cannot affect the instructions." (They can, and there is a documented literature of techniques for it.)
Question 5: What Is Your Position on IP Ownership, and How Is It Defined in Your Contract?
This is the question that founders discover they should have asked after it is too late.
Software development contracts have two common models: work-for-hire (you own everything) and licensed delivery (the agency retains ownership of the underlying frameworks and licenses you the product). The difference matters enormously when you go to raise funding, sell the company, or change agencies.
What to ask specifically:
- Is the code delivered as work-for-hire, meaning I own all IP from the first line?
- Are there any agency frameworks, libraries, or template code included in the delivery that you retain ownership of?
- Can I publish the source code, modify it freely, and give it to a different developer to maintain?
What good looks like: A clean work-for-hire agreement where all code, prompts, system designs, and documentation become your property on delivery. No agency-owned components bundled in.
What bad looks like: A contract that uses "perpetual license" language instead of "assignment of copyright." Or an agency that says you own the code but reserves the right to "reuse architectural patterns" — which in practice can mean reselling your competitive advantage to your competitors.
Question 6: How Do You Structure Milestones and What Are the Payment Terms?
GoodFirms' research on the $36,000 average AI project cost comes with a context that should alarm founders: the majority of projects paid in large upfront tranches had significantly worse scope creep outcomes than projects paid against defined deliverable milestones.
What good looks like: Milestone-based payments tied to specific, testable deliverables. A typical well-structured engagement looks like: 20% on contract signing and kickoff, 30% on delivery of a working MVP, 30% on passing acceptance testing, 20% on launch and handoff. Each milestone payment is conditioned on something specific — not on "the work we did this month."
What bad looks like: "We need 50% upfront to begin." Or monthly retainer billing without milestone checkpoints. Or milestones defined as activities rather than outcomes.
The contract clause to watch for: "Payment is due within 30 days regardless of acceptance testing results." This clause, common in template contracts, means you pay even if the deliverable fails testing. It should be removed.
Question 7: What Is Your Testing Approach for AI-Specific Behavior?
Testing AI systems requires techniques that differ from testing traditional software. Traditional test suites verify that a function given input A returns output B. AI systems produce probabilistic outputs — the same input can produce different outputs on different runs, and all of them may be "correct" at the individual level while the population of outputs has an unacceptable error rate.
What to ask:
- How do you test for hallucination rates in your AI components?
- What is your approach to regression testing when you update prompts or switch models?
- Do you have automated test suites for AI-specific behavior, or only for the surrounding application code?
What good looks like: The agency has a rubric-based evaluation approach — they define what "correct" means for their LLM outputs and test against that definition. They use a holdout test set of example inputs with verified correct outputs.
What bad looks like: "We test manually by using the system and verifying it seems right." Manual testing at this level does not scale and does not catch statistical degradation.
Question 8: What Does Your Handoff Look Like — What Do I Get When the Project Ends?
A surprisingly large number of agency engagements end without the client being able to operate the system they paid for. Documentation is missing. The deployment environment is locked to the agency's accounts. The architecture is undocumented.
What good looks like: A handoff package that includes: full source code in the client's version control repository (not the agency's), deployment documentation detailed enough for a different developer to follow, architecture documentation covering system design decisions, environment variable documentation, and a walkthrough session with the development team.
What bad looks like: Code handed over as a zip file. No documentation. Deployment that only the agency knows how to run.
Question 9: Can You Describe the Architecture of the Project Before You Build It?
Any competent AI engineering team should be able to describe the high-level architecture of your project within the first week of engagement — before a line of code is written.
What good looks like: A technical design document that covers: system components, data flow between components, technology choices with rationale, estimated complexity per component, and identified technical risks.
What bad looks like: Starting implementation immediately after a verbal description of requirements. Or a proposal that uses buzzwords without specifying which specific tools, frameworks, and architectural patterns.
Question 10: What Are Your Fees for Making Changes During Development?
Change management is where the cost overruns live in most software projects. A project quoted at $50,000 with a change order rate of $200 per hour for any deviation from the original specification can quickly become a $100,000 project when product discovery reveals that the original specification was incomplete — which it always is.
What good looks like: An explicit change management policy with clear categories: what counts as a change order versus what is included in the original scope, at what rate, with what approval process.
What bad looks like: No stated change management policy. Or a change policy that applies to any deviation from the original specification document, including clarifications of ambiguous requirements that were always within the intended scope.
Red Flags That Should End the Conversation
Beyond the 10 questions, these signals should stop you from proceeding regardless of the answers to everything else:
Guaranteed results. No legitimate AI development agency guarantees specific AI performance metrics in advance. AI system performance depends on real-world data distributions that cannot be fully predicted before deployment.
The discounted limited-time offer. Professional development agencies have consistent pricing. "We can give you a special rate but we need to start this week" is a sales pressure tactic.
Inability to name clients or provide references. Every legitimate agency has clients willing to take a reference call. Stealth NDA excuses for all clients simultaneously is a pattern, not a coincidence.
No engineers in the room. If every conversation before the contract is with salespeople and account managers, and you have never spoken to the engineers who will work on your project, you have no basis for evaluating technical capability.
Identical-looking case studies. Agencies that produce case studies from templates — where every case study has the same structure and same metrics (always "3x improvement" or "50% cost reduction") — are likely summarizing other agencies' work rather than their own.
The Contract Structure That Protects Gulf Founders
For Gulf founders unfamiliar with technology contract structures, here is the minimum acceptable framework:
-
Explicit IP assignment clause: All work product — code, prompts, system designs, documentation — is assigned to the client on payment.
-
Milestone-based payment schedule: No payment trigger is time-based; all are tied to deliverable acceptance.
-
Acceptance testing criteria: Each milestone must specify testable acceptance criteria. "The authentication system is functional" is not a criterion. Specific, verifiable outcomes are.
-
Source code escrow: For engagements over $50,000, the source code is committed to a repository under the client's control from day one, not handed over at completion.
-
Data handling provisions: Any client data processed during development is handled under Saudi Arabia PDPL, UAE PDPL, or Qatar PDPL-Q standards as applicable, with explicit data retention and deletion provisions.
-
Termination for convenience clause: The client can terminate the engagement with 30 days notice and receive all work completed to date. No termination penalty.
How to Evaluate Portfolio Without Technical Knowledge
The question that stops most non-technical Gulf founders: how do you evaluate a technical portfolio when you cannot read code?
You evaluate it through proxies:
Live, working products are the most reliable proxy. If the agency built it and it runs reliably, that is evidence. Ask for a demo of the live system and test it yourself.
Reference calls with direct clients are the second most reliable proxy. Ask the client: Did the project come in on time and budget? Are you still using the system? Would you hire this agency again?
GitHub repositories are a useful proxy even for non-technical founders. Public repositories show commit history — you can see how actively the team codes, whether they write tests, whether they document their work.
Technical questions in the sales process are a final proxy. An agency that can clearly explain its architecture choices in terms you understand without condescension — and that asks you sharp questions about your use case rather than pitching generic capabilities — demonstrates the communication quality that correlates with good client relationships.
ODSEA's Approach
When we work with Gulf founders, every engagement starts with an architecture proposal before any implementation begins. IP assignment is standard — everything we build belongs to you from the first line of code. We work milestone-based with testable acceptance criteria on each deliverable.
The founders we work with most successfully are the ones who treat the agency relationship the same way they treat any high-stakes vendor relationship: with due diligence upfront, clear contracts, and structured milestones that create accountability.
If you are at the stage of evaluating development partners for an AI project — whether that is an MVP build, a custom AI agent system, or a more complex production platform — we are happy to answer all 10 questions above. Start with a discovery call and bring this list.
Related Articles
Why Smart Gulf Investors Are Choosing Vietnam for Tech Development (Not India or Eastern Europe)
Vietnam's developer costs have held flat while quality has surged. Gulf investors are noticing. Here is an honest, data-backed comparison of Vietnam vs. India vs. Eastern Europe for AI-native development in 2026.
Building a Fintech MVP in Qatar Under $50k: What the Numbers Actually Look Like
Qatar's fintech market is at an inflection point. The QCB regulatory sandbox is open. BNPL has gone from 76,000 to 10 million Gulf users in under three years. Here is what a compliant fintech MVP actually costs to build in 2026.
When to Hire an AI Development Agency vs. Build In-House
The build vs. hire decision is one of the most consequential choices an AI-forward company will make. Here's a framework for getting it right.