I sat down with Will Meurer to trace a pattern that keeps surfacing across AEC product conversations: why does the industry keep adding sophisticated tools to manage symptoms instead of fixing what’s broken underneath? Meurer has an unusually broad vantage point on this — he’s seen it from inside Assemble (BIM tools acquired by Autodesk), from Document Crunch (AI contract review), and from the elevated perspective of consulting through Level10, which was eventually acquired by Document Crunch. What follows is a conversation that moves across those experiences to map out what’s actually going on in construction tech and what it would take to change it.
About Will Meurer
Will Meurer has worked across the construction tech space in multiple domains: BIM and design tools at Assemble, pre-construction and bidding at ConstructConnect, and AI contract review at Document Crunch. He co-founded Level10, a consulting firm that was eventually acquired by Document Crunch, giving him both the operational intensity of embedded product roles and the elevated perspective of consultancy.
“In construction, the product is done when you finish the project. In software, when you launch a feature, it’s just the beginning.” — Will Meurer
The construction industry has spent decades adding layers of complexity to its own processes, then building technology to manage the complexity it created. Each solution becomes tomorrow’s symptom. This cycle persists because three forces reinforce one another: a project mindset that treats software as a deliverable rather than an evolving product; a buyer-user gap where purchasing decisions are disconnected from the people who must actually adopt the tools; and a depth-breadth tension where venture capital pressure pushes companies to build thin slivers of many solutions rather than complete floors of focused value.
Meurer has observed this pattern from multiple vantage points. His consulting work at Level10 allowed him to step back from day-to-day operations and watch how companies across AEC approach product development. “The great thing about consulting is that it allows you to step out of the day-to-day miring of what’s going on in the operational side of business,” he explains. “It allows you to sit up a little bit and then get a better survey of the world of what’s going on in the industry.”
That perspective revealed a consistent tension: construction tech needs outside software expertise, yet the industry’s specificity makes domain knowledge essential. “I think it’s a great thing to have, maybe the best thing to have, an industry person as a founder or one of the founders for a product in AEC,” Meurer notes. “It’s like trying to start a finance startup and you don’t have a finance person, that would be a little bit nuts.”
The challenge is that industry expertise rarely comes paired with software expertise. “Unless you are a software company building software for software companies, you’re probably not going to have a bunch of people who are software knowledgeable and product thinking and UX thinking. You either luck into some of that or you’ve been paying attention for a long time, or you have to build that expertise up as you go.”
This gap between domain knowledge and product thinking runs through every challenge construction tech faces. The industry operates on project logic; software demands product thinking. Everything downstream follows from this mismatch.
The complexity inflation problem
Consider the documentation evolution of major construction projects. Jørn Utzon’s winning design for the Sydney Opera House, one of the most architecturally ambitious projects in history, comprised just twelve drawings when it won the international competition in 1957. The Australian contractors, Hornibrook, later developed an estimated 5,000 drawings for their specific work on the roof sails alone, showcasing the ingenuity required for implementation. Today, that order of magnitude represents what you’d expect for a standard commercial building project.
The contracts have followed a similar trajectory. What might have been a handful of pages for iconic structures now routinely exceeds a hundred pages for conventional projects. The construction industry has added layer upon layer of complexity through decades of accumulated processes, risk-transfer mechanisms, and defensive documentation.
This complexity didn’t emerge because buildings became fundamentally more complicated. The industry created its own crisis, and each layer of complexity spawned tools to manage it, which in turn enabled even more complexity.
Document Crunch exemplifies this pattern. The company built an AI tool that helps construction professionals work through increasingly complex contracts, identify key obligations, and surface potential risks buried in dense legal language. It’s extraordinarily useful and solves a genuine pain point. But the uncomfortable question persists: why are contracts so complex in the first place?
“To solve the symptom, not the underlying actual sickness,” Meurer observes when I bring up this contradiction.
The pattern is self-reinforcing. Tools that manage symptoms create new dependencies, which generate new complexity, which demands new tools. The cycle compounds because each layer of technology makes the underlying process harder to question; the sunk cost of the management infrastructure makes it harder to simplify the foundation.
Construction tech has become an expert at building sophisticated tools to manage problems the industry creates for itself. We’ve developed AI to parse hundred-page contracts rather than questioning why they need to be that long. We’ve built change management software rather than examining why changes proliferate uncontrollably. We’ve created coordination platforms because our processes generate thousands of drawings instead of hundreds.
This isn’t unique to any single company or tool; it’s a systemic pattern. The industry adds layers of technology on top of broken foundations, then builds more technology to manage the new problems those layers create. Each solution becomes tomorrow’s symptom.
Why the cycle perpetuates: project mindset meets software reality
The root cause lies in how construction conceptualises work. “In construction, the product is done when you finish the project,” Meurer explains. “In software, when you launch a feature, it’s just the beginning.”
This distinction shapes everything. When a general contractor finishes a building, they hand over the keys and move on. The structure stands or falls based on what was delivered. Success or failure is measurable, tangible, and immediate. This mindset permeates the industry: define the scope, execute the work, deliver the output, and move to the next project.
Meurer uses a vivid analogy to illustrate the gap: “In construction, the way I tell people is if you had to continue to do the maintenance for every building that you did as a company, your company would be huge.” But that ongoing maintenance is exactly what software demands. Every feature shipped requires monitoring, iteration, and refinement; the product is never handed over and forgotten.
Software operates on fundamentally different logic. Launching a feature marks the start of learning whether it delivers the intended outcome. The first version might solve a problem without solving it well enough. It might address the stated need while missing the underlying workflow challenge. It requires iteration, user feedback, and continuous refinement. You can’t declare victory and move on; you have to stay engaged with the outcome over time.
The challenge for product leaders is that “most people are thinking in output mode because it’s easy to make it tangible. It’s this thing that you did, not the benefit that you are able to provide over time, across all the features you do,” Meurer notes. This isn’t unique to construction; it’s true for anyone who’s not a product person. But construction’s project-based nature amplifies the problem.
At Assemble, Meurer encountered this tension directly. Customers would request specific features, such as “show us what moved” or “track XYZ position changes.” These were reasonable requests expressed in the language of outputs: specific functionality they believed would solve their problems.
“We had this need for people to see what was different, what changed from one version of the model to the next,” Meurer recalls. “They’d ask, ‘Can you just highlight what changed? What moved?’ Yes, that’s a feature we could build, but it was a very big technical challenge. But the underlying problem we had to understand was: what is your day like when a new version of the model comes in?”
When Meurer sat down in people’s offices and watched their actual workflows, a different story emerged. The real challenge wasn’t tracking XYZ position; it was risk management around changes they might miss between model versions. They needed to determine whether changes were intentional or errors, identify their impact on their work, and avoid costly downstream mistakes.
“One guy very early on said, ‘Here’s the process that I go through and how much time it takes me without Assemble. And then here’s the amount of time it takes me with Assemble,’” Meurer recalls. The difference was staggering: “One to two people for one to two weeks if a new model came in, or one person for like 30 minutes when the new model comes in with Assemble.”
The outcome was counterintuitive:
“The hardest part technically was going to be XYZ position changes. All the other types of changes could do more quickly and easier. We got these great benefits out to people, and they never even got XYZ for a long time. They still loved it because we were solving for that underlying problem.”
The lesson wasn’t about which features to build; it was about understanding that the stated request represents a hypothesis about a solution, not a clear articulation of the problem. When you operate in project mode, you take the request at face value and build what’s specified. When you operate in product mode, you dig deeper to understand what outcome the customer actually needs.
The project mindset creates a second-order problem that compounds the first. Meurer reinforced this at Document Crunch with the founders:
“If we do this feature, this major new thing, this major new space, we don’t know if it’s going to give us the outcome that we want yet or that our customers want yet fully. So we’re going to put something out there, but that doesn’t mean we’re done and we can move on to the next thing. We have to keep going, we have to iterate.”
“I think that’s kind of funky in the AEC industry,” Meurer observes. “Everybody’s mindset is project, and it’s done when it’s done, and that’s just not…the feature’s done, but the outcome isn’t done.”
This gap explains why so many construction tech products feel incomplete or fail to gain traction. They’re built with project logic: deliver the specified features, declare success, move forward. But software value accrues through iteration and refinement based on how users actually engage with the tool. Without that continued investment in achieving outcomes, features become abandoned half-solutions.
When buyers and users are different people
The cycle persists partly because of who controls purchasing decisions and what they optimise for. In most software markets, users discover tools, experience value, and become advocates for adoption. An individual contributor finds ChatGPT or Claude, uses it successfully, and shares it with colleagues. Adoption spreads organically based on demonstrated utility.
Construction doesn’t work that way.
“You’re not selling to the user very often,” Meurer explains. “In construction, because the companies are generally bigger and they’re dealing with a lot more revenue at stake, and there’s a lot of risk—yes, their margins aren’t big, but their revenues are big—they are more protective. That means you’re selling to operations and tech people, or executives.”
These buyers rightly focus on organisational requirements that matter: SOC2 compliance, single sign-on integration, reporting dashboards. No enterprise tool succeeds without meeting these standards, and any product leader who dismisses them will lose deals. The challenge is that these capabilities are a necessary, not a sufficient, condition for success. The ultimate return on that investment depends on whether end users find the product valuable enough to weave into their daily workflows.
“They’re going to be looking for things like: Is this a product that has SOC2 capability? Does it have single sign-on? Is it going to give me the reporting dashboard that I need?” Meurer describes. “But all of those things are only valuable if the underlying product has benefits and the people who need to use it to get those benefits are actually using it.”
Product-led growth offers one path through this impasse. When construction tech companies offer self-service trials or freemium entry points rather than routing every prospect through sales demonstrations, the product must prove its value to end users before procurement is involved. Buyers can delegate initial vetting to team members who use the tool daily, turning passive recipients of top-down mandates into informed advocates. The approach doesn’t eliminate the enterprise sales process, but it grounds purchasing decisions in demonstrated user value rather than feature comparisons on a spreadsheet.
Without that shift, the disconnect persists: companies optimise for what buyers evaluate rather than what users need. Products accumulate executive-friendly features while fundamental usability problems go unaddressed. Success depends on user adoption, but product decisions prioritise buyer preferences.
Meurer points to Procore’s “Big Orange Button” as a counterexample: a prominent button on every page showing users the next step. “Even if they’ve never used the product before, I guarantee you most of them are going to be able to do that work and do that over and over.” What makes it work isn’t the button itself — it’s that the product earns adoption from the person doing the work, not from the executive who signed the contract. When users can navigate a tool without training, they reach value before the institutional inertia sets in. The simplicity isn’t optional; it’s the mechanism by which adoption survives the buyer-user gap.
The risk-averse nature of construction amplifies the challenge. Projects span two to three years with razor-thin margins; companies can’t afford to experiment with unproven software on high-stakes work.
“Their margins are so razor thin, they don’t want to take a chance on a two-year project to see if it’s going to be good software,” Meurer explains. “If they do after a few months find that it’s pretty good, they’ll want to do it on a few others. And so then it’s two or three other projects. And then three years later, you might actually start to have a product that can be moved out to the entire company.”
This creates a temporal mismatch: software companies need rapid iteration and feedback loops; construction projects unfold over years with limited opportunity to adjust course.
The third economic force is venture capital pressure. VCs want maximum addressable market; founders want to focus. This creates the feature treadmill: instead of completely solving one problem for a specific customer segment, companies build a thin slice of many solutions to demonstrate broad market applicability.
“A lot of people will go, ‘I want to be a project management solution for a general contractor; I want to do everything for them.’ Okay, great. So I’m going to build a tiny sliver of all these tools.”
None of those slivers is good enough to stand alone. And as Meurer observes, “the features aren’t as important as what the story that the product tells. And the story for the product is not going to be easy to tell to all of those different groups.” A complete floor tells a coherent story; a sliver of many floors tells no story at all.
“You can’t build a skyscraper from left to right. You have to build it from the bottom to the top.”
The analogy clarifies what the feature treadmill obscures: construction companies won’t adopt partial solutions, but they will embrace a tool that genuinely solves a specific, painful problem. This “first floor of value” framework represents the crucial principle: what is the complete problem you can solve right now? Once you’ve built that foundation, you can add floors. But trying to build a little bit of everything yields a structure nobody can use.
The same economic logic that drives the feature treadmill also determines what gets measured — and what systematically gets missed. Construction tech marketing follows a predictable pattern: save X hours, reduce costs by Y per cent, improve efficiency. These metrics speak to the quarterly profit requirements that dominate purchasing decisions. They’re measurable, concrete, and defensible to the executives controlling the budget.
But the most valuable outcomes often resist such quantification. Meurer points to the challenge of selling risk reduction:
“With risk, one of the challenges at Document Crunch is we could say all day, ‘Hey, if you use our product, it’ll lower your risk down the road.’ But that means you have to do this now for something that you don’t know if that’s going to happen or not, but even if it does, it requires other people who weren’t even the people who use the product to do things the right way.”
Attribution becomes difficult when success looks like problems that never materialised. How do you measure the value of the mistake that didn’t happen?
This challenge extends to quality-of-life improvements. The industry knows people are burning out. Project deadlines compress, coordination complexity increases, and the consequences of errors escalate. When tools genuinely reduce stress, giving people more time to think strategically rather than react tactically, that’s valuable. But it’s not valuable in the language of quarterly profits and measurable ROI.
“These intangible benefits are harder to sell,” Meurer acknowledges. “And I don’t know what the solution is for that yet. But I think that’s where my mind keeps going. We’ve got to somehow find a way. In a world of capitalism that goes every quarter you have to make profits, and every quarter you need to see the change that will make the next profit, we’re getting so short-sighted that the long term is not really in our heads.”
The short-term thinking that dominates creates a contradiction: everyone recognises that construction processes need fundamental rethinking, but the economic structure rewards symptom-solving over foundation-fixing. Companies can justify spending on tools that demonstrably save time on existing workflows. They struggle to justify spending on tools that might enable entirely different workflows with harder-to-measure benefits.
Most AEC companies don’t systematically create space for strategic thinking; most product teams don’t have the breathing room to question fundamental assumptions. The urgency of the current project crowds out the importance of process improvement.
The generational shift creates an opening
Despite these structural obstacles, Meurer sees genuine reason for optimism. The incoming generation of construction professionals brings different expectations and less attachment to inherited processes. They’re more comfortable with digital tools, more willing to question established workflows, and less likely to accept “that’s how we’ve always done it” as justification. As Meurer puts it, this new cohort will look at legacy processes and recognise, “We don’t have to do it that way because we have all this new technology, even technologies that haven’t been fully taken advantage of.”
“An opportunity that we have right now is that, at least in the US, the workers in construction and design are aging. That population is getting older, and they need people to help usher up the new group.”
AI could amplify this generational momentum in ways the industry hasn’t fully grasped. The common narrative focuses on AI replacing workers or automating existing tasks. Meurer sees a more compelling possibility: AI handling enough specificity to enable products to serve broader audiences without becoming generic.
“I do think that AI has potential for being just flexible enough that you can build some of the bigger-level scaffolding that everybody needs, and then not have to be so specific,” he explains. “Let the AI take care of some of the specificity or the hand-holding for a particular industry or focus.”
This could directly address the fragmentation challenge that has constrained the industry for decades. A general contractor working on hospitals in California needs different features than one doing retail in Texas. Companies currently face a binary choice: highly specific tools for narrow markets or generic tools that require extensive configuration. AI enables a middle path; adaptable interfaces that adjust to context without requiring custom development for each use case.
The critical choice lies in how we deploy this capability. AI that accelerates existing processes offers immediate value; AI that simplifies the foundations creates lasting change. Contract review tools that help teams manage complexity serve a genuine need today, but the larger opportunity emerges when AI reduces that complexity at the source: standardising language, surfacing unnecessary clauses, and gradually simplifying what future contracts need to contain.
“It seems that we don’t want to change how we work,” Meurer observes.
Yet the convergence of generational turnover, AI capability, and mounting pressure on margins creates the strongest opening the industry has had to challenge that inertia. The capacity to rethink foundations exists; what’s needed is the willingness to direct new tools toward simplification rather than acceleration alone.
The diagnostic process: finding the first floor of value
When Meurer joins a new client, the same gaps tend to surface.
“I want to talk to some customers or at least watch some videos. I want to know: how are customers talking about the product? What do they describe the product as? What are their problems, their challenges that they need support for?”
Then comes the interrogation: what he calls getting to the “why.”
“What is the real problem that you’re solving for? There’s no shortage of problems in the construction industry. You need to figure out really where are they, where’s the customer, where’s this software company right now? And what is that first level of value?”
The critical question becomes identifying the “first floor of value”, the complete problem you can solve right now, the outcome you can fully deliver before expanding to adjacent problems.
“A lot of people really want to build features. And that feature up here in floor 18 is not usable yet or it’s not really most valuable because you don’t have any of the other supporting stuff to use it with.”
The discipline required is “making sure you’re fully building out a floor of value before you just start going to this next thing.”
This means saying no, explicitly defining what you’re not doing.
“You have to say you’re not doing something. You have to say that you’re not doing something right now, and you have to be confident in that.”
Then it becomes about prioritisation: identifying the best bets for next development priorities.
“What bet should you be making next? And what bet is the best bet to make that might have the lowest risk or is the best thing to do first because it opens all this other stuff up for us?”
One practical tool Meurer uses to bridge the gap between project and product thinking is to build outcome timelines into the roadmap. “You say where a launch is going to be. And then you also say, here’s when we’ll see the outcome that we’re looking at. Here’s the iteration and outcome time period.” The distinction matters: just because a feature launches in April doesn’t mean it delivers its intended outcome in April. Sales cycles, user adoption, and iteration all require time. Making that timeline explicit prevents the project mindset from declaring victory at launch and moving on.
This approach conflicts with VC pressure to quickly maximise the addressable market. It requires patient capital and conviction that focused solutions beat generic platforms. But it’s also the only path to products that users actually adopt and continue using, rather than tools that win enterprise deals but gather dust in daily work.
The closed loop
The three forces identified throughout this analysis do not operate independently; they form a self-reinforcing system.
The project mindset treats software as a deliverable: build the feature, ship it, move on. This produces tools that feel incomplete because iteration never follows the initial release. Incomplete tools struggle to gain user adoption, which validates the buyer’s instinct to evaluate on feature checklists rather than workflow outcomes. The buyer-user gap then reinforces the incentive to build broadly rather than deeply; companies optimise for what procurement evaluates rather than what end users need. VC pressure amplifies this breadth-over-depth tendency, pushing companies onto the feature treadmill: thin slivers of many solutions rather than complete floors of focused value. And the resulting products, spread too thin to solve any single problem completely, reinforce the project mindset’s assumption that software is just another deliverable to be evaluated and replaced.
Each element sustains the others. The cycle explains why so many construction tech products win enterprise deals but gather dust in daily work, why the industry keeps adding layers of technology on top of broken foundations, and why the Sydney Opera House comparison resonates: accumulated complexity has a cost that compounds, and we keep building tools to manage it rather than questioning why it exists.
“You really have to start in some place and focus,” Meurer says. “And start ideally in the biggest opportunity space. Then you can prove that enough to make it great and then widen as you go.”
The Assemble story illustrates what becomes possible when this loop is broken. The team resisted building the hardest technical feature (XYZ position tracking) and instead solved the underlying problem: risk management around model version changes. Users who never got the feature they requested still loved the product because it addressed their actual need. The hardest technical challenge is often not the most valuable thing to build.
The construction industry’s generational transition and AI’s flexibility create a genuine opening to challenge this system. But the opening is only as valuable as the willingness to direct new tools toward simplifying foundations rather than accelerating existing processes. The question facing every construction tech company is the same: what is the first floor of value you can build completely, and are you willing to stay on that floor until it bears weight?