Blog — 2026-08-07
By Emad Yahya — web developer & IT systems engineer, Dubai
Replace Excel when the spreadsheet stops being a document and starts being a system — when several people need to edit it at the same time, when you need to know who changed a number and when, and when a wrong figure costs real money. Until then, keep the spreadsheet. Excel is genuinely excellent software, and the problem is almost never Excel itself: it is that a file designed for one person's analysis ends up running an operation five people depend on. The replacement does not have to be enormous. It has to have logins, permissions, a full history of every change, validation at the point of entry, and reporting that reads from the same records the team actually works in.
I'm Emad Yahya, a web developer and IT systems engineer in Dubai. Most of the systems I have shipped replaced the same two things: spreadsheets and paper. The IT asset manager I built put 150+ company devices under continuous audit after device tracking had lived in error-prone spreadsheets with no assignment history and no audit trail. The HR platform I built at Platinum Square replaced paper checklists, email approval threads and spreadsheet leave balances. This is the sequence I use to decide whether a spreadsheet is finished — and what should replace it.
There is a moment where a spreadsheet quietly changes job. It was a document; now it is the system of record for something the business runs on — stock, staff, devices, leads, bookings, invoices. Nothing about the file changes at that moment, which is why teams rarely notice the transition. What they notice are the symptoms, months later.
These are the failure modes I see repeatedly in UAE SMEs. One of them on its own is survivable. Three at once means you are already paying for a system — in staff hours and corrected errors rather than in a build.
Migrate the register, not the report. A register is the sheet that records real things as they happen — devices, employees, stock, leads, bookings. A report is anything derived from a register. Teams usually want to start with the report, because the report is what management complains about, and that is backwards. Fix the register and most reports rebuild themselves, because a system can calculate on demand what a spreadsheet has to maintain by hand.
Among your registers, pick the one with the most hands on it and the most arguments attached to it. That is normally the one where accountability is ambiguous. For me it was device tracking: when an asset went missing, I was the person who could not answer who had it last. That question — who has this, who had it before, what did they sign, what maintenance has it had — is what the data model got built around, and it is a far better starting point than a feature list.
Resist migrating everything at once. One register, done properly, with the team using it every day, beats a six-month project that replaces five sheets simultaneously and gets quietly abandoned by week three.
Any replacement that is just a nicer-looking grid will fail, because a grid is what you already had. These are the non-negotiables I build into every system that replaces a spreadsheet — and a fair checklist to hold any vendor to, including me.
The IT asset manager is the cleanest example I have. Device tracking lived in error-prone spreadsheets: no assignment history, no liability records, no audit trail, and assets went missing. The replacement treats a device as a history rather than a row — every assignment, transfer and return is an event tied to the employee involved, with liability agreements and maintenance logs attached to the device record itself, and dashboards showing deployment status across departments. The outcome: 150+ devices under continuous audit, and zero untracked assets since deployment.
The PSQ HR platform is the same pattern one level up. Onboarding ran on paper checklists, leave balances sat in a spreadsheet nobody could verify, and contracts existed only inside somebody's inbox. That became structured onboarding workflows, leave with balances and approval chains, one central document repository and org-level reporting — integrated into the Microsoft 365 environment staff already used daily, because adoption is easier when the system lives where people already work. The result worth quoting is not a feature: it is one auditable source of truth for every employee record.
Export, clean, map, import, verify, run in parallel, cut over. That is the whole sequence, and the step that takes longest is cleaning. Years of spreadsheet history usually contain duplicates, inconsistent spellings of the same name, merged cells and half-finished rows. That cleanup is worth doing properly rather than importing the mess into a nicer home, and it is normally where the client's own knowledge is irreplaceable.
Existing data is migrated and verified before go-live rather than thrown away — nothing starts from zero. During the overlap period the old sheet stays readable but stops being edited. The moment two systems both accept new entries, you have two truths again, which is the exact problem you paid to remove.
And here is the half nobody sells you: the software is the easier part. A tracking system only works if it is the sole path the work can travel through. A single hand-over that happens outside it quietly reintroduces the spreadsheet problem, and if a leave request can still be approved by email, the spreadsheet era never really ended. Budget for the process change, not just the build.
No, and I say so when you don't, even though building custom systems is what I do for a living. If your workflow is genuinely standard — accounting, invoicing, document storage — a mature off-the-shelf subscription tool is usually the right call at small scale. Spreadsheet-style database tools sit in between and can be a reasonable middle step for a small team; the trade is that you are renting again, and shaping your process around the tool's model rather than the other way round.
Custom becomes the better answer when your process does not fit the templates, when per-user fees multiply as the team grows, when the system needs to talk natively to WhatsApp, your website or your other tools, and when the data is sensitive enough that owning it outright matters. On timelines, a custom platform is typically a 4–8 week build depending on features; if the register you are replacing is a sales pipeline, a CRM lead-and-pipeline core runs 3–5 weeks, with a fuller build including approvals and reporting at 6–10 weeks.
Cost depends entirely on scope — how many registers, how many roles, what has to integrate, how much history needs migrating — so I don't quote from a price list. Send me the actual sheet you are trying to retire and I will tell you honestly whether it needs a system or just better structure, with a fixed written quote within 24 hours if a build genuinely makes sense.
When the spreadsheet becomes the system of record for something the business runs on and starts showing the classic failure signs: several people needing to edit at once, no way to trace who changed what, multiple versions circulating on WhatsApp, formulas silently pointing at the wrong rows, and no permissions on sensitive data. One of those is survivable; three together means you are already paying for a system in staff hours and corrected errors.
A system with logins and role-based permissions, an automatic history of every change, validation at the point of entry, reporting that reads from the same records the team works in, soft delete instead of destruction, and export back to Excel whenever anyone wants it. Whether that is an off-the-shelf tool or a custom build depends on how standard your process is — a nicer-looking grid without those foundations is just the spreadsheet again.
No. Existing data is exported, cleaned, mapped and imported, then verified before go-live — nothing starts from zero. The cleaning step usually takes the longest, because years of spreadsheet history tend to contain duplicates and inconsistent entries that are worth resolving rather than carrying across.
A custom platform is typically a 4–8 week build depending on features. If the sheet you are replacing is a sales pipeline, a CRM lead-and-pipeline core runs 3–5 weeks, with a fuller build including approvals and reporting at 6–10 weeks. Migrating one register at a time is usually faster and far more likely to be adopted than replacing five sheets simultaneously.
It depends entirely on scope — how many registers, how many user roles, what has to integrate with your website or WhatsApp, and how much history needs migrating — so there is no meaningful list price. Send the sheet you want to retire and you get a fixed written quote within 24 hours, plus an honest answer if the truth is that better structure would do.
Yes, and they should where it helps. The point is to stop the spreadsheet being the system of record, not to ban spreadsheets. Data export is part of what I build — records out to a spreadsheet, payroll data out for your accountant — so analysts can still model, chart and slice the data — they just do it from a single verified source instead of from a file that three people edited separately.
Custom Software Development in Dubai — full service page · Custom Software vs Off-the-Shelf for UAE SMEs — the build-vs-buy guide · HR System Development in Dubai · POS System Development in Dubai