We’ve been here before: what the SaaS migration tells us about the AI-build moment
The conversation about AI and accounts payable automation is being treated as if it’s new. From where I sit, having spent a long career listening to finance and IT leaders work through software decisions, it doesn’t feel new. It feels like a cycle I’ve watched before, just running faster.
I started out as a developer in the Visual Basic days. The instinct back then, in a lot of organisations, was simple: if we can build something internally that does exactly what we want, let’s do it. A lot of companies acted on that instinct. What they discovered, ten years later, was that they’d ended up tied to those systems, carrying the maintenance burden, and slowly losing the flexibility they’d originally built for. That’s a large part of what drove the migration to SaaS. Companies wanted standard software with a bit of flexibility, and they wanted the deep specialty of running it to live somewhere outside their own four walls.
The reason I bring that up is that the build-vs-buy question we’re hearing now, with AI as the new building capability, looks very similar from the buyer’s seat. The arguments are the same. The instincts are the same. The promises being made are remarkably similar. And I think we’re at risk of repeating the same cycle, except this time it’ll happen far more quickly and in a more complex way than it did the first time around.
This isn’t a piece arguing that internal builds are always wrong. They sometimes aren’t. It’s a piece arguing that the question deserves to be asked with the benefit of recent history, rather than as if the industry is encountering this trade-off for the first time.
Read: an honest examination of what build actually entails today.
What the last cycle actually looked like
The build cycle of the late 1990s and 2000s wasn’t driven by hubris. It was driven by genuine capability. Better development tools, more powerful databases, the early commercial internet. The barrier to building enterprise software inside your own organisation came down meaningfully, and a lot of companies took the opportunity to do exactly that. Bespoke financial systems, custom-built workflow engines, internally developed integration layers. For a stretch of time, building looked like the obvious answer for any organisation with a competent IT team.
What happened next is the part worth remembering. The first three or four years were generally fine. The systems worked. They handled the use cases they were built for. And then the world started moving around them. New regulations came in. ERPs were upgraded or replaced. Acquisitions brought new business units that needed to be integrated. Security postures had to be hardened against threats that hadn’t existed when the original systems were designed. Each of these changes was small in isolation. Cumulatively, they were what eventually broke the case for in-house build.
My colleague Ben Fitzgerald, our Head of Engineering, made the same observation from the other side of the table on a recent webinar we ran together. People did build their own software. They did host their own software. They built their own websites and hosted those too.We watched a lot of that infrastructure quietly stop being defensible as the years went on, and we watched a generation of finance and IT leaders make the call to stop carrying it.
The migration to SaaS that followed wasn’t ideological. It was operational. As Ben put it, organisations wanted the flexibility, but they also wanted the specialty of running specific kinds of software to sit outside their business. The capabilities offered by hyperscale cloud platforms went well beyond what most internal IT teams could provide on security, reliability, compliance, and ongoing flexibility. Companies were happy to pay a premium for those things, because the alternative was carrying an ongoing total cost of maintenance that quietly grew every year.
That’s the cycle in compressed form. Build, plateau, accumulate maintenance debt, migrate. It took roughly a decade to play out the first time.
Why this cycle is going to compress
What’s different about the current AI-build moment isn’t the underlying logic. It’s the speed.
AI-assisted development genuinely is faster than anything we’ve seen before. Prototyping cycles that used to take weeks now take days. Implementation work that would have demanded a full engineering team can be bootstrapped by a much smaller group. None of that is hype. The capability is real, and from a buyer’s perspective, it’s easy to see why finance and IT leaders are looking at it and asking the same question their predecessors asked twenty years ago: if we can build it internally, why wouldn’t we?
The honest answer is that the same speed that makes the initial build look attractive is also going to make the regret cycle arrive much faster. If it took a decade for in-house enterprise software to plateau and start accumulating maintenance debt the first time around, AI-assisted development is going to compress that timeline meaningfully. The build phase is shorter. The capability lift is faster. And, just as importantly, the surrounding environment is moving faster too.
That last point is the one that gets missed in most build proposals. Ben raised it on the webinar in a way that stuck with me. The external systems your AP automation has to connect to, principally your ERP and any third-party finance tools, are also being accelerated by AI. Vendors are leveraging the same capabilities to move their own platforms forward more quickly. So if you’re building internally, you’re not just maintaining your software against a static environment. You’re playing catch-up against a moving one.
That changes the maths. In the first build cycle, an internally built system had to keep up with regulatory change, security threats, and a relatively slow rate of platform evolution. In this cycle, it has to keep up with all of that plus a baseline rate of vendor innovation that’s now itself AI-assisted. The treadmill speed has gone up.
The questions worth asking now
If the cycle is going to compress, the question isn’t whether the migration phase will arrive. It’s whether you want to be the team that absorbs the cost of the cycle, or the team that doesn’t.
There are three questions I’d encourage any finance or IT leader currently weighing an AI-build option to answer honestly before committing:
1. What is your core specialty?
Ben framed this directly on the webinar. If your core business is manufacturing, why are you running your own servers and building your own software? How is that going to accelerate revenue or improve cost efficiency in any meaningful way? The build instinct often gets justified on innovation grounds, and there’s a reasonable version of that argument. But building production-grade financial software is a sustained drain on capacity that has to come from somewhere, and it usually comes from the work that’s actually differentiated for the business. Software ends up pulling people away from whatever it is the business is genuinely specialised in.
2. Does the build proposal in front of you account honestly for the operating reality?
Most build cases I’ve seen presented model a one-time engineering cost, an ongoing run cost, and a comparison against vendor licence fees. The framing is clean. It’s also wrong, because it doesn’t account for what changes around the system over time. Requirements change. Security environments change. ERPs change. Compliance regimes change. The system doesn’t get to stand still, and someone has to own that ongoing work. Ultimately, you need a system designed to absorb change as part of the platform.
3. Who’s going to be there in three years’ time?
Nobody likes asking this question. But the system someone builds today will need to be maintained, modified, and defended in front of an auditor years after the people who built it have moved on. Documentation only carries you so far. Domain knowledge is harder to transfer than code. If the AI architect who built this is no longer with the organisation, who’s going to be the person who can go in and explain, with confidence, why the system makes the decisions it makes?
These aren’t abstract questions. They’re the questions that determined which side of the SaaS migration each organisation ended up on the first time around. They’re the questions worth answering honestly now, while the build decision is still in front of you, rather than three years from now when the maintenance debt has accumulated and the migration question has become a lot more expensive to act on.
This isn’t a vendor-says-no argument
A piece like this can read, fairly, as a vendor making a case. So I want to be precise about what the argument actually is.
The case for buying isn’t that internal teams can’t build. They demonstrably can, and AI-assisted development has made that more true than it’s ever been. The case for buying is that the long-term operating cost of finance-critical software is genuinely high, the failure modes are unforgiving, and the buyer-side question deserves to be asked with the benefit of recent history rather than as if it’s being asked for the first time.
I’ve been on the other side of enough enterprise software decisions to know that the buyer’s instinct, when shown a working prototype, is to imagine the production version of that prototype. That instinct is reasonable, and it’s the same instinct that drove the first build cycle. The difference now is that we have a recent precedent, well within professional memory, for what happened next. The migration to SaaS wasn’t an industry consensus that emerged out of nowhere. It was a correction. Companies had built things they couldn’t sustainably run, and over time they made the call to stop running them.
If the AI-build cycle compresses the way I think it will, that correction is going to arrive faster this time. The teams who acted on the build instinct in 1998 had the better part of a decade before they had to face the migration decision. The teams who act on it in 2026 are going to be facing it sooner than they think.
It’s a different set of parameters than building a marketing tool or an internal dashboard. It’s the lifeblood of the organisation we’re talking about. That’s the frame I’d want any AP automation build decision to be made inside.