Almost every contractor starts on Excel, and there is nothing embarrassing about that. Excel is an excellent tool: flexible, immediate, universally understood, and requiring neither a decision nor a budget. The problem does not appear when a project gets bigger. It appears when more than one person starts writing into the same file — a moment that usually passes unnoticed, so the arrangement stays in place for months after it stopped working.
Key takeaways
- Spreadsheets do not break on size, they break on concurrency: a file assumes a single writer, and the first second writer starts the chain of copies.
- Chat is excellent transport and a poor record: the message arrives, but you cannot search it or establish who approved what and when.
- What software adds is not prettier screens but things a file structurally cannot have: roles, an audit trail, linked records, and offline capture.
- A successful migration starts in the field, not in finance: the data entered daily is what makes everything above it worth reading.
- Not everything deserves to move — one-off estimating and modelling stays in the spreadsheet; shared, repeating records are what migrate.
Excel is not the problem — the second user is
One spreadsheet maintained by one person is an excellent tool, and arguably better than any system for that exact situation: no training, no subscription, total flexibility. But a file assumes a single writer by its nature. The moment the site engineer needs to update percent complete while the accountant updates cost in the same file, the first copies appear: "Report_FINAL_v3_revised.xlsx".
From then on the tool stops being a place where data lives and becomes a source of questions: which copy is current? who changed this figure? does the version sent to the owner include the latest change order? The time Excel used to save starts getting spent reconciling its own versions.
What actually breaks
The usual complaint about spreadsheets is that they look unprofessional, which is a weak argument. The real problems are specific and describable, and none of them is solved by a better spreadsheet:
| What breaks | How it shows up at work |
|---|---|
| Concurrent writing | Two versions of the truth, a weekly manual merge, decisions made on stale numbers |
| Permissions | Whoever opens the file sees everything — payroll, margins and supplier prices included |
| Audit trail | No way to know who changed a figure or when, so disputes get settled by memory |
| Linked records | The change order in one file, the budget in another, and nothing guaranteeing they agree |
| Offline capture | No coverage on site, so data goes on paper and gets typed up days later from memory |
| Two languages | An Arabic file for the owner and an English one for the consultant, drifting apart |
Five of those six are not Excel limitations that a more skilled user gets around. They are structural properties of a file being a file. A spreadsheet does not know who is reading it, does not retain a history of changes, and cannot enforce a relationship between a value here and a value there — which is exactly what it means to say the answer is not a better spreadsheet.
Chat is transport, not a system of record
Alongside the spreadsheets, most projects run their other half through WhatsApp: progress photos, spend approvals, a warning about a material running out, sign-off on a change. That is entirely sensible — it is on every phone on site and it works instantly. The problem is that it gets used as a record, and it is not one.
- You cannot search "every approval on project X in March" — messages are ordered by time, not by subject.
- A photo loses its context: three months later nobody knows which floor, which date, or which line it belonged to.
- A verbal agreement or a "ok" message is not an approval anyone can rely on in a dispute.
- An employee leaving the group takes half the project history with them.
The conclusion is not to abolish chat — that will not happen and does not need to. It is that anything worth keeping has to end up in a record: the photo attached to a daily report, the approval recorded where its status can be read later, the warning turned into a material request with a number and a status. Conversation stays for coordination; the record holds the truth.
What the software actually adds
A lot of construction management software is sold on screens: dashboards, charts, alerts. But the real difference between a file and a system is not presentation — it is four properties a file cannot have:
Roles and permissions
The engineer records but does not approve, the accountant sees money but not site detail, the owner sees all of it. Separating who records from who approves is what makes an approval mean anything.
An audit trail that cannot be edited
Every change leaves a trace of who and when. When a disagreement comes up, the answer is read rather than remembered.
Linked records
A change order knows which budget line it hit, a payment application knows which progress it was built from, a receipt knows which purchase order it came from.
Offline capture
Entry in a basement or on a remote site happens at the time and syncs later, so data arrives fresh instead of reconstructed from memory.
Notice that none of the four makes the work "faster" in any direct sense. What they do is eliminate a whole class of expensive errors: a decision made on stale data, an approval nobody can evidence, and two numbers that are each correct and mutually contradictory.
The order of migration is what decides it
The migrations that fail most reliably are the ones that move everything at once, or the ones that start with finance. The reason is the same in both cases: they ask people to enter data into a system that gives them nothing back yet.
Start in the field
Attendance and daily reports first. This is data produced daily and consumed daily, so its value is visible in the first week.
Then tasks and the schedule
Once site data exists, percent complete and the programme are built on something real.
Then the bill of quantities and cost
This is where the financial return starts: actual cost reaches its lines because the field is feeding it.
Then procurement and contracts
Purchase orders, receipts and subcontracts depend on having lines and sites recorded before them.
Finally payment applications and the client portal
The external outputs come last, because they present what the earlier steps built.
What should stay in Excel
Not everything is worth moving, and pretending otherwise costs credibility. Excel remains the better tool for one clear category of work: free-form, one-off modelling.
- Tender build-ups and estimating before a bid goes in — exploratory work whose formulas change hourly.
- One-off "what if" analysis on financing or cash-flow scenarios.
- Bespoke engineering calculations that do not repeat between projects.
- Temporary import and export with external parties who work in their own formats.
The working rule is simple: what several people enter repeatedly and decisions get read from moves into the system; what one person builds once to reach a number stays in the spreadsheet. The problem was never Excel — it was Excel used where it does not fit.
How this works in muqawil
muqawil is a construction management platform built in exactly that order: it starts in the field and works up to finance, in Arabic and English together.
- A full Arabic and English interface in both directions, not a partial translation — every record carries both of its language fields.
- GPS attendance, daily reports and safety incidents — all working offline and syncing later.
- Tasks and a schedule with real dependencies and a computed critical path, plus a bill of quantities with progress and cost.
- Procurement with receipts and matching, subcontracts, payment applications and retention.
- Roles and permissions separating who records from who approves, with an audit trail across every change.
- A client portal showing only what you choose to share, with no account for the client and no access to anything else.
And because the first question is usually price: one plan with every feature, monthly or annual, after a trial — no per-project pricing and no features held back for a higher tier.
Frequently asked questions
When exactly should we stop managing projects in Excel?
When more than one person regularly writes into the same file, or when merging versions has become somebody's standing weekly job. Project size is a much weaker signal than the number of people writing.
Can we import our existing bill of quantities from a spreadsheet?
BOQ lines are entered into the system as lines with quantities, rates and progress. The normal path is to move the live project's lines across once at the start, after which the system — not the file — is the reference.
What about old completed projects — do we migrate those?
There is no need. Closed projects are an archive, and an archive can stay where it is. Migration targets what is running and what is starting, because the value is in recording as things happen, not in retyping the past.
How long does it actually take to get a project running on the system?
Entering a project, its sites and its team is about an hour of work. The real period is the first few weeks while the site team gets used to recording daily — and that habit, not the setup, is what decides the outcome.
Do we need internet on site for it to work?
Not for field entry: attendance, reports and incidents are captured offline and sync when the connection returns. The analytical screens need a connection by nature, since they read everybody's data.
Does WhatsApp still get used after the move?
Yes, and that is fine. It stays for fast coordination, while anything worth keeping — a photo, an approval, a request — ends up in a record you can search and return to a year later.
Start with one project and run a month on it
Try muqawil on a single live project: attendance and daily reports first, then the bill of quantities and cost — in Arabic and English together.