"How much does it cost?" sounds like a simple question, and in the construction software market the answer is rarely a single number. The common model — a price per user per month — looks cheap in the demo and becomes expensive at exactly the moment the rollout succeeds and the team grows. This is not a product comparison. It is a method for working out what you will actually pay over three years, and what to ask before you sign.
Key takeaways
- Per-seat pricing raises your cost every time you widen adoption — the opposite of what you want from a system meant to reach the whole site.
- Implementation, migration and training fees can equal a full year of subscription and never appear on the pricing page.
- Model the cost over three years against realistic team growth, not against the first month.
- Modules locked behind a higher tier are a deferred price increase, not a choice.
- Spend the trial testing the worst case — a site with no signal and an old handset — not the best one.
The per-seat trap
Most construction platforms are priced per user per month. The logic is clear from the vendor side, but its effect on a contractor runs directly against the point of the system: you are buying a tool to unify information between office and site, and then charged for every additional person you let into it.
The practical result is familiar to anyone who has lived it. Five seats get bought for the engineers, the supervisors and foremen stay outside the system, and data goes back to paper and WhatsApp at exactly the end where the information is created. The system works in the office and never reaches the site — the one place it was supposed to reach.
| Model | Team of 5 | Team of 20 | Team of 60 |
|---|---|---|---|
| $25 per user / month | $1,500 a year | $6,000 a year | $18,000 a year |
| $45 per user / month | $2,700 a year | $10,800 a year | $32,400 a year |
| Flat company price | Unchanged | Unchanged | Unchanged |
None of this makes per-seat pricing inherently bad. It is sensible for a tool used by a fixed number of specialists — design software, say. But a system meant to capture attendance and receive daily reports from every site is by its nature something everyone touches, and pricing that resists that is resisting the reason for the purchase.
The costs that never reach the pricing page
The gap between the advertised price and the real first-year cost is sometimes a multiple. The items below are not tricks — most are entirely legitimate — but they surface during negotiation rather than during comparison, and that is where the mistake gets made.
- Implementation and setup: a one-off charge that can equal a full year of subscription.
- Data migration from your current system or from spreadsheets — usually billed hourly.
- Training: included, per session, or per person? And what about the new hire six months in?
- Support: is Arabic-language support included or a tier up? What response time is committed?
- Integration with an accounting package — often a separate and expensive line.
- Additional storage: one photo-documented project consumes space faster than you expect.
- Data egress fees on the way out — worth asking about before you go in, not after.
Building a three-year cost model
Three years is the right horizon: less than that ignores the cost of switching, more than that is guesswork. The model is simple and fits in one spreadsheet.
Estimate user count per year
Not the number of engineers — everyone who will need to be in the system: supervisors, storekeepers, the accountant, and possibly operatives if attendance runs through a phone.
Total the annual subscription for each scenario
Including any annual uplift the contract permits. Many contracts allow a yearly increase, and it compounds.
Add the one-off first-year costs
Implementation, migration, initial training. These do not recur, but they load the first year heavily and change the comparison.
Add the cost of your own team’s time
The most commonly omitted line. If rollout consumes three months of an engineer at 30%, that is a real cost and belongs in the model.
Subtract what you stop paying for
Tool subscriptions you retire, manual data-entry hours, and the cost of errors the system prevents. That is the other side of the equation.
The right decision is not choosing the cheapest option. It is knowing the real number before signing, instead of discovering it in year two.
What to actually test during the trial
Most trials are wasted demonstrating the things that work well. The purpose of a trial is the opposite: to find where the system breaks before you pay, not to confirm that the interface is attractive.
- Run it on a real site with no signal: do attendance and the daily report capture offline and sync later without duplicating?
- Try it on a cheap old handset — the device your supervisor actually carries, not yours.
- Enter a real BOQ item with its real quantities and check the report that comes out against what you already know.
- Ask to export your data on the last day of the trial. How easy it is to leave says a lot about vendor confidence.
- Test Arabic on every screen: printed reports, numerals, and text direction in exported PDFs.
- Put one genuine site user on it and watch: did they get through it without lengthy training?
Questions to ask before signing
These rarely get asked, and each one exposes something the demo does not. Ask them in writing and keep the answers.
- Is the price fixed for the contract term? What is the cap on renewal increases?
- What happens to my data if I stop paying? How long do I have to export it, and in what format?
- Are all modules included, or are some in a higher tier? Ask for the full list.
- Are there limits on projects, sites or storage? What happens when a limit is reached?
- Where is data stored geographically, and who on the vendor’s team can access it?
- What is the backup arrangement, and has a restore ever actually been tested?
- Can a subcontractor be onboarded as a separate entity with isolated data?
When to walk away
Some signals are enough to end the conversation on their own, however attractive the price. Most of them are about trust rather than features.
- Refusal to give a clear price before "a call to understand your needs" — a price that depends on an estimate of your budget is not a price.
- No clear route to exporting all of your data in a usable format.
- A decision resting on a "coming soon" feature — evaluate only what exists today.
- Machine-translated Arabic on core screens, or PDF reports that do not handle text direction.
- A contract with no availability commitment and no defined support process, alongside two years payable up front.
In the end the cost of the wrong system is not the subscription. It is the year spent persuading your team to use it, followed by the data you lose when you decide to switch. Choose on a three-year view, and test against the worst day on site.
Frequently asked questions
Is flat pricing always better than per-seat?
Not always, but usually in construction specifically, because correct use means getting the whole site into the system. If your team will stay at five office users, per-seat may well be cheaper. If the goal is to reach supervisors and operatives, flat pricing removes the financial obstacle to doing exactly that.
Monthly or annual billing?
Monthly buys flexibility at a higher price; annual buys a lower price for a longer commitment. The practical rule is to pay monthly through a genuine trial inside one project, and move to annual once the team has proved it actually uses the system rather than agreeing that it should.
How much of a project budget should go on project management software?
There is no standard percentage, and the more useful comparison is not against the project budget but against the cost of the problem: data-entry hours, errors in payment applications, and claims never submitted for want of documentation. If the annual cost is less than the value of one average dispute, the question is not price but fit.
Do I still need separate accounting software?
Usually yes. Project management systems track cost at project and item level; they do not replace a certified accounting package for ledgers, tax and statutory payroll. What matters is that data can move between them without double manual entry.
What if my team refuses to leave spreadsheets?
The resistance is usually not to the tool but to doing the work twice during transition. Start with one project and one module — attendance or the daily report — and retire the old file immediately instead of running both. A long parallel run is the single most common reason rollouts fail.
One flat price, every module included
muqawil is priced per company, not per seat: bring the whole site in without the bill moving, and start with a free trial that needs no card.