Why 85% of Construction Estimators Still Use Excel — And What It's Costing Them

Walk into almost any construction business — a five-person residential builder or a general contractor running dozens of sites — and you'll find the same thing at the center of the estimating process: a spreadsheet. Industry surveys put it at roughly 85% of estimators still working primarily in Excel. Not as a scratchpad. As the system of record.

That number gets treated as a punchline, as if estimators simply haven't discovered better tools. They have. The reason Excel persists is more interesting, and understanding it is the only way to actually replace it.

Excel won by being forgiving

An estimate is a strange document. It has to be precise enough to bet a margin on, but flexible enough to change ten times before a job is won. A client adds a floor. A supplier's price moves. A scope assumption turns out wrong. The estimator needs to reshape the whole thing in minutes, without asking permission from a rigid piece of software.

Excel does exactly that. A blank grid makes no assumptions about how you build. You can model a bespoke foundation detail, a weird phasing plan, or a one-off client requirement without fighting a schema someone else designed. For a business where every job is a little different, that forgiveness is not a bug. It's the whole appeal.

So estimators stay — not because they love Excel, but because most "estimating software" trades away the one thing that made the spreadsheet usable: the freedom to model reality as it actually is.

What that forgiveness quietly costs

The problem isn't the spreadsheet itself. It's what happens to the estimate after the number is signed.

The estimate becomes an orphan. Once the job is won, the spreadsheet gets emailed around, saved to a shared drive, and slowly abandoned. The assumptions that produced the price — the labour rate, the wastage factor, the vendor quote that was only valid for two weeks — live in cells nobody opens again. Execution starts from a clean slate, disconnected from the thinking that set the budget.

Margin becomes something you discover, not manage. Because the estimate and the running job live in separate worlds, there's no live comparison between what you priced and what you're actually spending. The variance surfaces at closeout, when it's a post-mortem instead of a decision. Every experienced builder has felt this: the job "felt fine" right up until the final numbers came in.

Knowledge doesn't compound. Every estimate is a lesson — this trade always runs over, that supplier's quotes are optimistic, this kind of job carries hidden risk. In a spreadsheet, those lessons stay trapped in individual files and individual heads. The 200th estimate is built with barely more institutional memory than the 20th. The business does the reps but doesn't get the benefit of them.

Version chaos is a tax you pay on every bid. Estimate_v4_FINAL_revised_client.xlsx is a genre of filename for a reason. When the source of truth is a file that gets copied, emailed, and re-saved, someone eventually prices off the wrong version. On a thin-margin job, that single mistake can erase the profit.

None of these costs show up as a line item. That's exactly why they persist — they're diffuse, they're absorbed as "how construction works," and no single one is painful enough to trigger a change on its own.

The real requirement: keep the flexibility, lose the isolation

The mistake most estimating software makes is trying to win by being more rigid than Excel — more fields, more required steps, more structure. That's backwards. It attacks the one thing estimators actually valued.

The right goal is narrower and harder: keep the modelling flexibility of a spreadsheet, but stop the estimate from being an island.

That means an estimate that stays connected to everything downstream of it:

• When the estimate is won, its assumptions become the project's budget baseline — automatically, not through re-entry into a second system.
• As the job runs, actual spend is compared against those assumptions in real time, so margin is visible while you can still do something about it.
• When a supplier's price changes or a delay hits the schedule, the affected numbers update together, instead of drifting apart.
• When the job closes, its outcomes feed back — so the next estimate for similar work starts smarter than the last.

Notice that none of this requires taking the flexible grid away from the estimator. It requires connecting it to the rest of the business so the number isn't stranded the moment it's signed.

Why this is an AI-native problem, not a forms problem

You could, in theory, wire all of this together with enough integrations and discipline. In practice, that's exactly the "ten disconnected logins" trap that made people retreat to Excel in the first place.

What changes the equation is a system where estimating, site execution, procurement, and finance already live together under one AI layer — so the connections aren't integrations you maintain, they're just how the system works. A price change doesn't trigger a sync job; it ripples through the model because everything is one model. That's the difference between software that stores your estimate and a system that runs on it.

Excel earned its place. The answer isn't to shame estimators off it — it's to give them something that keeps what worked and fixes what didn't.

That's the part we're building.