The binary nobody plans for when they build with AI

Most internal-build business cases for AP automation that I’ve seen have the same shape. There’s a one-time engineering cost. There’s an ongoing run cost. And there’s a comparison against vendor licence fees over some defined horizon, usually three to five years. The framing is clean, the maths is tidy, and the conclusion is often that building internally comes out ahead. 

I want to argue, from inside engineering, that the framing is wrong. Not because the numbers are off, but because there’s a category that’s missing from the equation entirely. There is no steady state for self-built finance software. Either it’s being actively reinvested in, with that investment compounding annually as the surrounding environment moves, or it’s quietly degrading against an environment that doesn’t sit still. There’s no third option. And the version of the build case that ignores this, which is most of them, is making a structural mistake that will land on someone’s desk eighteen to twenty-four months after the system goes live. 

That’s the argument. The rest of this piece is the working. 

The build case that almost everyone presents 

The reason build cases look attractive right now isn’t mysterious. AI-assisted development has genuinely shortened the path from idea to working prototype in a way that wasn’t possible two years ago. It’s a very exciting time in terms of what’s possible from idea to a working thing. You can ask a question and get answers. You can prototype something. You can have a non-technical person in a finance team express what they want to see in a workflow, and an AI development environment can produce a usable starting point. 

That’s a genuine shift, and I don’t want to dismiss it. The capability is real. Tools like Lovable, vibe-coding environments, and AI development assistants have meaningfully changed what a small team can stand up in a short period of time. If you’re a finance leader looking at this and asking “couldn’t we just build it ourselves,” that’s a reasonable question to be asking. The barrier to a working prototype has come down. 

The trouble is that the build case typically gets framed against the build phase only. The cost line in the proposal usually has two components: the engineering cost to build, and the ongoing run cost to keep it running. The “run” line is sized small, because once a system is built, the working assumption is that maintenance is a manageable trickle of patches, occasional upgrades, and incidental support. 

This is the part of the model I want to challenge. The “run” line, in finance software, is not a small steady-state number. It’s either a continuously growing investment, or it’s a quietly declining capability. Pick one. 

Why there’s no steady state 

Software is not a fixed object. It’s a point in time of the world. It reflects the requirements of the business at the moment it was built, the libraries it was assembled from at that moment, the integrations it was wired into, and the regulatory regime it was designed to comply with. None of those stay still. 

The world keeps moving. New attack vectors get developed. New libraries get released and old ones get deprecated. Your organisation moves on. You purchase a company. You want to integrate it, and now that’s hard, because the connection layer to your previous ERP was AI-generated and the new business unit is on a different platform. That kind of integration debt isn’t unusual. It’s the operating reality of any organisation that’s growing or evolving in any meaningful way. 

There’s a second mover too, which most build cases ignore entirely. The vendors of the systems your software has to talk to are also accelerating. Your ERP vendor is leveraging AI to move their platform forward faster than they were two years ago. Their integration surface is changing. Their data models are evolving. Their compliance posture is being updated to keep pace with regulation. If you’re maintaining an internally built AP system, you’re not just maintaining it against a static environment. You’re maintaining it against a moving one, and the speed of that movement is itself increasing. 

That’s what I mean when I say there’s no steady state. The system you build today is sitting inside an environment that’s moving in five different directions at once. You can either invest enough engineering capacity to keep moving with it, or you can watch the gap between your software and the environment widen quietly until something breaks. 

What “investing” actually requires 

The investing path is the one most build cases assume implicitly without costing it honestly. The honest version is more demanding than people expect. 

Investing in self-built finance software means continuously funding the engineering capacity to keep it stable, modern, useful, and secure.[^18] Each of those words is doing work. Stable means catching and patching the edge cases that emerge from real production data, which only surfaces over months and years of operation. Modern means upgrading dependencies, refactoring for new platform requirements, and migrating off deprecated services before they become a security liability. Useful means responding to changes in business requirements, new tax regimes, new approval workflows, new compliance demands. Secure means tracking the threat landscape, hardening the system against new attack vectors, and maintaining the certifications that audit teams will ask for. 

Each of those is a sustained engineering cost. Not a one-off. Not a “we’ll handle it in maintenance windows.” A continuous, funded engineering function dedicated to a system that isn’t your core business and doesn’t differentiate you in your market. 

The honest TCO question, in other words, isn’t “what does this cost to build.” It’s “are we committing to fund the investing path indefinitely, with the engineering capacity that path actually requires, and is that funding real?” If the answer is yes, the build case may stand up. If the answer is “we’ll see how it goes,” what’s actually being committed to is the second path. 

What “sun-setting” actually looks like 

The sun-setting path isn’t a deliberate choice. Nobody approves a build proposal saying “and after eighteen months we’ll let it rot.” It happens by default, when the investing path turns out to be more expensive or more demanding than expected, and the engineering capacity gets reallocated to something else. 

The way I’d describe what happens after that point is that the software starts to erode. If you’ve built something and left it for a year and a half, it’s already eroding. There’s a phrase we use in engineering for this: bit rot. It’s not poetic. It’s a real thing. 

Bit rot in finance software has specific symptoms. Dependencies you imported eighteen months ago now have known security vulnerabilities, and patching them requires changes to surrounding code that nobody currently on the team understands. The integration to your ERP starts hitting deprecation warnings. The compliance posture you certified at launch no longer maps cleanly to current regulation. The documentation describes a version of the system that doesn’t quite match what’s running in production, because three small changes were made along the way and the documentation didn’t get updated. The original engineer has moved on, and the institutional knowledge of why specific decisions were made has gone with them. 

None of these symptoms are catastrophic on their own. The system keeps running. Invoices keep getting processed. From the outside, things look fine. But the cost of any future change has gone up, and the risk of any future failure has gone up with it. The first time you discover the real cost of bit rot is usually when something forces a change. A new ERP. An acquisition. A regulatory deadline. A security audit. At that point, the conversation with the engineering team is much harder than the original build proposal suggested it would be. 

The acquisition trap 

There’s one specific failure mode worth singling out, because most build cases ignore it entirely and it’s the one that catches finance leaders by surprise most often. It’s what happens when the business does an acquisition. 

The acquired company is on a different ERP, or on a different version of the same ERP. Their finance processes don’t map cleanly to yours. The integration timeline that the deal team has assumed is twelve weeks. And then somebody in the AP team has to surface the fact that the connection to your existing ERP was built two years ago by an AI development environment, and modifying it to handle the second ERP isn’t a small piece of work. It might be a substantial one, depending on how the original system was structured and how well it was documented at the time. 

If you bring in specialists, they’ll get there quicker, because they’ve already solved this problem in dozens of similar environments. If you’re trying to do it with the team that built the original system, assuming they’re still with the organisation, the timeline starts to slip. 

Acquisitions are a useful test for any build proposal because they surface the integration debt that’s been quietly accumulating in the background. If your AP system can’t gracefully accommodate a second ERP, a third entity, or a different jurisdiction, the build case has to account for the cost of getting it to that state at the moment that requirement arrives. That cost should be in the original TCO. It almost never is. 

The honest question to put to a build proposal 

The frame I’d put in front of any finance or IT leader currently weighing a build decision is this. There is no steady state. The decision in front of you is not “build versus buy.” It’s “commit to the investing path, with the engineering capacity that path actually requires, or commit to the sun-setting path, with the erosion timeline that path implies.” There’s no middle ground. 

The investing path can be the right answer. For a small number of organisations, with deep in-house engineering capability, distinctive requirements that vendors don’t address well, and a strategic reason to keep the capability inside the business, it stands up. Where that case is genuinely defensible, my colleague Peter Briggs has written about this in detail. 

For most organisations, the investing path is more expensive than the original build case acknowledges, the sun-setting path arrives faster than anyone anticipates, and the question that ends up on the boardroom table eighteen months later is the same question that drove the SaaS migration twenty years ago. We’ve been here before, and the lesson from the last cycle is worth remembering. 

The capability AI gives us is genuinely powerful. There’s a phrase from the same conversation that I keep coming back to: with fire you can cook, but you can also burn yourself. That’s the frame I’d want any AP automation build decision to be made inside. Cautious excitement, not naysaying, not hype. Specifically, the kind of caution that costs out the investing path honestly before signing up for it.