This article is a guest contribution from Niyi Oladepo, Vice President of Finance at Pike Industries (a CRH company). The views expressed are solely those of the author.

It all started with a hypothesis, not a technological breakthrough.

State DOT bid results are public records. In New Hampshire or Maine, any contractor bidding on a highway project has their line-item prices made public after the award. Mobilization, drainage pipe, hot mix asphalt, striping—every item, one after another, posted as PDFs on the state DOT website.

My hypothesis was: if historical bid results influence how experienced contractors price their work, then I should be able to model that behavior with a reasonable degree of confidence. Validating that hypothesis took months, and early versions did not perform well.

Early Failures: Why the Model Kept Getting It Wrong

The AI models I initially used struggled with the volume and consistency of bid summary data. Early outputs included: item prices that didn't apply to the specific project type, competitor behavior patterns attributed to the wrong geographic regions, and analyses that sounded confident but were useless in practice. In one backtest, the tool produced results 52% below the actual winning bid—not because of incorrect unit prices, but because it ran on an incomplete item list and couldn't flag what was missing.

I spent months rejecting those outputs, arguing with the model, pushing back, challenging its reasoning, insisting it base its conclusions on what the data actually showed rather than what it wanted to infer. When early outputs reached the estimating team, our estimator Bethany commented, "That's interesting." Greg, our senior construction manager, asked how I did it. Their feedback shaped the tool as much as any feature I deliberately built. One key point that was never overlooked: low price was not the goal. The system needed to find where our pricing position could create a real advantage, not just where we could cut prices.

What the System Really Needed to Know

The tool operates in three layers, and the division of labor between them was carefully considered.

Layer One: Historical Baseline Pricing.Based on 56 New Hampshire DOT projects ($394 million in total contracts) and 90 Maine DOT projects ($445 million in total contracts)—146 projects combined, $839 million in contracts, nearly 4,300 bid item data points—the AI establishes historical pricing benchmarks for competitors on specific items, project types, and regions, covering four dimensions: item type, project size, project category, and geographic area.

Item type matters because competitors' strengths are not uniform across categories. A contractor with an advantage in hot mix asphalt plant capacity will bid aggressively on asphalt tonnage but conservatively on labor-intensive drainage work. This pattern is invisible in a single project but becomes clear across 56 or 90 projects. Project size matters because the same contractor prices a $2 million project (where crews need to be filled) very differently from a $20 million project (where bonding capacity and cash flow dominate decisions). Geographic region matters because NHDOT's six districts and Maine DOT's five districts each have different competitive landscapes. A contractor dominant in pavement reclamation near Portland may be nearly absent in Aroostook County, where hauling economics make them uncompetitive on that type of work.

Layer Two: The Estimator Takes Over Completely.No dataset can know whether a project is night-only, whether a guardrail subcontractor is available in that market, or whether a competitor just won three large projects and is bidding conservatively to protect capacity. Estimators score five dynamic factors (schedule constraints, site and production conditions, subcontractor dependence, technical complexity, current market conditions), each corresponding to a price adjustment. This scoring is professional judgment, not data retrieval.

Layer Three: AI Re-Engages.When multiple dynamic factors are scored, some correlate with each other, and simple addition becomes misleading. Night work and project complexity are the classic example: all night work inherently introduces project complexity, so adding 5% for each doesn't represent an additional 10% cost. The AI incorporates known relationships between factors and applies a blended adjustment—in this case 7% rather than 10%—capturing the true overlap rather than mechanically stacking independent adjustments.

Any CFO who has built a capital allocation scorecard or an acquisition pricing model will recognize this problem: scoring correlated risk factors independently and adding them up overstates total risk. Building correlation logic into the model produces consistent outputs without stripping estimators of their judgment on inputs.

What We Learned

The most critical decision we made was to start with data that already existed. DOT bid summaries are public, structured, and directly tied to hundreds of decisions we make every year. We simply organized what we already had. Most organizations have at least one dataset that fits that description but haven't built a process around it yet.

What I didn't anticipate was that a significant portion of the value came from the failure period, not from narrowly avoiding failure. The 52% range deviation exposed a specific flaw in how the model handled incomplete inputs; the phantom suggestions pointed to areas where data density was too thin to support reliable inference. A model producing wrong answers during an iteration period, being questioned and corrected by practitioners, is not a sign that the approach is failing—it's precisely the approach working.

The boundary between AI and estimators ultimately proved to be the most important design decision in the entire system, and we got it right more out of necessity than foresight. Estimators' judgment on competitor backlogs, subcontractor availability, and seasonal market conditions cannot be extracted from historical data because that information simply doesn't exist in historical data. Once we accepted that as a permanent constraint rather than a temporary problem to solve, the architecture naturally took shape: AI handles history, estimators handle the present, and deduplication logic handles the interaction between the two. This division is not a compromise—it's the fundamental reason the output is worth using.