Audio article narrated by OpenAI
Luigi La Corte’s path runs from the bottom of the trade to the top of the capital stack and back down into the product. He spent his teenage years cleaning and painting baseboards on his father’s jobs, trained as a civil engineer, and then spent six years at an infrastructure investor evaluating bids from general contractors. From the practitioner’s floor, he saw what was broken; from the investor’s seat, he saw the same failures recur on a billion-dollar scale. The gap that separates those two vantage points seeing the problem versus being positioned to act on it is exactly the gap this publication keeps returning to. What follows is a conversation about what changes when someone who understood construction first, and technology second, finally gets to build.
About Luigi La Corte
Luigi is the co-founder and CEO of Provision (YC S22), a Toronto-based AI platform for pre-construction. He is a civil engineer by training, worked at Arup on large infrastructure projects in Toronto, and spent six years as a director at the Plenary Group, investing in public-private partnerships, before quitting in 2021 to build. The son of an immigrant general contractor, Luigi started working on his father’s sites at fourteen; Provision today sells Scope Agent, Risk Review, and Chat Agent to some of the most document-intensive general contractors in the world.
—
“The whole point of building a venture-backed startup is to get to scale. To grow, I need to build the product once. I need to sell it a thousand times.” Luigi La Corte
—
There is a comfortable position available to any founder who emerges from a hard industry: become the indispensable service layer. Sell outcomes, charge for expertise, wrap the technology in a team of people who do the work. It is a defensible business, and in construction it is having a moment. Luigi has chosen the harder road, and his reasons map almost exactly onto the structural realities of the market he serves.
Why the science is finished and the tooling isn’t
Luigi’s founding insight is not that construction is broken. It is more precise than that, and he reached it from the inside: he trained as an engineer, concluded the discipline had nothing left to solve, so he changed.
“Civil engineering is solved. Basically solved. There’s really no innovation there anymore.”
He is careful to define what he means. The science of supporting or transferring load, of accomplishing with one dollar what someone else does with two, reached its frontier long ago; the remaining innovations are minuscule and do not push that frontier. This is why engineering hours plateau and why he found the discipline to be static, even on extraordinary projects. The opening, he concluded, was not in the science but in everything around it: the tools, the processes, the documents that govern how the science gets bought and sold.
That distinction matters because it tells you where Luigi looked for the problem. He did not look at how a beam is sized. He looked at how a contractor decides whether to bid, what to price, and where the risk hides. From his years in the sophisticated buyer’s seat at Plenary, he watched the largest general contractors in Canada misjudge what was in their own documents, then sue or get sued over the gap. The failure was not individual; it repeated across firms, which is the signature of a structural problem rather than a human one.
Products, not services, and the case for building once
Provision builds products and refuses services. The only customisation he permits is the last mile: a logo or the formatting of a scope of work. Ask Provision to rebuild your proprietary historic cost-estimate method and the answer is no.
“We don’t build services. We only build products. I still think that products are the most scalable. And having a product that is very unique and very differentiated, in my opinion, would beat a service any day. For construction.”
The reasoning is economic, not ideological. Four years and several thousand contractor conversations have taught him what every general contractor has in common, and the commonality is where he builds. “I know enough about how people do their scopes to see the commonalities. I build the product for those commonalities. And then the roadmap reflects the last 20% that allows me to really scale.” Build for the most abundant opportunity; add the enterprise extras, single sign-on, SOC 2 Type 2, on top to sell more.
He reaches for Palantir as the model: a company that looks like a service business but is really a single product, with the implementation done as last-mile services around an unchanging core. This is the products-versus-services divide that runs through construction tech right now, and it is worth naming the counter-position honestly, because serious people hold it, some of them close to Luigi. Y Combinator, which backed Provision, has been making the public case for AI-native services: companies that sell outcomes rather than software, where humans are the customer interface and the product scales them non-linearly across trillion-dollar markets like tax, audit, and insurance. David Niewiadomski at Zero RFI argues the same from inside construction: that the surviving play is a technology-enabled services company selling outcomes, not software. That Luigi’s own accelerator advocates the road he refused is exactly what makes his choice worth examining. Both can be right for different businesses; what makes Luigi’s coherent is that it follows from his read of the market. If the problem is common across thousands of contractors, the leverage is in selling the same product a thousand times, not in selling your time once. There is a deeper principle underneath the choice. Entrepreneurial leverage comes from turning a unique skill into a reusable component others can draw on, repeatedly, without you in the room. Luigi’s reusable component is not a service; it is a processing engine that reads construction documents, and the entire product strategy is built to maximise its reuse.
The right problem moves a slow industry fast
The standard objection to a YC-style iterate-fast playbook in construction is that contractors take six to eighteen months to try anything. Luigi disagrees harder than almost any founder I have spoken to, and his rebuttal reframes the whole adoption question.
“If I say, hey, I can make your Gmail two times better, they’re probably going to take 19, 20 months to even try it. But if I say, your estimating team is preventing you from making more money, you don’t have enough estimators and you’re making mistakes, I can solve all three of those problems for $50,000, they move pretty quickly.”
Demo in two weeks, contract in four to six. The speed is not a property of the customer; it is a property of the problem. Everything sits on a spectrum of urgency, and the founder’s job is to find the problem near the top. This is why Provision sells to the back office rather than to operations. In operations, the project is already underway, the budget is fixed, and there is no room. In the back office, pre-construction estimating, the work is about winning more and making more money, which is precisely where a contractor will move.
There is a quieter insight folded into this. Luigi credits Y Combinator for the company’s survival, despite a fashionable construction-worldview that YC is irrelevant to the industry. What YC taught was simple and hard: do not spend too much, talk to your customer constantly, build something they want. The difficulty is in the discipline, because money invites spending and attention invites distraction. The standard objection, that construction allows zero margin for error and you often get one chance with a customer, is real, but it does not contradict fast iteration. The two coexist precisely when you have aimed at a problem that matters to the customer’s urgency, because high stakes are what make the customer willing to move fast in the first place.
Pre-construction as the highest-leverage cut
Why pre-construction specifically? Partly because Luigi understands the back office in a way he does not understand operations, an honest admission of where his four years of study actually point. But the structural case is in the numbers. Contractors lose the majority of the projects they bid on; when they win, they still make mistakes; the work takes weeks; and much of it is deterministic because the content already exists in a PDF.
“If it’s a hard bid, it’s so inefficient. They have to count the things and then they get a new version, they got to count it again and see what changed. It’s ripe for disruption with technology.”
This is the shift-left logic of software quality applied to construction: a scope gap is far cheaper to catch at bid stage than after the contract is signed and the money is committed. The intervention point is chosen for leverage, not convenience.
Brand and trust as the moat nobody talks about
I never brought up the topic of branding in previous interviews, but I sensed that Luigi had something to say about it. He seemed particularly engaged, discussing how he learned the value of a strong brand through experience. When his company competed on contract review, it lost to Document Crunch; in his reading, partly because it did no marketing and its brand was weaker.
“The brand is many things. It’s the perception of your company before they meet you. And I think it’s the sum total of your impact on the market.”
He builds that perception by giving away knowledge: templates, ebooks, content, hosted conversations, and a podcast. “I genuinely want the industry to get better. And I think that genuineness helps.” The sequence matters: giving is what starts the receiving, because you invest in the market’s competence before you ask it to invest in you, and the trust compounds from there. Trust, separately, is built over years and protected absolutely: four years in business, no security incident, every NDA honoured. The two compound into a reputation that arrives before the salesperson does. On a demo the day we spoke, a prospect mentioned having used the product at a former company and loving it. Luigi is precise about the relationship between brand and marketing, because the two are routinely confused. Marketing is the mouthpiece; the brand is the thing being voiced. “You can’t turn on a brand by spending money on marketing.” Apple’s brand is its product and the legend of its founders, not its advertisements. The measurable return shows up as warm inbound: “Have you heard of us? Yes, you hosted a poker game, that was really cool.” In a relationship-driven industry where buyers fear pilots that die and vendors that vanish, brand is not soft. It is the asset that enables a small company to be trusted with the documents that determine whether a contractor wins or loses.
Augmentation, mentorship, and the indemnity that would change everything
I pushed on a tension I keep returning to. Construction tends to accumulate solutions rather than simplify them; if every new tool just augments the existing way of working, are we adding another layer when we should be rethinking how the work is done? Luigi would be open to complete automation. His customers do not want this, and his explanation is the most interesting argument for human-in-the-loop I have heard from a founder.
Reading the drawings does two things that matter beyond the output. It teaches the estimator the job, which leads to better pricing and greater leverage with subcontractors, and it lets the next generation learn the craft. “If the power went out, could they read drawings?”
“I’m all about automating where we need to, but they don’t necessarily want full automation. They want people to be accountable. But they also want to make sure that people learn how to do these things.”
The material gain is already large. On one scope on a challenging $200 million construction-management job that would take six weeks, the product does in three days; an 80 per cent reduction. The remaining 20 percent is where accountability and knowledge transfer live, and Luigi treats that residue as a feature rather than an unfinished job. This echoes Sarah Buchner’s warning that 40 percent of the construction workforce goes out the window in the next five years, which makes the mentorship the tool encourages an asset rather than a sentiment. Francesco Iorio makes the parallel case for augmentation over replacement: the point of the technology is to let people focus on decisions rather than drafting, not to remove them. Then Luigi names the precise condition that would tip the balance toward full automation, and it has nothing to do with model accuracy.
“If somebody comes up with an insurance product that completely indemnifies or makes whole a user for relying on wrong information, I think you’ll see a lot of automation and less augmentation.”
Today, these are probabilistic products that can be wrong, and the companies building them are not prepared to indemnify users. Wrap the output in a policy that absorbs the liability, and contract review could run like an antivirus scan in the background, always on, surfacing only the flags. What he is describing is legalising the result of an agent: the moment financial accountability shifts off the human, the human no longer needs to be in the loop. Greg Lawton has put it plainly: until we grant legal accountability to AI, some human remains at the end of the loop because people still want someone to sue. The indemnity product is the mechanism that would finally remove that human, and until it exists, augmentation is not a limitation of the technology but a requirement of the market.
Build versus buy, and the opportunity cost contractors miss
The threat to a company like Provision is that a large general contractor decides to build the same thing in-house. Luigi’s answer is grounded in opportunity cost rather than capability.
“General contractors are brilliant at site logistics, bringing together subs, figuring out constructability. They are not brilliant at building software. And good software is very hard to build.”
His own behaviour models the principle. He recently bought time-off-tracking software that lives in Slack for $200 a year; he could have built it, but he would have spent a quarter of that in tokens and four hours fixing it when it broke. The energy you are brilliant with should not be spent on the thing you are not. For a contractor, building Scope Agent themselves might save $50,000, but the opportunity cost is three more jobs they could have bid in the time. Even Anthropic uses Salesforce, a database with workflows, because building its own CRM would divert engineers from producing far more valuable software. The observation runs in the other direction too. Non-software companies that try to become full software companies rarely assemble the core development team the work actually demands; the best builders go where software is the main event, not a side project. The competitive question is therefore not whether a GC can build it, but whether building it is the best possible use of the capital and attention they have.
The engine underneath the platform
Provision’s three products do not look connected. The connection is the strategy. “Every product we release makes the other product better. And it uses the same processing.” The contracts, specs, and drawings are processed once and used three times today, soon four when RFI Agent ships.
The reinforcement is concrete. Risk Review flags contract terms that deviate from a customer’s ideal position; RFI Agent finds conflicts between specs and drawings and raises questions to the owner; findings in Risk Review populate the RFIs; the RFIs feed Scope Agent, because you cannot scope a project with unresolved conflicts; and Scope Agent feeds back into Risk Review, because scope caps are a common way to take on risk. “They all add value to each other and they all interface. You don’t want point solutions. We are building a platform; a one-stop shop for pre-construction software.” Winning one step of the customer journey earns the right to integrate with the others, and the shared processing engine makes each additional step cheap to add.
The technical core of all of this is reading construction drawings, and Luigi is candid that it is genuinely hard. The documents contain errors, a reference to a detail that does not exist, that a model must account for. They compress three-dimensional logic into a 2D file: a plan tells you what to build, but to know how, you follow a link to a detail, and when that link is broken, a human makes a judgement call. “Deterministic machines have had a hard time. But now we have probabilistic machines.” The documents are also hard to read on their own terms; a legend tells you how to read the plan but lists items that may not be in your scope, so naive logic gets you wrong answers. You need conditional reasoning across tables, plans, details, elevations, legends, drawing blocks, notes, and embedded specs, tracing the business logic each customer employs.
“If you shove it into Claude, it gets like 68% of the way there. But you need it to be 98%. And that last 30% you have to build in a way that’s cheap and fast, and that’s hard to do off the shelf.”
LLMs read text, not images, so finding the elements you have to actually see requires custom work that is cheap and fast. A typo in a chat is harmless, but a mistake in an engineering document can cost millions in rework, and off-the-shelf models do not clear that bar on their own.
Benchmarks as the discipline that makes the rest possible
What separates their claim of accuracy from the marketing version of it is a refusal to ship anything unmeasured.
“We don’t build anything, we don’t build a single thing, without a benchmark. Nothing that we’ve released does not have a benchmark.”
Building a benchmark means knowing the definitive scope, extraction, and classification for a given project, and the only people who truly know that are estimators. So they hired five of them, had them estimate projects for roughly eight months, and generated hundreds of thousands of line items of benchmark data. Every program update runs against it: did it find the elements in scope, assign the right subcontractor, combine elements correctly? The build itself is custom plus off-the-shelf: OCR is off-the-shelf within a specific process; drawing segmentation is proprietary and genuinely better than what is available; the scope-finding model is off-the-shelf, but the prompt-chaining around it is custom. “The only thing that really matters is whether it works well. Eventually, when your business is mature, what matters then is your margin.” The benchmark is what lets him hold both truths at once, and it is also what makes the cost of AI a solved problem rather than a looming one.
Because he can measure performance, he can choose the cheapest model that clears the bar. If extraction runs at 93 percent on a cheap model, he can swap in an expensive one and see whether accuracy improves at all; usually it does not, because extraction is a preprocessing problem rather than an intelligence problem. Instead of feeding a whole PDF to a smart model and asking for the conflicts, the product first identifies what constitutes a conflict, then only needs a cheap model to make the call. What you do not need for deterministic calculations is probabilities. The benchmark turns that principle into a margin strategy.
When chat is the harder interface
I suggested that chat interfaces might change how we interact with solutions by lowering the learning curve. Luigi disagreed, and the disagreement is instructive.
“Even chat needs to be learned. There are people who are prompt engineers, they prompt better than you. I think chat is harder to learn than workflows.”
Scope Agent has a chat component, but most of its workflow is deterministic: click here to go to the next step, precisely because deterministic steps are easier to learn than an open prompt. The deeper principle he draws from a well-designed software investment of one of his backers is one worth keeping:
“Really good software should kind of teach you how to use it without going through an onboarding. If you’re doing onboarding, you’ve kind of already failed.”
For construction, the question then splits into two because there are now two kinds of users. The estimator is a visual creature who needs layout, sequence, and a short path to the first success. The agent reading the drawings is a different user class with different bottlenecks; it does not want a polished screen but the right semantic structure, the schema that is, in effect, its interface. Designing for both at once is the harder version of Luigi’s point.
Good design gets customers to the aha moment quickly, which leads to case studies, recommendations, and sales. The chat-versus-workflow question, then, is not about which is more modern; it is about which lowers the cost of the first success.
The interface where seeing finally meets acting
Run the threads together and they close into a single mechanism. The science of construction is finished, so the leverage moved to the documents; the documents are common across thousands of contractors, so the leverage is in a product rather than a service; a product earns trust only if it is benchmarked and a brand that arrives before the salesperson; and the same processing engine that reads the drawings is what lets one product subsidise the next. Each choice makes the others possible, and each follows from understanding construction before understanding technology.
What makes Luigi’s story a signal rather than an anecdote is where his constraint actually sits. The technology can already do far more than his customers permit; the limit on automation is not the model’s accuracy but the lack of a financial instrument to shift accountability away from the human. The same force, capital, is what he expects to compress the old wedge-to-platform timeline, arriving to aggregate the fragmented industry on the promise of AI rather than on AI itself. In both cases, the binding constraint is commercial and legal, not technical. The person who understood construction first saw this years before he could act on it; the rest of the industry is now discovering that the hard part was never the engineering, and that the gap between seeing what is broken and being allowed to fix it is closed not by better software but by someone willing to absorb the risk of being wrong.