The board pack arrives. The AI initiative is on slide nine. Build-vs-buy underway, vendor evaluation in progress, capital request landing next quarter. The sponsor nods. The CEO moves on. Six months later the slide reappears with the same objectives and nothing customer-visible has shipped.
It is not a vendor-selection problem and it is not a CEO-conviction problem. The capital is available. The mandate is there. The engineering team genuinely wants to be more AI-native. What is missing is structural, and the foundation work is not the kind of thing that wins a slide.
SaaS platforms were built before LLM-based architectures were a real engineering choice. The data is structured for fast transaction processing in tightly partitioned schemas, optimized to serve thousands of customers cheaply on shared infrastructure. Integrations between systems are point-to-point. That architecture is what made the unit economics work for traditional SaaS. It is also what makes AI workloads slow and expensive to run on top of it. None of it was wrong at the time. It is the wrong starting point now.
Bolted-on AI does not survive that environment. A "summarize this record" co-pilot feature shipped on top of a legacy data model becomes a feature flag nobody uses. The latency is inconvenient, the context is incomplete, and the customer still has to do the workflow they were doing before. AI deployed checkmark shows up on the slide. Customer pull does not.
So the team tries again. A new vendor. A different feature. Same legacy architecture. Same outcome. The pattern repeats because the conversation keeps anchoring on which AI features to build, when the question underneath is different.
The right question is what it takes to make the organization and the platform capable of shipping AI in the first place.
The two pieces of foundational work that need to be scoped
Two things have to be true before any AI feature ships in a way the customer can feel. Both require investment that is invisible on a status slide, which is why most portcos skip them.
The first is engineering-org redesign. Before the team can ship AI features the customer feels, the team itself has to be rebuilt around AI tooling -- code generation, test generation, documentation, ticket triage, bug reproduction. The capability has to be internal before it is customer-visible. An R&D org that does not use AI to build software cannot credibly ship AI inside its product. Companies that skip this step end up with engineering teams that cannot keep pace with the roadmap they have been handed. The ones with deep customer moats survive it. The ones without do not.
The second is the data and retrieval layer. AI workloads need context-aware retrieval that legacy data models were never designed to provide. This is the hard, multi-quarter platform investment most companies do not scope, and there is no shortcut around it. The portcos that ship credible AI features have done this work first. The ones still stuck on slide nine have not.
Once the foundation is in, the product work has a sequence. Apply AI first to existing, tested workflows where it amplifies what the customer is already paying for. The workflows the product already does well, executed faster or with less manual lift, where the customer's mental model does not have to change. This is where the early, real wins come from -- and where most portcos under-invest because the slide does not flatter the work.
Only then does in-code AI insertion make sense. AI inside the platform code path, in places where it improves outcomes the platform already produces, with deterministic fallbacks when the model output is wrong. This is the riskiest move and the one most often done badly. The discipline is surgical. The goal is to leave the core intact and let AI improve specific operations inside it. New AI-native features and capabilities come after that, not before.
The funding question, answered honestly
This is where most board conversations stall. The work above is opex-heavy. The capital has to come from somewhere, and most companies model it as new investment competing with everything else in the operating plan.
That framing is what makes the program look unaffordable. The honest model is different. A serious AI program, sequenced correctly, generates the cost takeout that funds the next phase of itself. Not all of it on day one. Enough that the conversation shifts from "can we afford this" to "what is the sequencing that lets the savings fund the build."
Three sources, in order of reliability.
The largest is the cloud migration program. Most PE-backed software portcos have a long tail of on-prem customers running deployments that get harder to maintain every year. The conventional read is that on-prem makes the AI problem worse. The data is not in the cloud, the deployment is bespoke, the model serving infrastructure is not there. All true. And exactly why the constraint is leverage, not blocker.
The play is to bundle embedded AI capability with a managed cloud migration the customer funds. The customer gets two things they have wanted but could not justify on their own: modern AI capability inside the product they already use, and a path off the on-prem deployment they have been quietly worrying about. The portco gets three things. Higher-margin recurring revenue replacing lower-margin maintenance contracts. A maintainable cloud environment instead of dozens of bespoke installations. A one-time professional services revenue event that funds part of the AI build. The customer relationships that survive a successful migration are also stickier than the on-prem ones they replaced, which compounds in any future exit scenario. Most portcos with on-prem tails have not seriously costed this move.
The second source is infrastructure rationalization. The AI program forces a hard look at hosting, tooling, and data infrastructure spend that most portcos have never aggressively rationalized. Workload-appropriate compute, retired duplicate tools, consolidated data infrastructure -- the savings are real, repeatable, and recur every year, even if rarely transformative on their own.
The third is R&D capacity expansion, and this is where the operating plan needs the most discipline. The 2025 METR randomized controlled trial found experienced developers were 19% slower with AI assistance on familiar codebases. The savings live where the conditions are right -- greenfield work, junior engineers, unfamiliar stacks, the activities adjacent to coding. They are smaller and sometimes negative on senior engineers maintaining mature systems. Three factors move the equation and most operating plans miss them: tool familiarity (the leverage shows up after a learning curve longer than most pilots run), effective cost per task (headline token rates are falling, but denser tokenizers and agentic patterns push effective consumption the other way), and whether the legacy codebase gets refactored into something AI can actually maintain. The honest planning assumption is that AI tooling, applied with discipline, lets the org hold engineering headcount flat against a meaningfully bigger and faster-moving roadmap. Real, sequenced, and contingent on the conditions the operating plan sets up.
Modeled this way -- cloud-migration margin lift, infrastructure rationalization, and engineering capacity that holds payroll flat against a bigger roadmap -- the AI program funds a material portion of itself within the hold period. The sponsor conversation stops being about whether to commit capital and starts being about which sequencing puts the cost takeout in front of the next phase of the build.
What it leaves out, and why it matters
The picture above is the year-one and year-two operating math. What it deliberately leaves out is what compounds across the hold period.
Customer churn impact, positive if the AI capability is real, negative if shipped before the architecture is ready. Pricing power changes as the product capability gap to competitors widens or narrows. Sales-cycle compression where AI capability becomes a deal qualifier in renewals. Token consumption on the customer-payload side, which scales with usage and becomes a real cost line if pricing does not account for it. None of these belong in the year-one synergy model. All of them belong in the exit thesis.
The sponsor's job in this conversation is not to push the AI narrative harder. It is to ask the structural questions and enforce the sequencing discipline. Has the engineering org itself been redesigned around AI tooling, or are we shipping AI features on top of a development organization that does not yet use AI? Is the data layer built for AI workloads, or are we layering features on top of a model that cannot support them? What is the cloud migration play, how much of the AI program does it fund, and are we using AI to accelerate the migrations themselves? Are we modeling the cost takeout honestly, including the parts of R&D leverage that do not actually materialize?
The portcos that ship AI well are not the ones with the loudest AI narratives. They are the ones that did the unglamorous foundational work first, identified where the funding actually comes from, and only then turned the capital toward customer-visible AI features. The sequence is the strategy. Most portfolios will not have the operating bandwidth to run it without help.