Building defensibility during a private equity hold depends less on finding the asset a competitor can't copy and more on deciding what to build on top of it, and that second step is where most value creation plans stall. That was the clearest lesson from AI Pathfinder's Private Equity AI Strategy Day in London, where Ed and I ran a workshop called Building Defensibility During the Hold, with Elizabeth Gooch MBE (founder of Scale To Value) joining us as special guest. The room was a mix of operating partners, portfolio CTOs, investment directors and a handful of advisers, and we ran the session twice.
Before we started, Ed set a ground rule. Neither of us would say "AI" for the next hour, and anyone who caught us slipping was welcome to shout. By that point in the day the word had been said a fair few times already (it was, to be fair, in the name of the event), and we wanted to see whether a conversation about value creation still held up without it.
It held up fine.
Ed gave the groups a short brief. Everyone was the newly appointed CTO of Meridian, a fictional compliance software business selling to mid-sized UK financial services firms. £18m ARR, 310 customers, 95% gross retention, average customer tenure of eight and a half years. Halberd Capital has just taken a majority stake on a five-year hold, the board has given you a mandate to double ARR and in three weeks you're presenting your priorities to them.
In round one, each group got a worksheet with six value creation candidates: switching costs, an integration library, nine regulatory analysts, fifteen years of compliance data, an industry-leading conference and community, and Meridian Intelligence (the AI assistant, running on a third-party model). For each one, groups marked whether it commanded a premium and gave a short reason.
One of the candidates read: "Fifteen years of compliance data. Every customer decision and audit outcome, going back fifteen years. No competitor has this depth of data."
All twelve groups came back with the data. Fair enough, really (write the answer on the sheet and experienced people will agree with it quickly and without much of an argument). The more interesting bit was in the margins. The deal team in the brief had put that same sentence into the investment case, and exactly one group wrote "Is this true?" next to it.
One, out of twelve.
Round two. A competitor turns up with cash, an engineering team and something to prove, and you've got about twelve months before they ship. Of the things you've just called valuable, which ones are still standing afterwards?
This is the round people enjoy, because knocking things down is more fun than building them, and the room was good at it.
The switching costs came through, a bit shallower than they went in. Ten of the twelve groups had said the low churn deserved a premium, and their reasons were all loyalty, trust and history, which is fair enough for a business whose customers stay eight and a half years. Then somebody pointed out that most of what makes a migration a six-month job is schema mapping, and schema mapping has got a lot cheaper in the last two years. Six months becomes six weeks. The trust survives that, the technical lock-in underneath it gets thinner, and it's worth keeping the two apart in a plan. One group did the arithmetic in the margin, worked out how many new customers a year you'd need to double, looked again at the retention figure and concluded that holding the base and doubling the business are two different projects, and nobody else did the sums.
The integration library got the roughest treatment. Forty-odd connections built over a decade, eating something like 70% of engineering capacity, and ten of the eleven groups who filled in that row said a competitor could rebuild it. One room pushed back, and on good grounds: plenty of the systems on the other end have poor APIs or none at all, so "show a model the input and the output and let it work out the rest" is less of a shortcut than it sounds.
Meridian Intelligence was dead on arrival. Every group killed it, and quickly. A third-party model with none of the company's own data behind it, two competitors shipping the same feature in the same quarter, API bills up and sales flat. On the evidence in front of them, they were right to.
We let that sit for a moment, then described something we'd built for a real client that, from a distance, looks like exactly the same product: an assistant over a corpus, in a regulated setting. The difference is that it runs on data the client owns and nobody else has, and it's bringing in revenue we can measure. Same kind of feature, with something very different underneath it.
Round three gave every group four boxes and four minutes. What could you build on what survived? Why would a customer buy it? Why couldn't a competitor build it inside twelve months? And why would a buyer still pay a premium for it at exit?
Most groups wrote a noun. "Data." "Monetise data." "Surface historic data."
Several got as far as a direction, and in discussion a few landed on the obvious first product, which is telling each customer what its own fifteen years say about its own risk (which control is most likely to fail before the auditor turns up, how the firm scores against three hundred peers, which rule changes touch it and which don't). Good instincts, all of them, but very little made it onto paper, and one group out of twelve finished a pitch.
That group had gone back to the integrations. If those systems really are that hard to connect to, they reasoned, then a decade of solved connections is something other software vendors would pay for. They wrote "license the platform as APIs", which is the whole plan in five words, and then the timer went.
None of this reflects badly on the room. Four minutes is four minutes, and it's a hard question (more or less the question a five-year hold exists to answer, isn't it?). The shape of it has stuck with me, though. Twelve groups of experienced people settled on the same asset almost instantly, then had the same four minutes to say what to do with it and mostly couldn't. Agreeing on the asset costs nothing, and everything after that is what the hold period is for.
The core platform is a fourteen-year-old monolith on a quarterly release cycle, and the two engineers who understand it best are close to retirement. Every idea in both rooms would have had to be built on that system, and no group wrote it down. In the second session a CTO raised it out loud, unprompted, and you could see it land around the room (obvious the moment somebody says it, invisible until they do). Getting that domain knowledge written down, so developers and agents can both work from it without reverse-engineering fifteen years of accumulated decisions, turns two retirement dates from a risk into a deadline.
Much the same with the nine regulatory analysts. In both sessions the room's first instinct was to shrink the team (it's the instinct the technology invites, and every vendor deck this year has encouraged it). One group wrote "knowledge can walk out the door" and another paired "data + analysts" as a single opportunity, and both were closer. Those nine people have spent fifteen years deciding what every FCA change meant in practice, and that judgement is the labelled training data the business thinks it already owns. Put the model on the first pass and the analysts on the review, and you get faster turnaround, less exposure when somebody leaves, a set of interpretations nobody else can assemble, and nine expensive people spending their time on the hard cases. Cut the team first and you've sold the asset to pay for the restructure.
Then there's the legal position. The brief says plainly that nobody has confirmed what Meridian may do with customer data in aggregate. Groups circled it as a risk, which is right, but nobody proposed doing anything about it, including the most obvious move of all: going and asking the three hundred and ten customers. It's a compliance product. The customers are compliance officers. They are, on the whole, people who will read a clause.
One group used the blank row at the bottom of the sheet to write "speed of execution", then marked it as not worth a premium.
Strictly, they were right. Speed of execution is an operating capability, and a well-funded competitor can match it. They were also right that it was missing from our list, and both of those being true at once is more or less where Elizabeth came in.
We'd built the whole session around a filter. Round one asks what's valuable, round two asks what somebody else could copy, and whatever fails round two gets crossed off. It's a tidy structure, it gets people arguing, and it's close to how a lot of technical diligence actually runs.
Elizabeth's objection (put more politely than this, and mostly in the second session) was that the filter throws away perfectly good material. Something being copyable doesn't stop you capitalising on it. Between them, the conference and the community are a direct line to six thousand compliance officers, and neither makes a penny today. No competitor with an engineering team and twelve months can conjure six thousand compliance officers out of thin air. The integrations could be replicated in principle, but this is compliance software sold into financial services, and the more useful question is whether anybody's really going to bother.
Her line, near enough verbatim: "When I look at these candidates, I spot opportunity everywhere."
That's the failure mode we'd accidentally designed into our own workshop, and it's the one we run into most often in real portfolios. A room of capable people applies a diligence reflex, eliminates its way down to the one asset that survives every test, and ends up somewhere perfectly defensible and very small. Defensibility is a useful constraint on the answer. It was never going to come up with the answer on its own.
So, a fair summary of the afternoon: everybody found the moat, almost nobody built anything on it.
What's changed (and the reason we could get through an hour without saying the word) is where the scarce skill sits now. Building the first version of nearly anything has got cheaper, which cuts both ways, because your competitor's twelve-month window has shortened and so has yours. Once the building is cheap, what's left is working out which thing to build, for whom, priced against what they already pay for or already worry about. Product thinking, in other words, which was a slightly unfashionable discipline for a while has become a key part of the job.
If the investment case for one of your portfolio companies has a sentence in it starting "the data is the asset", it might be worth finding out how long it takes somebody inside that business to finish the sentence. On the evidence of two rooms in London, agreeing takes about four minutes. Answering takes rather longer.
Nobody caught us saying it, by the way. Not once, in either session.
If this article raises questions your portfolio hasn't fully answered yet, you're probably somewhere between "we know where the moat is" and "we're not sure what to build on it". That gap is where most of the stalled value creation plans, the untested investment case assumptions and the late surprises at exit are coming from.
Codurance helps PE-backed businesses turn defensible assets into products that create value during the hold: testing the claims in the investment case, surfacing platform and key-person risk early, modernising ageing core systems without stopping delivery, and bringing the product thinking that works out what to build, for whom and why a buyer will pay for it. Whether you need an independent assessment of what your portfolio company's technology can actually support, or hands-on support building on what survives the test, our software craftspeople work alongside your teams to get you there.
Want to know which of your portfolio company's assets would survive the twelve-month test? Get in touch with Codurance to start the conversation.
A moat is a competitive advantage that a well-resourced rival couldn't replicate within a defined window, around twelve months in technology-driven sectors. In a PE context, testing whether an asset such as proprietary data, integrations or customer relationships still holds up under that assumption is central to building a credible value creation plan, not just listing what the business happens to have. You can find out more about this in our whitepaper - The Impact of AI on Private Equity.
Ask whether a funded competitor with a full engineering team could rebuild it within about twelve months. In Codurance's AI Pathfinder workshop, applying this test to a fictional compliance software business eliminated assets - like a decade-old integration library - that looked defensible on paper but weren't once someone worked through how a rival would actually copy them.
Data only becomes a moat when it's paired with something a competitor can't easily copy, such as the domain expertise needed to interpret it or the distribution that gets you the data in the first place. On its own, a claim like “we have fifteen years of data” is a hypothesis to test, not a defensible fact.
Not without care. In the workshop, most groups' first instinct on seeing an AI tool was to shrink the nine-person specialist team behind it. But that team's accumulated judgement is often the hardest-to-replace asset in the business, and cutting it too early can destroy the very thing that made the underlying data valuable.
Treating “copyable” as the same as “not worth building on.” A strict twelve-month copy test is useful for ruling things out, but assets like community, brand trust or distribution can still be commercially valuable even if a competitor could technically replicate them, the more useful question is whether anyone will actually bother.
Sam Griffiths is a Principal Client Consultant at Codurance. He fell into technology after a Geography degree and has spent fifteen years helping organisations navigate cloud transformation, platform engineering and AI adoption. Operating at the intersection of technology strategy and commercial decision-making, he works with clients to identify opportunities, shape solutions and deliver technology investments that create lasting business value.
Ed Farrow is a Principal Client Solutions at Codurance. Ed has a keen focus on software architecture and communicating the need for architectural design to the wider business. He also has a particular interest in managing technical debt within organisations, including handling technical debt as part of wider business risk management frameworks.