Decision guides

Build or buy? A decision guide for UAE operations teams.

Buy what every company does the same way. Build what makes your operation different. Most UAE teams end up with a mix, and the skill is knowing where the line sits.

Ahmed Khaled, Founder6 min readPublished

Conceptual software architecture artwork
Conceptual illustration
Short answer: Buy software for work every company does the same way, such as payroll or email. Build when the workflow is how you win, or when off-the-shelf tools force workarounds your team resents. For most UAE operations teams the best answer is a mix: keep the standard tools and build the focused system around them.

What are the three routes?

Most buying decisions come down to three routes, and they are often mixed.

  1. Buy SaaS. You subscribe to a finished product and adapt your process to it. It is quick to start and someone else maintains it.
  2. Configure an ERP. You take a broad business suite and set it up for your company. It covers accounting, purchasing, inventory and people well, and you adapt the rest.
  3. Build a custom system. You pay for a system shaped around your workflow, and you own the source code of the custom work.

Each route is right somewhere. The mistakes come from choosing by habit: buying because it feels safe, or building because the standard tool annoyed someone once.

When should you buy?

Buy when the work is the same in every company. Accounting, payroll, email, file storage and basic project tracking are solved problems. A product used by thousands of companies has had its rough edges removed by them. Building your own version is rarely worth it.

Buy, too, when speed matters more than fit. A good enough tool that your team uses next week beats a perfect one that arrives later.

When should you build?

Build when the workflow is part of how you compete, or when the standard tool cannot represent how you actually work. In our experience the signs are consistent:

  • Your team keeps the real process in spreadsheets, WhatsApp threads or a person's head, because the tool does not fit.
  • Approvals have rules specific to your contracts, clients or sites.
  • You need one record across several teams or sites, and each tool holds only a piece.
  • Your customers or staff need an app or portal that a general product cannot give them.

For example, supervising a G+5P+15 building project involves inspections, submittals, drawings, bill of quantities finance, variations and payments in one traceable record. That is why Al Mukab AlFudhi Engineering Consultancy uses ArkanCS, a construction-specific system, rather than a general project tool. And EVS needed customer apps for iOS and Android, in Arabic and English, connected to its workshop system. A general product could not give it that.

What about configuring an ERP?

An ERP is the middle route, and it is the right answer more often than people admit. Ashbilia Contracting LLC had no system and ran everything manually. We implemented Odoo for its accounting, purchasing, employees and inventory. That is standard back-office work, and configuring a proven suite was the sensible choice.

The ERP route gets harder when your core workflow is unusual. You then pay twice: once for the licence and set-up, and again for customisation that must be re-tested after every upgrade. In our view that is the point to consider a focused custom module that connects to the ERP instead of bending the ERP further.

How do the routes compare?

QuestionBuy SaaSConfigure an ERPBuild custom
Fit with your workflowYou adapt to itGood for standard work, strained for unusual workShaped around your work
Speed to first useFastestModerateSlowest, but modules ship in stages
Who owns the data modelThe vendorThe vendor, with your configurationYou, and you own the custom source code
Cost of change laterLimited to what the vendor addsCustomisation can be costly to maintainDesigned to absorb change
Dependence on a vendorHighHighLower, with documented handover
Best forCommodity workBack-office workWork that sets you apart

This table is the author's view, not a rule. A well-run ERP project can beat a badly run custom one.

How do you decide in practice?

Ask five questions about each workflow, not about the company as a whole:

  1. Would a competitor run this workflow the same way? If yes, lean towards buying.
  2. What do we do today when the tool does not fit? If the answer is spreadsheets and chat, the tool is failing.
  3. How often does this workflow change? Frequent change favours a system designed for it.
  4. Who needs access, and in which language? Customers, subcontractors and Arabic-speaking staff raise the bar.
  5. What happens if the vendor changes direction? Ownership and handover terms matter more for core workflows.

Different workflows will land in different places. That is normal.

What does the hybrid route look like?

Keep the standard tools for standard work. Build only the focused system where the fit is poor, and connect the two. The result is a smaller custom project, a lower risk and a system that grows in stages. This is also how we run a project: we release one module at a time, and you commit one phase at a time. See how we engage and our method.

If you are unsure which workflows deserve custom work, a technology advisory session is often the cheapest first step, because it ends with a written recommendation, not a proposal to build.

FAQ

Can we start with SaaS and build later?

Yes, and it is often the sensible order. Start with the standard tool, learn where it strains, and then build only that part. Make sure you can export your data in a usable form from day one.

Who owns the data in a SaaS product?

You own your data in principle, but the vendor owns the data model and the product. Check export formats, retention and what happens when you leave before you sign.

Is custom software always more expensive than an ERP?

Not always. It depends on how much customisation the ERP needs and how long you will use it. Compare the full cost of change over the system's life, not only the first quote. Our guide to what drives the cost of custom software explains the drivers.

What if my team is unsure which route fits?

Describe the workflow, the people in it and what goes wrong today. That is enough to decide. Our discovery call is free and the advice is honest, including when we say buying is the better route.

Do you only build, or can you help us choose?

We do both. Choosing is part of why teams work with us: we run products of our own, we implement standard tools where they fit, and we say so when they do.

Weighing build against buy?

Book a free 30-minute discovery call and bring the workflow you are unsure about.

Where this applies · Keep reading

Put the article to work.

More from the engineering desk.

Start a conversation

Facing this decision in your organisation?.

Free 30-minute discovery call. Bring the workflow; we’ll tell you whether it’s a product fit, a custom build or neither.