This Q&A is a companion to AI in Preconstruction: Why Rewiring Matters More Than Speed, where Gaurav Singal makes the case for getting the foundation right before chasing AI speed.
Every estimator in preconstruction is getting pitched AI tools right now.
Tools that read plans, flag scope gaps, predict what to bid. Some are genuinely useful. Many are general-purpose software with a construction logo applied on top.
For the people receiving those pitches—GCs, trade contractors, estimators, building product manufacturers—there's no reliable way to tell the difference. The demos look similar. The claims sound alike. And the cost of trusting the wrong tool isn't abstract: it shows up in margin, in errors, in bids you lose or, worse, win at the wrong number.
That is the concern behind this conversation with Gaurav Singal, Chief Technology Officer at ConstructConnect®. His work requires him to understand both sides of the problem. He has to understand how the technology works. But he also has to understand what construction professionals need before they trust software with a real number.
His most revealing answer is not about an AI feature ConstructConnect plans to build, but about one impressive AI development that the team decided not to pursue.
The risk starts with one wrong number
For an estimator, the fear is not always that AI will take their job. The more immediate fear is that it will make a mistake that goes unnoticed.
Singal put that concern plainly: “The thing nobody says in the room but everybody thinks: Am I going to be the person who trusted the AI and got burned on a bid?”
Estimators and project managers have spent years building judgement they trust. Now they're being asked to rely on something they can't fully understand and stake real margin on it. Singal doesn't think that concern is misplaced.
Singal said: “The smart ones know the accountability doesn’t transfer when the software is wrong.”
That is why trust matters more than a fast demo. A vendor can promise speed, but the construction professional still owns the result. Singal does not see that concern as resistance to change, but a fair response to real risk.
Singal put the responsibility this way: “We’re asking them to extend trust to a system before the track record is there to earn it.” He added: “The honest answer from anyone selling AI to construction right now is: that concern is legitimate, and it should shape how you evaluate and deploy every tool. If a vendor doesn’t acknowledge it, walk away.”
A plan shows what is there, not what is missing
The difference between general AI and construction AI becomes clearer when an estimator opens a set of drawings.
A plan may show walls, doors, equipment, and finishes, but an experienced estimator is also looking for what the drawings leave unclear. They are checking for gaps between trades, conflicts between documents, and details that were never coordinated beyond what exists on the page.
"Documents tell you what's on the plan," Singal said. "They don't tell you what's not there."
That judgement does not come from reading one document faster. It comes from seeing the same problems across hundreds of jobs. Singal described that experience this way: “An experienced estimator reads a set of drawings and immediately starts cataloging what’s missing like scope gaps, ambiguous interfaces between trades, details that aren’t coordinated. That judgement comes from hundreds of jobs, not from the document in front of them.”
A general-purpose system can find words and patterns. That does not mean it understands the risk behind them. It may not know that a specification conflicts with a drawing or that a familiar scope often runs over the printed schedule of values.
Singal said: “General-purpose AI reads what’s written. It doesn’t know what the architect forgot to coordinate, or that this spec section quietly conflicts with that one, or that in this market, on this type of job, the mechanical scope always runs over the printed schedule of values.”
For Singal, the key difference is context. Construction software must understand how pieces of a project relate to each other and it must also recognize when the absence of information creates a risk.
He explained: “The gap isn’t reading speed or data processing. It’s knowing what questions to ask before you take the risk. That’s what construction AI has to encode: what things mean in context, how they relate to each other, what the absence of something signals. That's what separates purpose-built from rebranded. It's not a marketing distinction. It's the difference between a tool that helps you move faster and one that gets you in trouble faster."
Why ConstructConnect passed on automated bidding
Many AI conversations focus on what can be automated. Singal’s answer takes a different approach. He points to a use case that sounds efficient, then explains why the team decided not to build it.
When asked which use case sounded compelling but was not being pursued, Singal answered simply: “Automated bid.”
The idea is simple. A system could look at a contractor’s past win rate, capacity, project type, owner relationship, and competitive landscape and score the jobs a company should pursue.
On paper, that sounds useful. Estimating teams are busy, and a score could seem like a clear way to focus their time. But a bid decision often carries information that is difficult to put into a model.
Singal recalled: “We looked at it seriously. We passed.”
His reason says something about how he thinks tool-building should work. The bid decision, Singal said, isn't a data or AI problem.
"A GC decides to bid a hospital addition at thin margin because they want that owner relationship for the next decade. A trade contractor passes on a job with strong numbers because they've worked with that GC before and they know exactly how the change orders are going to go. Those calls are strategic, relational, and in some cases personal."
A model score could make that judgement look more certain than it really is. In addition, it could also give people a number to point to when they should be owning the decision themselves. For Singal, the goal is not to remove judgement from the process. It is to help professionals use technology where it can support their work, while keeping important decisions in human hands.
“I’d rather have an estimator looking the right person in the eye and owning that call than have a system manufacture a false confidence interval around a decision that was always going to be made on instinct and relationship. Some judgement should stay human. That one should.”
Where the software stops and estimating judgement starts
That same boundary appears in the daily work of preconstruction. Singal names three areas where construction professionals should remain closely involved.
Scope gaps. "AI can read what's in the documents. Identifying what isn't there, the undrawn detail, the scope that falls between the trades, still requires human judgement. That's where the real margin risk lives on almost every job. A model trained on construction documents learns to process what's written. It doesn't yet have the instinct to ask: who's responsible for that slab edge Condition the drawings don't address?"
Exclusion language. "The language you write into your bid to protect yourself is a professional judgement call, not a text-generation task. A capable AI can draft it. A sharp estimator has to own it. If you let the software write your exclusions and you don't read them with the same critical eye you'd bring to any other risk, you've transferred accountability without transferring the liability."
Anything relational. "Knowing that a particular GC writes aggressive change orders, that a certain sub has been consistently late on schedule, that this owner treats the initial scope as a starting position: none of that lives in a document. AI can process structured data from past projects. It can't read a relationship, and it can't tell you when the person across the table isn't telling you the whole story. That read is still yours."
Three questions to ask before trusting an AI tool
The best way to test an AI vendor is to move past broad claims about accuracy and efficiency. Ask questions that reveal how the tool was built, how it was tested, and what happens when it is wrong.
Where did you training data come from?
A construction label does not explain what makes a system construction specific. Buyers should ask about the data behind the tool and the people who prepared it.
Singal’s first question is direct: “First, what construction-specific data went into the system, who labeled or evaluated it, and were those people experienced in construction?”
Before trusting a product, buyers should find out whether construction shaped the system from the start or was added later.
Singal said: “A lot of what’s being sold as ‘construction AI’ is a general-purpose language model with construction documents dropped on top. The outputs look plausible until they don’t. Ask for the data lineage. Ask what was purpose-built for construction, what was adapted from a general model, and how the system was evaluated on real construction workflows. If the vendor can't explain that clearly, that's a red flag.”
What is your error rate on the work that matters to me?
An overall accuracy number may not tell a contractor much. The useful question is how the system performs on the assemblies and project types that create the most risk.
Singal asked: “Second, what’s your error rate on the assemblies that matter most to me, broken out by project type? Not aggregate accuracy but specific error rates on the line items that will damage a job if they’re wrong. Concrete, structural steel, MEP rough-in on a school versus a hospital.”
A vendor should be able to explain how it tests those results. If it cannot, the buyer should keep asking.
Singal advised: “If the answer is a marketing metric, push harder. If they can’t produce it, they haven’t done the testing that bid work requires.”
What happens when the AI is wrong?
This may be the most important question of all. A tool used in preconstruction should not ask users to accept an answer without showing how it reached that answer.
Singal asked: “Third, when the AI is wrong, what does the audit trail look like? Can you see exactly what the model calculated and why? Can you trace the output back to the source document or assumption it came from?”
That record gives the estimator a way to review the result instead of accepting it on faith.
Singal’s standard is clear: “If the answer is ‘trust the output,’ that’s not an AI tool ready for preconstruction.”
A vendor should be willing to show its work and explain its limits. As Singal put it: “You’re not buying software. You’re extending trust. Make them earn it the same way you’d evaluate any subcontractor you’d never worked with before.”
For construction professionals, that may be the most useful way to think about AI. The right tool is not the one that promises to replace judgement, but the one that helps an experienced professional make a better decision, while making it clear where the software stops and responsibility begins.
Gaurav Singal is Chief Technology Officer at ConstructConnect. Read his piece on why the construction industry needs to rewire its technology foundation before AI can deliver on its promise: AI in Preconstruction: Why Rewriting Matters More Than Speed.
Read Gaurav Singal’s full Forbes article to learn more about how ConstructConnect is building for the next era of AI.
.png)
