Last month I was on a call with a project director — large mixed-use scheme, central London, about 18 months into construction. I asked him a simple question: "If I wanted to know the current status of the steel frame on Level 4 right now, how would I find out?"
He laughed. Then he listed the steps. Open Tekla to check the model. Open Navisworks to see if any clashes were flagged against it. Open the project drive to find the latest RFI. Open the contractor's portal for the fabrication schedule. Open the cost tracking spreadsheet — Excel, obviously — to check if the change order went through. Open the coordination meeting minutes from last Thursday. Maybe send a WhatsApp to the site manager asking if they actually installed it yet.
Seven steps. At least four different applications. And he still wasn't confident the answer would be correct.
The 10-app reality
This isn't an unusual story. Research shows the average construction project runs on 10 different software applications. Not 10 apps across the company — 10 apps on a single project. Revit for the architects. Tekla for the structural engineers. Navisworks for coordination. Bluebeam for markup. Procore or Aconex for document management. Excel for cost tracking (always Excel). Power BI or Tableau for the dashboards nobody updates. SharePoint or Google Drive for file sharing. WhatsApp for anything urgent. Email for everything else.
Each of these tools works fine in isolation. Some of them are genuinely excellent at what they do. The problem is that none of them talk to each other in any meaningful way.
The result? 75% of decision-makers in construction say they spend too much time managing data across disconnected systems. About 20% of construction professionals report spending 10–15 hours per week just searching for information they need. Not doing work — searching for the information they need to do work.
The productivity paradox
Here's a number that should keep every construction executive awake at night: since 1970, construction labour productivity has declined by 30%. In the same period, overall economic productivity in the US more than doubled. Manufacturing figured it out. Logistics figured it out. Finance figured it out. Construction went backwards.
We've spent billions on software. More tools, more platforms, more dashboards. And somehow we're less productive than we were 50 years ago.
I don't think the problem is a lack of technology. I think the problem is too much technology that doesn't connect. Every new app promises to solve a specific pain point, and it probably does — but it also creates another data island that someone has to manually bridge to everything else. The bridge is usually a human being with a spreadsheet and a lot of patience.
What fragmentation actually costs
IDC estimates that companies lose 20–30% of revenue annually due to data silo inefficiencies. In construction, where margins are already thin — typically 2–5% — that isn't just a productivity issue. It's existential.
Think about what happens when your data lives in silos:
- The QS can't see model changes until someone exports a new Navisworks file and emails it over. By then, the quantities have shifted and the cost plan is already wrong.
- The site team discovers a design change when they try to install something and it doesn't fit. The RFI was raised three weeks ago but nobody told them the model was updated.
- The project manager reports progress based on last week's data because this week's data hasn't been compiled yet. The client gets a version of reality that's already outdated.
- The design team makes a change to the structural grid. The MEP team doesn't know about it for two weeks. When they do find out, half their coordination is invalid.
Every one of these scenarios leads to rework, delays, or both. And every one of them is fundamentally a data connectivity problem, not a competence problem.
Why "integrations" don't fix it
The standard industry response is integrations. API connectors. Middleware. CSV imports and exports. Build a pipeline from Tool A to Tool B, and now they're "connected."
Except they're not. An integration is a scheduled data transfer — it moves a snapshot of information from one place to another at a point in time. By the time the data lands, it's already stale. And if anything changes in either system's data structure, the integration breaks silently and nobody notices until someone makes a decision based on wrong numbers.
We've heard from project teams where the "integrated" cost data was three weeks behind the model because someone forgot to run the sync script. Three weeks of decisions made on outdated quantities. The change order that resulted cost more than the integration software.
One model, not one more tool
The answer isn't another app on top of the pile. It's removing the pile.
What if your Revit architecture, your Tekla steel, your IFC exports, and your Navisworks coordination all lived in one federated model — not converted, not exported, but genuinely unified? What if any change in any discipline was visible to every other discipline immediately, not after the next scheduled sync or the next coordination meeting?
And what if anyone on the project could query that model in plain language? Not just the BIM team. The project manager. The QS. The site supervisor. "What changed in the structural model since Monday?" "How many linear metres of ductwork are on Level 3?" "Which elements were affected by yesterday's revision?"
That's not a fantasy. That's what federation should have always been. Not file-based exchange with all its data loss and version conflicts, but a live, queryable environment where every discipline's model contributes to one source of truth.
The real integration is no integration
The construction industry doesn't need better integrations between 10 apps. It needs fewer reasons to use 10 apps. When the model is the database — when quantities, changes, clashes, and costs all derive from the same federated source — most of those apps become redundant.
That's what we're building at Criad. Not another tool in the stack. The layer underneath that makes half the stack unnecessary.
Because every hour your team spends searching for data across disconnected apps is an hour they're not spending on the work that actually moves the project forward.
Harsh Singh is the co-founder and CEO of Criad, an AI-powered BIM platform that federates construction models into a single live source of truth. If your project data lives in too many places, let's talk or join the waitlist.