The thing that shipped was a plain website that pulls live data and ranks jobs. A.I. helped build it, but there’s no A.I. in it. I’ve watched this pattern play out across all of my peer group cohorts since last fall.

Back then, the question was whether non-developers could build anything usable. Today, that question is settled.

The interested part isn’t that builders can build software tools. It’s what they’re choosing to build. And it’s boring stuff. Not boring in any derogatory way—boring in the mundane, quotidian, day-to-day way that actually gets things done.

There’s no pie-in-the-sky futurism. No autonomous jobsite. We’re talking meat and potatoes tasks.

Sure, a handful of firms are standing up MCP connectors and doing genuinely impressive work. But the bulk of the A.I. wins this year are monthly report consolidation, invoice naming, bid intake setup, contract rate audits, spec reviews. Ho-hum operational stuff.

It’s easy to get caught up in the hype. Our 2026 report opens with agents, MCP, and multimodal perception as the technology backdrop. I put those in there as a primer because the industry needed to get educated on what they are.

But I’ve since watched people read it as a sequencing recommendation, which it was (hopefully obviously) not. A.I.’s real power in construction hasn’t come from any of those yet. It’s come from quotidian builds like the one the superintendent did. If you’re a contractor deciding where to start in 2026, agents are not the starting point.

Another thing worth noticing is where the builds are coming from. The most architecturally mature builds came out of project controls, not IT or innovation. A director built a contract intelligence system with reusable skill files encoding what standard terms look like at that firm, a source citation layer, and an audit tracker that appends itself every turn.

Understanding context management and how these A.I. tools actually work is sophistication at the operational level. People are upskilling themselves personally at the tooling layer.

I’m more and more convinced that A.I. is a horizontal tool in the same way Excel was, which means that every function and everyone will eventually use A.I. but no function will actually own it. In the same way that no company has an “Excel department”. In the same way there were Excel superusers, there will be A.I. superusers in every business.

Point solutions are done. There have always been hundreds of addressable opportunities in a construction business, and five years ago they were all ripe for the picking. But today, nearly all of them can be built in a weekend by somebody who has never opened a coding tool.

Which is strange because senior leaders across my network are still fielding discovery calls from Y Combinator grads who’ve found a construction pain point and think they’ve found a business. They’ve likely found something deceptively easy to solve for one user and extraordinarily hard to generalize across the industry—which is basically the defining feature of construction’s technology challenge.

As a well-respected construction tech VC in my network said: “What’s the last point solution I saw, or at least paid attention to? Very few. I think point solutions need to meet a very high bar.”

Add what that superintendent who made that risk dashboard said: “I’m just a superintendent. I’m not a technical guy by any means.”

And that’s your answer. Point solutions are dead.

I’ve been winning this work, so I can tell you what these buyers are actually purchasing, and it ties back to the wedge I described in the last piece.

The work is typically well defined at the business requirements level. It could be a go/no-go bidding automation, a project progress health dashboard, an RFI-adjacent spec bot, etc. It’s something their operations has identified as a pain point and that has early A.I. use showing a win. But oftentimes, the builder has little to no data foundation in place beyond their ERP systems. The vision of what they want far exceeds what the request implies.

The RFP describes the workflows. It doesn’t describe the ground those A.I. workflows need to stand on because the contractor can’t see their own foundation from inside their own business.

Underneath nearly every one of these requests, there’s field data that those workflows need that doesn’t exist yet. A consultant who says yes to the RFP is automating on top of all that. It’s lipstick on a pig, and the pig is the reason the contractor wrote the RFP in the first place.

So the real purchase is the ground that the A.I. workflow needs to stand on. Somebody has to make their data exist, make it mean something for their organization, and make it safe to operate on before the A.I. vision the contractor wants can hold water.

That roadmap is exactly what I’m going to give you.

I’ll show you the A.I. stack that dozens of contractors run today, every layer of it, and who inside the business is actually paying for it.

I’ll map the four grounds where that floor actually holds, what each one is made of, and how each one fails.

I’ll rank those grounds by how fast technology erodes them, so you know where to go first, and I’ll name the ones to prioritize.

I’ll walk you through how the A.I. work is actually driven, drawn from what I’m hearing across dozens of contractors in our A.I. peer groups and from the engagements in my own work.

And I’m going to lay out the fork every founder on this path hits early. Two paths with real comparable from other industries.

If you’re building in construction A.I., or helping someone who is, this is the piece I’d want in your hands.

Everything in this comes from the same place all my pieces do.

The first is my own time in the industry, with the better part of a decade on applied technology inside a construction company.

I spent nearly a decade at Bechtel, in the field on heavy projects from Canada to Papua New Guinea. A civil engineer by training, I was embedded in project management teams that ran pre-feasibility to handover. I’ve witnessed how large construction projects evolve and move over time, and how those demands change from project to project.

I then helped stand up the company’s Office of Innovation in 2016, helping pilot drones, sensors, and robotics on live jobsites. While much of the industry was still coming to terms with emerging technology, I was actively developing and molding best practices around field adoption in construction.

From there I went into entrepreneurship, helping co-found a jobsite computer vision startup, and since 2020 I’ve worked with ENR-ranked builders on exactly what this piece describes.

The other source is the A.I. peer groups I created through Placer Solutions. These are monthly, invite-only rooms where the leadership teams of dozens of construction companies work through how A.I. impacts their business, sharing honest feedback on the wins, challenges, and best practices of A.I. adoption. Nothing in this piece traces back to any single firm, but the peer groups help inform some of the patterns we’ll discuss and examine.

What follows is my read on what I’m hearing across the industry, what I’m seeing in my own engagements, and what I’d do if I were building the next generation of construction A.I. today.

Read more

I know that scenario well. In 2018, at Bechtel, I concepted and led a project we called Spool Hunter. We used drone photogrammetry to map every spool in laydown, compare it against the project’s 3D fabrication model, and ground-truth procurement before discrepancies went critical path. It went a step further than McKinsey’s version, since it was proactive rather than reactive.

I presented it on stage at ENR FutureTech that year:

So when the flagship scenario of construction’s agentic future turns out to be an eight-year-old demo, it’s worth grading the report carefully. The builders in my Strategic A.I. Peer Groups have spent all of 2026 field-testing its claims. Here’s how the report scores.

Where the report is right

The core advice is to focus on what the report calls "transforming domains," meaning end-to-end processes, instead of deploying “isolated use cases."

Their example is a schedule agent, which they argue creates more value "connected to procurement, design changes, cost forecasts, and field conditions" than as a stand-alone planning tool.

That’s true.

I also agree with the two premises beneath it. The report claims companies “do not need perfectly clean data to start creating value," and that most project workflows are "repeatable decision systems disguised as expert judgment."

Both of those are true, and the second premise is exactly why…

A.I. is cutting takeoffs and proposals from two days to two hours. Several-hundred-page specs are being categorized by trade in 30 seconds instead of half a day.

These aren’t trivial wins.

But notice what those wins have in common. They’re all narrow. Some are bought from a vendor, some are homegrown, and every one of them is a deployment pattern that the McKinsey report minimizes as “isolated”.

So the report almost gets there, but only partly, and that’s frustrating.

In my A.I. peer groups, the path that the McKinsey report advises isn’t workable. Diminishing the only pattern producing real, honest-to-God wins in AEC right now as “isolated” isn’t a serious position.

That’s not a contradiction of the report’s value claim—it’s a signal about what the report decided to disregard or simply ignore.

What connecting actually costs

Saying a schedule agent is worth more when “connected to procurement, cost, and field conditions” is a no-brainer. Anyone who’s run construction knows that those functions have to move together for a project to succeed.

The question a construction executive needs answered right now in 2026 is what “connected” actually means mid-project, and here the report goes totally quiet.

A client of mine, an ENR Top 50 builder, is redesigning procurement around exactly this kind of connected intelligence. The first thing they surfaced is that procurement doesn't live in one place. The procurement team keeps the material and equipment log. Project engineers own the submittal register. The superintendent owns the trade schedule.

Three functions, three trackers, three versions of the truth, reconciled by hand every time something moves onsite. Their procurement leads describe chasing schedule data and not trusting it.

On one project, a scheduler updated sequencing logic without input from the other two and it ended up delaying the project by three months. The connection is not a feature you switch on. It’s the organizational work of getting three functions to agree on a single version of the truth.

And that’s the friction inside one firm. Layer on construction's actual structure, where every project is its own P&L, with its own systems and its own trade partners who may or may not play along, and things get messy quickly.

That structure is what killed Spool Hunter, and it’s why I flinch at hanging a strategy on the pipe spool scenario that McKinsey led with.

In 2018, every piece of the technology existed. Photogrammetry could build a rough 3D picture of each spool. Computer vision could basically examine or segment them. Suppliers fabricated from 3D models.

But none of it was connected, because the supplier’s model wasn’t the EPC’s model, the procurement team didn’t get updates from the material management team, and the systems that needed to communicate sat on opposite sides of contract boundaries.

In retrospect it was shiny-ballism, and I say that as the guy who presented it at ENR FutureTech. Eight years later, in 2026, the models are incomparably better, yet the connective ground is largely unchanged.

Grading the clock

This is where the report’s sequencing falls apart for builders. McKinsey puts agentic orchestration in the near term, within 18 months, and data advantage work in the “medium term”.

The rooms I facilitate converge on exactly the opposite order.

By the report's own definition, "AI agents are not stand-alone software tools designed only for narrow tasks." They're embedded in core systems, orchestrating work across the project life cycle.

The chat-style agent succeeds because a human with a specific task hands it the right context for that one task, then checks the output like they’d check a junior employee’s first pass. The embedded kind McKinsey describes needs the context infrastructure to exist already: unified data, agreed definitions, no semantic drift, one version of the truth. That’s the “medium term” work they defined. Their clock runs backwards.

The field also ran this test on the report's flagship example, an estimating agent that assembles the bid and recommends contingency levels.

One member of my groups literally scoped this and attempted it. It never got off the ground: “Our data was not really clean or centralized enough," he told the group. Their head of estimating had assumed they were sitting on plenty of clean data to make it work, but that wasn’t the case. They consciously didn’t build it.

To put it bluntly: the literal flagship example from the McKinsey report was considered and abandoned because the “medium term” work wasn’t ready.

That’s not a firm failing to be ambitious. That’s a firm reading its own clock correctly and prioritizing their roadmap accordingly.

What to do instead

The risk in writing off “isolated” use cases is that it becomes a license to boil the ocean, a failure mode I’ve written about before.

To be fair, the report's own playbook starts narrower than its rhetoric. Their step one is prioritizing three to five high-value workflows, not rewiring the whole enterprise. The real difference is what it asks you to do inside those workflows: redesign them end to end around embedded A.I. agents, versus what I'd tell you, which is to run narrow wins inside them until the repetition exposes the gaps.

The firms getting it right in my peer groups follow a simple sequence. Understand your own systems. Understand your own culture. Get quick A.I. wins under your belt to build confidence. Then rinse and repeat on those isolated wins, diligently, because the repetition is what exposes the gaps, and the gaps are your roadmap.

Notice what that sequence builds: unified data, agreed definitions, one version of the truth, standardization. The "medium term" work McKinsey schedules for later is the byproduct of the narrow wins it minimizes. You don't clear the ground and then start. You start, and the starting clears the ground.

I’ve begun calling this “driving the wedge inward”, building depth into your own operational reality rather than breadth across someone else’s framework. More on that in a coming piece.

The one warning that’s already true

The report's sharpest claim is buried near the end. A.I. is automating the tasks junior staff used to build judgment on and weakening the training pipeline. My peer groups have already confirmed this.

One VDC leader, encoding his department's workflows, put it plainly: "I've basically automated away our former intern program. It’s on my list to rethink that position, because you need new people.”

McKinsey's fix is to train junior staff through “structured reviews, simulations, explicit standards, and exposure to real project failure cases." But judgment in construction was never built by curriculum. It was a byproduct of doing the grunt work across a rotating series of projects.

So here’s my prediction. The field non-manual headcount that exploded over the past 25 years will plateau or decline. Career advancement will come from being on the jobsite every day, learning the two things A.I. won't compress, which are strategic planning on the front end and owner delivery on the back end.

Knowledge work will go away. The knowledge-able worker will prevail.

Nobody has fully answered the question underneath that shift, including me. But if A.I. is absorbing the work that built your next generation’s judgment, someone in your firm needs to own the plan for replacing that judgment.

Most of the builders in my rooms don’t have that plan yet either. The difference is that they know it, but they’re taking realistic steps to address it.

Each of those startups had already done the hardest thing in construction technology: they had earned a contractor’s trust and proven a workflow.

That is what the platforms were paying for. Trimble didn’t build A.I. contract review. They bought the company that had already crossed that chasm.

Two years ago I wrote that construction tech startups have to cross the chasm twice, once inside a single contractor and again across the fragmented construction industry.

Since then I’ve continued to listen to how A.I. is actually landing in construction.

During that time, one pattern has emerged more than the rest: the thing most likely to kill a construction A.I. startup in 2026 isn’t the first chasm or the second. It’s the company that owns the bridge to your customer—the platform your customer already works inside.

To see why that’s a sharper problem than it looks, it helps to back up and understand how A.I. companies are sized up in the first place.

What makes an A.I. company

Anyone sizing up an A.I. company in 2026 is really asking two questions. Which layer of the tech stack is actually yours and how narrow is your wedge? Both questions are standard. Every investor memo asks some version of them.

Start with the layers. Almost every A.I. product is built from the same idealized layers, stacked on top of each other, and the standard read is which of those layers the startup actually owns.

#1. At the bottom is the raw intelligence like GPT or Claude or Gemini

Almost nobody building an A.I. product owns this. They rent it from one of the few labs who have the resources to build it, and so does everyone else, which means that on its own, the foundational A.I. model is no longer a moat.

The construction buyers I sit with would go one further and say that the model underlying their A.I. solutions is not only non-differentiating, it’s a liability they actively manage and prefer to treat it like a utility that turns on and off when needed.

#2. Above the A.I. model is the data layer

This is where a product feeds the A.I. model documents and records so that it answers from the real world instead of the open internet. The standard VC thesis is that this layer became table stakes two years ago with the advent of RAG plumbing, embeddings, connectors to SharePoint, etc.

But that’s not true in construction. One of the most advanced firms in my peer groups traced its wrong A.I. answers back to the source and found that roughly 70% of them came from bad data, not the model. The same firm’s hardest problem isn’t the A.I. at all. It’s getting agreement on what an “active project” even means.

The data layer is the first place where construction breaks the framework and it also breaks harder than anywhere else. I’ll come back to it.

#3. Above the data layer is the execution layer

This is where a product stops answering questions and starts doing the work of drafting RFIs, reviewing the contract, updating the schedule, etc. The edge here is how well the startup handles the messy reality of construction projects.

The wrinkle is that execution runs on processes and no two contractors operate the same way. Take something as universal as a change order. One firm routes it through the PM, another through a dedicated contracts group, a third built a custom tracker because that's how one big client wanted it, and someone still spends two hours a week hand-carrying data between systems.

What's changed is that contractors are now taking this ground back. Their own people are rebuilding these workflows in Claude Cowork and Copilot every week.

So the startups still standing in the execution layer (and there are quite a few of them) aren't selling a generic workflow, they live in the exception-heavy, integration-ridden work a contractor's own quick builds can't reliably hold.

#4. And at the top is the governance layer

The final layer makes the whole thing safe to run inside a real company. The permissions, the audit trail, the guardrails that keep it from doing something reckless with live data. The standard VC thesis is that this is the hardest layer to copy, so it’s where the most durable companies end up.

But the A.I. peer groups say differently. They would say that governance sits at the bottom, as the floor of the buying process. The buyers I sit with disqualify any vendor that can't say, on day one, what the agent can touch, what it keeps, and whether it trains on their data.

One firm in my peer groups runs a mandatory seven-step evaluation gate that nobody skips, not even the executives, and the security audit sits right in the middle of it. Another walked away from a well-funded vendor over a single non-answer on breach liability, with the observation that “the non-answer was the answer.”

Governance is the entry ticket, not the prize. And where it does harden into a real moat, that moat tends to accrue to the incumbents that the industry already trusts, not to the startup reading this.

Staying in the standard read for a moment longer, the first question a VC asks about any A.I. company is which of those layers is actually the company’s own and which are they renting?

And a surprising number of A.I. startups turn out to be a thin layer sitting on top of layers they don’t own. I wrote a whole piece on spotting them back in 2024 when the hard part was just telling a real product from a chat box.

That test still matters. It just stopped being enough.

That’s the first question. The second is who the product is for? The sharper and narrower that focus is, the better. One industry beats all industries. One workflow beats all workflows. One specific role at one size of company beats anyone who’ll pay.

A narrow, well-chosen slice is called a wedge, and a good wedge is hard to dislodge, because you fit a single job so well that a generalist can’t follow you into it.

And hanging over both questions is the one that matters most here. What happens when a bigger player decides to give your layer away for free?

In ordinary software markets, that player is usually a cloud giant or an A.I. lab like Amazon, Microsoft, Google or OpenAI. They absorb a little bit of each layer every year and any company whose whole moat was that layer simply disappears.

Those are the questions: which layer is yours, how sharp is your wedge, and who might commoditize you from above? They're good questions and most of the smart money is asking some version of them.

But it was built for horizontal software. It assumes a horizontal world. It assumes the giant who can take your layer sits somewhere above you, in the cloud. It assumes your buyer is directly consuming what you build. And it assumes the stack keeps its shape, that the moat sits up top and your data is the cheap part.

Construction breaks all of these assumptions. Once those assumptions go, the lens keeps working, but it starts pointing at the wrong risks and the wrong openings.

I run the A.I. Peer Groups for Builders, rooms where the leadership teams of dozens of construction firms work through exactly these issues every month. When we take a look through this lens and hold it up against what’s actually happening inside construction companies, the picture distorts.

It doesn’t distort in one place. But in several specific, repeatable ones, and each one is a spot where the horizontal playbook hands a founder or an investor the wrong read.

Below is the first of those broken assumptions. It’s the easiest one to see because it’s already in the headlines, but it sets the stage for what’s next.

Construction has its own hyperscalers

In construction, the company that commoditizes you from above isn’t Amazon or OpenAI. Construction has its own hyperscalers and they behave exactly like the cloud giants do. They acquire, they embed, and they box out.

It’s Procore, Autodesk, and Trimble, with Microsoft increasingly sitting underneath all of them.

They’ve been doing it for decades. In 2018, Autodesk spent over a billion dollars in about a month buying PlanGrid and BuildingConnected. Trimble spent more than that on e-Builder and Viewpoint. That is how those companies became the foundation that the industry builds on. They bought the field instead of out-building it.

The 2026 wave is that same playbook, just aimed at A.I.

The platforms are bringing your buyers a workbench

But here’s the part that’s genuinely new in 2026. And it’s why these acquisitions are the smaller half of the story.

The platform isn’t only shipping against you. They’re also arming your buyer to build against you.

In May, Procore announced a suite of A.I. agents on the Datagrid technology it had just acquired, with prebuilt agents for RFIs and daily logs. In the same push it shipped Agent Builder, which lets a contractor’s own people build their own agents inside the platform, no code required.

So look at where a construction A.I. founder is standing now. On the one side, a platform is shipping your workflow natively. On the other side, that same platform is handing your customer the tools to build a rough version of your product themselves.

There appears to be very little floor left to stand on, at least on paper.

Earlier in this series I wrote that the user became the competitor. A contractor’s own people, armed with A.I., could build the tool instead of buying it.

That’s still 100% true. What’s changed is that the platform has also joined them. The platform is shipping against you and arming your buyer in the same breath.

The question keeps narrowing

I’ve been revisiting Crossing The Chasm Twice for several articles now. Look at how the question a founder has to answer has narrowed.

Back in the original piece, it was whether your pain point was generalizable enough to cross the second chasm and reach a fragmented industry. Then A.I. put real tools in your buyer’s hands and it became whether your buyer could build it themselves.

Then the platforms turned aggressive. The test became whether your buyer couldn’t build what you’re selling and whether the platform wouldn’t ship it.

Now both of those gates are closing simultaneously. What’s left is what the platform won’t ship natively and what your buyer can’t build themselves—the addressable value is shrinking.

The opening that started as a “generalizable pain point” has narrowed to almost nothing.

So the honest question isn’t whether the opening is big anymore. It’s whether anything left is defensible. And here’s the part that should worry a founder more than the platforms…

Getting specific isn’t enough

For as long as anyone has funded technology startups, the answer to a competitive squeeze has been the same. Get specific. Pick a narrow enough slice and you’re safe, because you fit one job so well that a generalist can’t be bothered to follow you into it. That’s the wedge and it’s the move every founder in this position reaches for.

But this is changing. The platform already owns the system of record your slice lives in and it ships your feature natively. Your buyer has a Claude Cowork license and can rebuild a specific workflow in an afternoon.

The wedge was supposed to be a place a bigger player wouldn’t bother to go. In construction, both of the players who can kill you now have the ability to walk right in.

Specificity still gets you in the door, but it stopped keeping you in the room because the wedge has changed direction.

The wedge turned inward

The old wedge pointed outward. A narrow slice across the market. This industry, this workflow, this role. It was defensible for one reason: it was too small for a big player to bother chasing.

That version is dead because in construction the buyer and the platform can now chase any potential customer slice, however small.

The wedge that remains points the other way. Not across the market, but into a single customer. Not who you serve, but how far into their reality you’re going.

And, in construction, here's what that inward wedge is actually made of: it's the layer I told you I'd come back to. The data.

In construction the data layer isn’t table stakes and almost none of it is the tidy RAG plumbing the standard playbook assumes is commoditized. It’s getting a fragmented, physical, project-based company’s data to exist and mean something. It’s conditioning the field-based processes underneath it so the data is worth having. It’s earning the right to operate on that data once it does.

That’s the hardest, slowest, most valuable work in the whole business. One firm in my groups spent roughly eighteen months conditioning its data lake across six platforms before pointing a single agent at it. That’s not an outlier. That’s what the work costs.

And here’s why it holds when nothing else does. It isn’t a product you sell. It’s a capability you co-build with the customer, entangled in their own systems, their own mess, their own way of running a job.

A horizontal player can’t parachute into it because it only exists inside this one customer’s reality. And the platform can’t fully absorb it, because it was never a tool sitting on a shelf to buy.

You don't buy your way into an inward wedge. You build your way into it.

The outward wedge was a place to hide from a big player. The inward wedge is a thing you build with your customer that no big player can reach.

Same word, opposite direction. In construction it’s the only truly differentiated direction left.

Mapping exactly where you drive that wedge is what I’m turning to next and it’s likely the first piece in this series that I put behind the paywall.

It comes from the same place everything does: the better part of a year sitting with leadership teams across dozens of construction companies, watching what A.I. actually gets adopted, what A.I. gets abandoned, and what nobody can build no matter how badly they want it.

The chasm was never the only thing that could kill a construction startup. But this newer problem is subtler. The bridge you were trying to cross now belongs to the company you’re competing against and the only ground left is the ground you build with the customer.

The reasoning behind this is easy to follow. IT has owned many technology adoption …

Read more

Now he’s pushing for contractual clauses with startup ven…

Read more

Read more

Read more

The question earning contractors near-term value right now is different: When the tool worked and we walked away, what did we learn?

I’ve been watching this pattern accumulate across peer groups over the past six months and it…

Read more

None of these people are developers. None of them …

Read more

I’ve been facilitating A.I. peer groups for construction leadership teams and the firms making real progress aren’t swinging for the fences. They’re bunting, getting …

Read more

Despite their regional status and reputation for reliable work, a mid-sized construction company faced an undeniable truth: they were falling behind competitors who had embraced artificial intelligence.

The realization came gr…

Read more

Let’s face it: in our fragmented and complex industry, construction buyers often lack the sophistication needed to navigate new technologies.

Currently, A.I. technology is the biggest trend of all and it’s impossible to ignore its impact. Recent advancements in large language models are not hype; they’re real, and construction companies t…

Read more

If there’s any industry in need of digital process improvement, it’s construction. Even as more than 90 percent of field users have Internet-connected supercomputers in their pockets, a huge deficit in digital maturity remains in the industry. Not to men…

Read more

Placer Solutions has released its new research report series starting on the topic of Augmented Reality (AR) and Mixed Reality (MR) in Construction.

The series strives to be independent, with a shared mission from all collaborators to assist builders and tech providers in suc…

Read more

When I first ventured into the world of construction tech, I had recently come off four years working overseas on large construction projects for Bechtel. …

Read more

Inertia Systems might be one of the most successful construction tech companies you’ve never heard of. For 13 years, they’ve been reshaping the industry’s blueprints, pioneering better ways to access and view information in the field. Today, they’re primed to seize the opportunities that th…

Read more

Perhaps it’s not surprising that this Q&A steers into structural innovation for the construction industry. Rather than focusing solely on technology, Todd Mustard, Vice President at one of the country’s largest national associations for uni…

Read more

If there’s a theme to construction technology over the past several years, it’s the growing realization that technology alone won’t solve all of the industry’s challenges. In a lot of ways, looking inwards at the organizational level to individual construction companies is perhaps the bett…

Read more

Innovation in construction lacks a standard playbook. Each company approaches things differently, based on their specific sector and customer base. This interview with Brian Arnold offers a clear explanation of an innovation group from the viewpoint of a general contractor specializin…

Read more