Writing

Build or buy: a Dubai owner’s guide to the agentic AI decision.

Every owner in Dubai who takes the two-year agentic AI window seriously arrives at the same fork. Buy software that already exists and fit the business to it, or build a system around how the business already works. Both are legitimate. This note is about how to tell which is right for a particular company, and it is written by people who build, so read it with that in mind.

The two things being compared

On one side is software as a service: a CRM, a project tool, an accounting package, a scheduling app, increasingly with AI features built in, rented by the month and configured to the business. On the other is a system built for one company around how that company already operates, holding its pipeline, work, money and people in one place, on its own infrastructure, in its own brand, with an AI executive running it. The first is a set of good tools. The second is the operating system the business runs on. They are not the same category, and the mistake most owners make is to compare them as if they were.

When buying is right

Buying is right more often than a builder would like to admit, and it is right in a few clear cases.

  • The operation is close to a standard shape. If the way the business runs is roughly how similar businesses run, a well-chosen tool will fit well enough, and the configuration effort is small.
  • The business is small and simple. Under about ten people, with one or two kinds of work, a CRM and a shared inbox and a spreadsheet are usually enough.
  • The problem is in one place. If the only thing broken is the pipeline, or only the invoicing, buy the tool that fixes that one thing. Building a whole system to solve one problem is the wrong size of answer.
  • Speed matters more than fit. SaaS can be live this week. If the business needs something working now and can live with the compromises, buy now and revisit later.

A business simple enough for off-the-shelf software should buy it, and we say so when that is the case.

When buying stops working

The failure of SaaS in a growing owner-run business is rarely a failure of any one tool. It is a failure of the joins. The CRM holds the deal, the project tool holds the job, the accounting software holds the invoice, the spreadsheet holds the payouts, and a person carries every number between them. The person is usually the owner. Every tool is fine and everything still routes through one head.

The signs are specific. A quote is approved in one place and the job planned in another, so plan and budget drift apart without anyone deciding they should. A debrief never happens because no tool owns the step after delivery. A past client is never called at six months because no tool remembers them. Nobody can say which channel the revenue came from, because the enquiry and the invoice were never the same record. Every number is a reconciliation. If more than two of these are true, another tool will not fix it, because the tool is not the problem.

The other sign is the one owners feel rather than measure: the business cannot run for a week without them. Not because the team is weak, but because the operation exists only in the owner’s head and the tools hold fragments of it. That is the wall, and it is where building starts to be the right answer.

What “own infrastructure” buys

A built system runs on hardware the company controls rather than in a platform it rents access to. Three things follow. The data stays where the owner can see it, which for a company whose operation is its edge is not a small matter. The system is shaped by the business and continues to be, because there is no product roadmap set by a hundred thousand other customers deciding what it does next. And the system can hold the whole operation in one record, from enquiry to debrief to reactivation, because nothing has to be handed between vendors. The four parts of such a system, and what each holds, are described under pipeline, work, money and people.

What it costs is attention: the business has to be mapped first, in a room, against a real job. That takes a day of the owner’s time, and it is the reason the result fits. The method page describes it.

The questions to ask any vendor

These apply to a SaaS provider, to a platform programme, and to us.

  1. Where does my data live, and who else can see it? A clear answer is a good sign. A vague one is the answer.
  2. What happens to the parts of my operation that your product does not model? If the answer is a feature request or a workaround, understand that you will be carrying those parts yourself.
  3. Who carries a record from the sale to the job to the invoice to the follow-up? If it is a person, ask which person. It is usually you.
  4. What does the AI in this product actually have the authority to do, and to whom does it answer? Agentic software that acts on its own in your name should worry you more than software that prepares and asks.
  5. What will it look like to my team and my clients? Whose brand is on the screen.
  6. What does it cost to leave? Both the money and the operational cost of taking the records somewhere else.
  7. Can I see one in production, not a demo? For us, the answer is under work in production.

Deciding without regret

The decision is not permanent in either direction. A business that buys well now can build later when the joins fail. A business that builds has, by definition, a system shaped to it, and can still use good SaaS at the edges where a standard tool is better than a custom one. What should be avoided is the middle: buying a fourth and fifth tool to fix the joins between the first three, because that is the path on which the owner ends up carrying more rather than less. If you recognise the signs above, the agentic AI page explains what a system a business runs on actually is, and one conversation will tell you which side of the fork you are on. We will say so either way.

Written by the founders of Symbaiotic, Dubai. See who we are, and more writing.