Internal systems that survive the team changing
Custom software in the UAE carries two requirements that are easy to underestimate. Many businesses run several entities across mainland and free zones, and a system that assumes one company will be worked around within months. And with high staff turnover in this market, a system nobody documented becomes unmaintainable at a change of personnel rather than a change of technology.
Businesses commission custom software when the spreadsheets have stopped coping. The brief is usually accurate about what the software should do and silent about the two things that determine whether it is still useful in three years: how many legal entities it has to serve, and who will understand it when the people who specified it have moved on. Both are more pressing here than in most markets, and neither costs much to address at the start.
The multi-entity problem arrives quietly. A system is built for the company that commissioned it, and then the same group needs it for the free zone entity, which invoices differently, holds a separate licence and sometimes trades under a different name. What follows is either a second installation nobody reconciles, or a series of workarounds inside the first. The turnover problem arrives more slowly and more completely: the people who knew why the system worked the way it did leave, taking the reasoning with them, and their successors treat it as a black box to be replaced rather than extended.
When this work makes sense
Questions worth asking any supplier
How many legal entities will this serve, now and plausibly later? Building for one and extending to several is much harder than allowing for several from the start.
Does the system generate VAT-correct documents itself, or produce something your finance team corrects afterwards? The second is a recurring cost disguised as a one-off compromise.
Establish who needs Arabic. And is it the interface, the printed output, or both? They are different pieces of work and only one of them is usually scoped.
What happens when the person who specified this leaves? Ask what documentation is included and whether it explains reasoning or only describes screens.
Is the data yours in a usable form, exportable without the vendor's cooperation? This is the question that matters most at the moment it is hardest to ask.
Deliverables
Multi-entity support where the group structure warrants it, with separate licences, numbering and branding handled properly
VAT-correct invoices and credit notes generated by the system, built to your accountant's specification
Arabic interface and Arabic printed documents where staff or customers need them, including right-to-left document layout
Documentation that records why decisions were made, not only what the screens do
Integration with the accounting, CRM and payment systems you already run
Data export in an open format, available to you without our involvement
Handover that a new hire can use to become productive without us
Built with
Process
We map the entity structure before the workflow. That means establishing which companies exist, which hold which licences, how they invoice each other if they do, and which of them this system will eventually need to serve, a conversation that frequently surfaces a second or third entity nobody mentioned in the brief. Getting it into the data model at the start is inexpensive; adding it to a system that assumed one company is a rebuild of the parts that matter most. Documentation is written as the work proceeds rather than assembled at the end, because documentation written at the end is written from memory and is the first thing cut when a deadline moves.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Build, configure, or keep the spreadsheets
Off-the-shelf, configured
Fits: Processes that are genuinely standard, accounting, payroll, common CRM needs
Limits: You adapt to the software; where your process is a real differentiator, that adaptation costs more than the licence saves
Custom build
Fits: Processes specific enough that no product fits, or multi-entity structures products handle badly
Limits: You own the maintenance, so documentation and data portability matter more than they feel like they do on day one
Keep the spreadsheets
Fits: Genuinely viable longer than most vendors admit, particularly below a certain volume
Limits: Fails at a specific point, concurrent editing, audit trail, or one person holding the whole thing in their head
Case studies
No published UAE custom software case study yet. Our Dubai office is in Standard Chartered Tower, Downtown Dubai. Client work will be published when we have permission to name the business and outcomes that can be evidenced rather than described.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
We have three companies across mainland and a free zone. Does that complicate things?
It changes the data model, which is exactly why it belongs at the start. Separate licences, invoice numbering, branding and sometimes different processes per entity are all manageable when designed in. Added later, they touch nearly everything, which is why the answer is usually a second system nobody reconciles.
Can the system issue VAT invoices?
Yes, built to what your accountant specifies, including numbering, credit notes and the records your filings need. We build to their instruction and do not advise on your tax position. A system that produces documents finance has to correct is a recurring cost that looks like a saving.
Do we need the interface in Arabic?
It depends who uses it. Often the answer is that the internal screens can stay in English while the printed documents, invoices, delivery notes, contracts, need Arabic. Those are separate pieces of work, and the document side involves right-to-left layout rather than only translation.
What happens if our IT person leaves?
That is the question worth asking before you commission anything, and in this market it is not hypothetical. We write documentation that records reasoning rather than just describing screens, because a successor can work out what a button does and cannot work out why it behaves that way on the fifteenth of the month.
Who owns the code and the data?
You own both. The code is yours and the data is exportable in an open format without our involvement. Ask this of any vendor before signing. It is the question whose answer matters most precisely when the relationship is at its worst.
Could we use an off-the-shelf product instead?
Often, and we will say so when we think so. Custom software is the right answer when your process is genuinely specific or your entity structure is handled badly by the products available. It is the wrong answer when what you actually need is a standard product configured properly.
How long does it take?
It depends on scope, and we will give you a schedule with the estimate rather than a number now. What we can say is that we build in stages with something usable early, because a system delivered whole after many months is a system whose assumptions were never tested against the people using it.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.