AI Is Re-Rating Software Moats: How Buyers Should Diligence Defensibility
As the cost of building software collapses, code is no longer proof of advantage. The sharper question for buyers is what here is genuinely hard to rebuild — and the fastest way to answer it is to try.

For most of the last decade, a software company's code was treated as self-evident proof of its advantage. If a product worked, was widely used, and was hard to displace, the assumption followed that it must also be hard to build. Buyers paid for that assumption. It was priced into multiples, written into investment theses, and rarely tested directly.
Generative AI has broken the link between those two ideas. The cost and time required to recreate a working piece of software have fallen sharply, and continue to fall. Public markets have already begun to reprice the consequence, cutting meaningful value from leading enterprise software groups on the view that AI lowers barriers to entry and compresses the premium once attached to proprietary technology. In private markets the same uncertainty has translated into hesitation: deal activity in software has slowed as buyers struggle to judge which businesses will endure and which are about to be commoditised.
This matters most acutely in the mid-market and private equity segment, where software has sat at the centre of a long buyout boom and where the “defensible technology” story has underwritten a great many bids. The question facing buyers is no longer whether a target's product works. It is whether the part of the business they are paying a premium for is actually the hard part — and whether it will still be hard in three to five years.
The question has changed
Traditional due diligence answers “what does this software do, and how well does it do it?” That question is necessary but no longer sufficient. The more decisive question is “what here is genuinely difficult to reproduce, and why?”
Those are not the same enquiry. A product can be polished, sticky, and commercially successful while resting on capabilities that a competent team, equipped with modern AI tooling, could now stand up quickly. Conversely, an unremarkable-looking product can sit on advantages — proprietary data, regulatory permissions, entrenched distribution — that no amount of cheap engineering can replicate. Reading a data room and demoing the product will not, on their own, tell the two apart. Increasingly, the most reliable way to find out how hard something is to build is to attempt to build it.
Rebuilding to understand
The technique gaining ground among the most advanced advisers is to use AI to rapidly rebuild the specific capabilities a target claims are defensible — a working MVP of the core engine, not a sketch of it. Rather than reasoning about reproducibility in the abstract, a team builds it directly, under a tight time-box, and observes how far it gets.
The value of this is less the prototype than the act of building it. It is the difference between seeing a business in two dimensions and seeing it in three. The exercise surfaces hard, comparable evidence: a build-effort log showing that the core analytics view a seller described as years of proprietary engineering was approximated in days, or, equally usefully, that an apparently simple workflow could not be reproduced at all without access to data or relationships the target controls. Both outcomes change the conversation. Both are difficult to argue with.
It is worth being precise about what a replica does and does not prove. A working rebuild of an interface or an algorithm demonstrates that the surface is cheap to reproduce. It does not, by itself, demonstrate that the business is undefended — the moat may simply live elsewhere. The discipline of the method lies in using the prototype to separate the surface from the substance, then directing diligence at whatever the prototype could not reproduce.
Where the moat actually lives
When code stops being scarce, advantage migrates to whatever remains scarce. A rigorous defensibility assessment systematically tests where, if anywhere, a target's edge genuinely resides:
- Proprietary data. Unique, accumulated, or hard-to-collect datasets that a competitor cannot simply prompt into existence — and which improve the product in ways a fresh build cannot match.
- Switching costs and workflow entrenchment. Deep integration into a customer's operations, data, and processes, where the cost of leaving is high regardless of how cheaply the software itself could be recreated.
- Distribution and embedded relationships. Access to customers, channels, and trust that took years to build and that new entrants cannot short-cut with better engineering.
- Regulatory position and certifications. Approvals, accreditations, and compliance postures that function as barriers in their own right.
- Network effects and ecosystem. Value that grows with participation and is therefore self-reinforcing rather than reproducible in isolation.
This is where AI-enabled diligence connects to the commercial, operational, and vendor diligence buyers already commission. The replica is a probe; the answer it returns tells the wider diligence team where to dig. If the technology is cheap to copy but the data and distribution are not, the thesis is intact and the negotiation shifts. If neither the code nor anything around it is hard to reproduce, that is a finding worth a great deal more than a clean legal review.
The five-year question
Defensibility is not only a present-tense judgement. A large part of the value of building with AI in diligence is forward-looking: mapping how a target's product, and the category it sits in, are likely to be reshaped as the technology advances. Where does this business sit in the value chain once AI commoditises the layers around it? Which of its capabilities does AI erode, and which does it make more valuable? What would a credible competitor — or the target itself — build next?
Uncertainty is an uncomfortable word in private equity, and software is currently full of it: sellers' expectations remain high while buyers' conviction has thinned. A structured view of how a product evolves under AI does not remove that uncertainty, but it converts it into something a buyer can price and act on, rather than something that simply deters them from acting at all.
What it means for the bid
The purpose of the exercise is a decision, not a demo. Translated into the transaction, a defensibility assessment sharpens three things: the multiple that the “proprietary technology” narrative can actually justify, the conditions under which a buyer should walk away, and the post-deal agenda for protecting or rebuilding advantage under new ownership. In practice the most valuable outcome is sometimes a disciplined decision not to bid — avoided value destruction is as real as value created, and far cheaper to secure before signing than after. This is the same constructive scepticism that distinguishes the best acquirers in mid-market due diligence generally; AI simply gives it sharper instruments.
Beyond the deal: corporates and software spend
The same logic applies well outside M&A. Corporates carry large and growing software estates, and the questions a buyer asks of an acquisition target are the questions a CIO or CFO should be asking of their own renewals and roadmaps:
- Software contract and vendor reviews. Before renewing a material licence, is the incumbent's product genuinely hard to replace, or is the organisation paying a legacy premium for something now cheap to substitute or rebuild? A replica-based test makes that negotiable rather than theoretical.
- Build-versus-buy decisions. Where the cost of building has fallen, the historic default to “buy” deserves re-examination for specific, well-bounded capabilities — with a working prototype as evidence rather than a business case built on assumption.
- Portfolio and roadmap assurance. For PE-backed businesses, the same assessment run across a portfolio company's own stack clarifies where engineering investment defends real advantage and where it is sustaining a position AI is about to erode.
In each case the deliverable is the same: a clear-eyed view of what is genuinely scarce, what is not, and what that should change about spending, pricing, and strategy.
How Covelent approaches it
Covelent combines transaction and commercial judgement with the ability to build. We do not only advise on where AI changes economics — we develop AI software ourselves, which is what allows us to recreate the specific capabilities a target or vendor claims are defensible and report back on what we found, honestly and quickly. Our AI and due diligence work are designed to operate together: the prototype tells the diligence team where the real questions are, and the diligence answers them.
We are deliberate about the limits of the method. Replicas are functional, black-box builds derived only from what is observable; they are not, and must never be, copies of a target's source code, and the work is scoped to respect confidentiality, intellectual property, and data-room terms. We are equally careful not to over-read a prototype: rebuilding a surface is not the same as proving a business is undefended, and we say so. The output is a judgement a buyer or a board can rely on — about where advantage genuinely lives, how durable it is, and what that means for the price they should pay or the renewal they should sign.
As AI continues to lower the cost of building software, the gap will widen between businesses whose advantage was always the code and those whose advantage was something harder to see. Telling them apart, quickly and credibly, is becoming one of the more valuable things diligence can do. If you are evaluating a software acquisition, reviewing a major vendor relationship, or pressure-testing a portfolio company's technology, we would welcome the conversation.