Civil Engineering Cost Estimator

Project Deep Dive

Atlas Civil Construction had built up a massive estimation spreadsheet over years of project work, covering everything from initial site excavation through roadworks, sewers, and watermain construction in one workbook.

What the spreadsheet did

The workbook priced a civil site job across five work categories - excavation and removals, roadworks, sanitary sewers, storm sewers, and waterworks - with well over a hundred individually priced work items spread across them. Every row broke a unit price into its full cost buildup: labor, permanent material, subcontractor cost, company equipment, and outside equipment, summed into a total unit price for that item. Entering a quantity against a row extended that unit price into a line total, and each category rolled its line totals up into its own subtotal before all five fed a single grand job total, with a markup percentage applied at the bottom to arrive at the final bid figure. Atlas maintained this exact structure in two parallel workbooks - one priced in US customary units (feet and inches) for domestic bids, the other in metric units (millimeters and cubic metres) for jobs quoted to metric-standard specifications - each carrying its own independent rate table built up the same way.

How we converted it

We rebuilt the calculation engine in JavaScript, keeping the same five-category grouping as collapsible panels rather than one long printed list. The workbook's five-part cost buildup for each item was fixed data, not something an estimator adjusted row by row, so we collapsed it to a single all-in unit rate per line item extracted from the workbook, preserving the exact arithmetic - quantity times rate - behind each line total. Every item stays hidden behind a small toggle until an estimator needs it, then expands into a quantity field; entering a number recalculates that line instantly, rolls into its category's running subtotal, and updates the overall project total, which also applies a user-entered markup percentage the way the workbook's bottom-line formula did. We shipped it as two separate builds sharing identical panel structure and calculation logic but each wired to its own rate table and unit labels, so the imperial and metric estimators could be deployed, updated, and re-priced independently without either rate table touching the other.

What changed for the client

For estimators, the workflow moved from scrolling a dense spreadsheet looking for the right row and re-checking rate cells to opening a category panel, entering quantities only for the items that apply to a job, and reading category and project totals as they go instead of building them by hand. The same markup percentage that closed out the original workbook now drives the final total automatically. Running an estimate against metric-spec requirements - millimeters and cubic metres instead of feet and inches - no longer means re-deriving formulas by hand; it is the identical interface pointed at a second, independently priced rate table built the same way as the first.