Eight active sites. Two hundred workers. One WhatsApp group per project, and an owner who found out about problems after they had already cost money.
ImarHub was not purchased off a shelf. It was designed around the way the client actually operates, their process flow, approval chains, site structure, and workforce profile. Not the other way around.
Most mid-sized construction companies hit the same wall with enterprise software: the product is polished, but implementation forces the business to reshape itself around the system. Staff end up running the software in parallel with the WhatsApp groups and spreadsheets it was supposed to replace.
ImarHub was built to eliminate that failure mode entirely. Every module, workflow, and approval step was mapped to the client before a single line of code was written. The system conformed to the business, which made adoption a matter of days rather than months.
It is a one-time build with no recurring licence, no per-seat fees, and no vendor dependency. It runs on infrastructure the client controls and can scale to new sites, new users, and new modules without a commercial ceiling.
The client is a Saudi-based civil and MEP subcontractor with over 15 years of operation across the Kingdom. The company grew from a single-site fit-out contractor into a multi-project subcontracting firm handling civil works, MEP installations, and infrastructure packages for major real estate developers and government-linked main contractors.
By the time they engaged AppWorx, the client was running 8 to 12 active sites simultaneously, employing over 230 workers across Pakistani, Indian, Egyptian, and Filipino nationalities, and turning over approximately $22M in annual contract value.
The business had the contracts. It did not have the systems to match the scale it had grown into.
The operational pain was not a single problem. Each issue was manageable in isolation, together, they created an operational ceiling that was stalling growth.
The owner was spending his time chasing information that a system should surface automatically. Growth was stalled not from lack of contracts, but from running a $20M+ operation on infrastructure built for a $2M one.
Progress was reported informally through voice notes, WhatsApp photos, and competing spreadsheets. When the owner needed the actual completion percentage on a specific block or zone, the answer required phone calls.
Across eight sites, that delay made every decision stale: labour allocation, resource deployment, and client updates all depended on information that arrived too late.
Payment certificates were created in Word or Excel, printed, signed, scanned, and emailed. Revisions became file versions with no reliable history.
Disputes about certified quantities were regular because there was no audit trail, only conflicting memories and different spreadsheet versions. Each dispute cost days of commercial time.
A site engineer identified a material need and texted procurement. It may or may not have been actioned. There was no record of who requested what, when it was approved, whether it was ordered, or whether it was delivered.
Overstock and shortages coexisted across the same portfolio. Materials sat idle on one site while work stopped on another waiting for items that should already have been there.
Foremen did not fill out daily site reports consistently. Photos were scattered across personal camera rolls and WhatsApp batches with no structure.
The daily site report is a legal document under most Gulf construction contracts. In practice, the record was a collection of messages, not a structured, timestamped report.
When scope changed on site, instructions came verbally or through informal WhatsApp messages. Work was performed, payment claims were submitted later, and the subcontractor had no formal variation log showing timely notification.
Under FIDIC-based Gulf contracts, a variation claim without a timestamped submission record at the time of instruction may be rejected even when the work was completed. This was the most financially dangerous gap in the operation.
With more than 200 workers across eight sites, paper attendance created payroll errors, daily headcount discrepancies, and productivity blind spots.
There was no reliable way to know how many workers of which trade were on which site on any given day without calling the foreman and hoping the count was accurate.
ImarHub was built as seven operational layers, each with defined scope and defined interfaces with the layers it works alongside.
The owner gets a single-pane view across the entire portfolio: every active project, current completion, budget consumed against contract value, outstanding variation value, overdue approvals, and last daily site report timestamp.
Built for foremen and site engineers working in intermittent connectivity, direct sun, dusty screens, and a multi-nationality field environment.
The most financially critical module: a full certification-cycle engine from IPC claim submission through adjustment, approval, document generation, acknowledgement, dispute, and retention release tracking.
A variation register that logs scope changes at the point of instruction, attaches evidence, submits formal notices, and creates signed immutable timestamp records that protect the subcontractor contractually.
Hierarchical BOQ model with recursive tree structure, real-time earned value calculations, material requests against BOQ line items, procurement approvals, delivery confirmation, and schedule-aware stock alerts.
Drawing register by number, title, revision, and status. Site app users always receive the current revision, superseded drawings are archived, RFIs are tracked, formal correspondence is logged, and document expiry alerts prevent compliance gaps.
A lightweight secure-link portal where subcontractors view payment certificates, submit IPC claims, acknowledge certified amounts, flag disputes, and download formal PDF records without a full platform account.
Live project P&L, certified income, committed costs, projected final margin, cash flow projection, retention summary, VAT treatment, and accounting exports compatible with Xero, QuickBooks, and Sage.
.NET 10 clean architecture, PostgreSQL, React Native, Arabic-RTL primary interfaces, immutable audit records, and WhatsApp Business API notifications.
Clean architecture with domain, application, infrastructure, and API layers. SQL-backed event outbox for notifications, document generation, and financial recalculation events.
Recursive CTE-optimized BOQ schema with separate read models for portfolio-level dashboard aggregation so reporting does not hit write-side transaction tables.
Offline-first mobile app with local SQLite store and vector-clock conflict detection for concurrent field submissions across multiple sites.
Templating engine with Arabic RTL support, Arabic numeral formatting, bidirectional table layout, and immutable storage for generated certificate PDFs.
Critical actions write to an append-only audit ledger as part of the same database transaction. A certificate cannot be approved without the ledger entry.
Owner, project manager, site engineer, commercial manager, and director access is scoped by project and combined through composable roles.
Arabic-RTL primary, full layout flip on language switch, and icon-based display mode for field workers operating in a third language.
Operational alerts are delivered to the relevant role holder through WhatsApp Business API, not only through an in-app notification center.
What previously required phone calls is now visible without asking. Overdue daily reports flag automatically. Payment certificates move through a documented approval cycle. Variation orders are on record at the point of instruction, not at the point of claiming.
The commercial impact on subcontractor relationships was immediate. Disputed certification rounds dropped because both sides work from the same measured quantities in the same system, with adjustments visible and documented.
AppWorx continues to develop ImarHub under a Continuous Development Contract. Phase 1 and Phase 2 are live. Phase 3 and Phase 4 are in active development.
The civil construction background Mahmoud brings to this kind of engagement is not a marketing line. It is the difference between an agency learning what a payment certificate is and a partner who already understands a FIDIC payment cycle, variation timestamp protection, BOQ structure, and field sync constraints.
That domain fluency compressed discovery. The risks did not need to be explained, and the technical decisions, immutable audit trail, recursive BOQ schema, vector-clock conflict resolution, and contractual timestamp model, were scoped correctly from the start.
The common Gulf subcontractor objection to Procore is that it is too expensive, too Western, and overloaded with features they do not need. ImarHub was built for the actual operating model: payment logic, workforce profile, document requirements, language infrastructure, and site realities.
"This is what it looks like when a system is built by people who understand the operation from the inside."
Eight sites. Before ImarHub, I knew what was happening on a site when I called the foreman. Now I open one screen and everything is there, the completion percentages, the DSRs, the variation register, the payment certificate status. The variation timestamp alone has already protected us on a claim that would have been rejected under the old process.
Tell us what you are managing and how. We will tell you honestly whether the answer is a custom system, and if it is, what it would actually take to build it.