Build or buy: should a Dubai brokerage keep adapting a ready-made CRM or have something built?

A disclosure first

I run Blur Studio, a one-person studio that builds custom software and AI tools for small businesses. That means I earn money if you decide to build, and the other articles on this site include my services. Weigh what follows with that in mind. The test of whether I am being fair is simple: I will tell you below the cases where I think you should not hire me, and the risks of hiring someone like me.

The honest answer: most brokerages should buy first

A ready-made CRM has years of other people's mistakes already fixed. It has a team behind it, mobile apps, integrations with the UAE property portals (Property Finder, Bayut and Dubizzle) and a price you can read. For a brokerage with typical needs it will be live in days or weeks and cost far less than a custom build in the first year. If you are still deciding which one, my guides on evaluating software vendors and what to check before buying a CRM come first. The general version of this decision is in build vs buy software; this article is about the Dubai-specific parts.

What buying covers well

• Lead capture and assignment, including from portals.
• Contact and deal records, tasks, reminders, notes.
• A mobile app agents will use, built by a team that does nothing else.
• WhatsApp (the messaging app) integration, where the product offers it.
• Standard reports.
• Updates, security and support without any effort from you.

If your needs are in this list, building is a poor use of money. That is true at 5 agents and true at 50.

Why "how many agents" is the wrong question

Every article I found on this question was written by a seller of custom software, and they give different agent-count answers: under 20, under 30, 50 or more, a break-even somewhere between 5 and 20. Because they disagree, I do not trust any of them, including mine. Their cost figures are also seller estimates with no stated method; for example, one custom-build firm quotes a range of AED 12,500 to 98,000 for a custom CRM, while another says AED 140,000 to 300,000. The spread alone tells you that the scope matters more than the headcount. For the ready-made side, see CRM cost by agent count.

A better rule: build only for a specific workflow where a ready-made tool is costing you a measurable amount each month. One idea I found in a seller's article and keep: custom is justified by the specialised 20 percent of your needs, not the standard 80 percent.

Signs a ready-made tool is holding you back

• Someone spends hours every month in a spreadsheet doing something the CRM should do, such as calculating commission splits.
• Agents keep a "real" tracker outside the system because the CRM cannot model something you do.
• You are upgrading a plan only to unlock one feature. See Bitrix24 pricing (Bitrix24 is a CRM) for how that looks in practice.
• Errors recur at a hand-off, for example deal to invoice to agent payout.
• You have several offices, or several types of business (off-plan, resale, leasing, property management), that need to be reported together.

If none of these is true, stay where you are.

The three workflows that most often justify building

1. A commission split engine. If your splits depend on tiers, referrals, co-broke arrangements, team overrides or developer-specific rules, a spreadsheet becomes fragile. A tool that reads closed deals and produces payout statements with the arithmetic shown removes a monthly job and a source of disputes. See commission split models and back office automation for invoices, VAT and payouts.
2. A developer and launch ledger. Terms, triggers, holds, buyer matches and receivables per developer. Few CRMs model this well. See tracking developer relationships.
3. An owner portal. A place where landlords and investors, especially overseas, see statements, documents and cheque dates. See landlord owner reporting.

Notice that all three sit around the CRM, not inside it. That points to the middle option.

Hybrid: keep the CRM and build one piece

The most useful idea in the seller articles I read was the hybrid: keep the standard CRM and build one small module over its API (the connection point that lets other software read and write its data). The attraction is clear. You keep the mobile app, the portal feeds and the support you already pay for. You build only the one thing that is costing you. If the small tool turns out useful, you have proved value cheaply. If it does not, you have lost far less than a full build. A hybrid also depends on the CRM allowing it: ask whether the plan you are on includes API access, and what limits apply. Some do not include it on every plan.

What building really costs: build, hosting, changes and a person to call

I will not print a price range, because the published ones are seller estimates that contradict each other and mine would depend on your scope. Instead, here is what to put in the budget so that no quote surprises you:

• The build itself, ideally fixed per defined piece rather than open-ended.
• Hosting and running costs (servers, databases, any AI usage), which are ongoing. They should sit in an account you own.
• Change requests. Your business will change in the first six months and the software must change with it. Ask how these are priced.
• Maintenance and fixes. A rule of thumb that custom software costs 15 to 20 percent of its build price each year to keep going appeared in search results, but I could not trace it to a source, so use it only as a question to ask any builder.
• Your own time. Someone on your team must test, give feedback and train agents. This is often the biggest cost and the least budgeted.
• A person to call when something breaks at 9am on a launch day.

The risk of a one-person studio, and the questions to ask any builder

I am a one-person studio, so I will be direct about the key-person risk: if I disappear, who maintains the system? The same question applies to any small agency. These are the protections I think you should require from anyone, me included:

• You own the source code, in writing, and receive a copy.
• Hosting is in your account, not the builder's, so you can move the system.
• Documentation exists that another developer could follow.
• Standard technology, not an obscure framework nobody else knows.
• Your data can be exported in a normal format.
• A named backup person, or an agreement about handover if the builder stops working.
• References you can phone, and a small first project to test the working relationship.

If a builder resists any of these, that tells you something.

A simple decision worksheet with your own numbers

Use real figures from your own office. For each candidate workflow, fill in:

1. Hours per month spent on it, and who does them. Multiply by that person's cost per hour.
2. Money lost per month to errors (underpaid, overpaid or missed commission, late invoices).
3. Cost per month of any upgrade or extra subscription you pay only because of it.
4. The build quote for just that piece, and the yearly running and change costs.
5. Months to pay back: build cost divided by the monthly saving, where the saving is (1 + 2 + 3) minus the monthly running costs.

A made-up example, to show the arithmetic only: if a payout spreadsheet takes 12 hours a month at an internal cost of AED 100 an hour, and errors cost AED 1,000 a month, that is AED 2,200 a month. A piece quoted at AED 30,000 with AED 200 a month in running costs would pay back in roughly 15 months. If your numbers give 40 months, do not build. If they give 8, ask for a fixed-price quote on that piece alone. Those figures are invented; use yours.

Where AI-assisted building changes the cost

AI coding tools have made small, focused tools cheaper to build than they were a few years ago, and that is the real reason a single workflow can now be worth building when it was not. It is also where I would be careful. An AI-built tool can look finished and still hide errors in how it handles money, permissions and edge cases. A payout engine that is wrong by a small amount is worse than none. Ask any builder, including me, how the calculations are tested, using your own past deals as test cases, with the expected answers worked out by hand first.

Try this yourself with Claude, an AI assistant, before you hire anyone: describe your commission rules in plain words and ask it to write them as a numbered list of rules with one worked example each, and to list every situation where the rules are unclear. The ambiguities it lists are the arguments you will have later, with or without software. This turns a vague need into a specification, which is the cheapest thing you can do to reduce the cost of any build. It cannot replace a developer, and it does not know your legal obligations. See the limits of AI for UAE teams.

Whether you are building or buying, remember what no software fixes: agents who do not record their deals. For that, see a new agent onboarding system.

A sensible sequence

1. Buy and run a ready-made CRM properly for six months, with adoption tracked.
2. Keep a list of workarounds and time lost, with numbers.
3. Pick the single costliest workflow and run the worksheet.
4. If it pays back, build that piece around the CRM with source code, hosting and documentation in your hands.
5. Review after three months. Only then consider a second piece, and only consider replacing the CRM if the pieces have grown to be most of it.

How would I approach it?

If you came to me, I would ask for the worksheet before talking about price, and I would tell you to buy if the numbers say buy. The cheapest outcome for you is a decision you will not regret in a year, whoever benefits.