The objection usually arrives late in the meeting, from the person who has watched a project age badly. Whatever we build now will be out of date in a year. Why not wait.
The first half of that is true, and it is worth saying plainly rather than arguing with it. The tools these systems are built on improve every few months. Each improvement makes some of the extra machinery built around them unnecessary, and a part of it worse than unnecessary. A work-around added last year to compensate for something the tool could not do yet becomes, once the tool can do it, the reason today's result is weaker than it should be. Nothing announces this. The work-around still runs, and it still returns an answer.
The second half does not follow. Waiting is a decision with no end date, because there is no version after which the improvement stops and the ground settles. The question that decides your exposure is not whether what you buy will need changing. It will. The question is what changing it costs you, and whether you need anyone's permission to do it.
Two Shapes Of The Same Decision
Put two purchases side by side, both pointed at the same broken process.
The first is a programme. A licence, a partner, a discovery phase, and a year or more of custom work built around a platform. The business case runs five years, because five years is how long it takes for the number to work.
The second is one process. Written down, built, handed over, running in about a month, and yours afterwards.
Both will need rework within a year or two. Only one of them can absorb it without a negotiation.
A five-year payback period is a commitment that the design decisions taken in month three are still correct in year five. Nobody signing it believes that literally, and it goes into the numbers anyway. When the rework comes, it is a change request against somebody else's contract, priced by the party who wrote it and scheduled against their other clients.
Size makes this worse rather than better. A study of 1,471 IT projects (Harvard Business Review, 2011) found an average cost overrun of 27%, which sounds survivable, and then found that one project in six was an extreme case — a cost overrun of 200% on average and a schedule overrun of almost 70%. Later work on a larger sample of 5,392 projects (Journal of Management Information Systems, 2022) explains why the average misleads: overruns follow a power law with a fat tail, so the extreme case is far more common than a normal spread would predict. The exposure is proportional to what you committed.
None of this is peculiar to AI. The laws of software evolution (Lehman, Proceedings of the IEEE, 1980) established that software embedded in a real process must keep changing or become steadily less useful, and that it grows more complex as it changes unless deliberate work holds that down. Rework is not a symptom of this particular moment in technology. It is the normal condition of any software that is actually used. What is new is only the speed.
The question is not whether it will need changing. It is whether changing it is a decision you make, or a negotiation you enter.
Put The Part That Will Change Behind One Boundary
Which part will change is not a mystery, and it has not been one for fifty years. The criterion for dividing a system into parts (Parnas, Communications of the ACM, 1972) is to draw the boundaries around what is likely to change, so a change lands inside one part instead of spreading across all of them. It is the oldest useful idea in the field, and it is the one that sets your cost of change.
For a buyer, that criterion becomes three things you can ask for by name, before anything is built.
- One connection for each system you already own. When the tool underneath changes, or when your own accounting system is upgraded, you replace one connection instead of reopening the whole build.
- The rules held as values you can read and change, dated, rather than buried inside the working parts. A threshold that moves should move by editing a number, not by commissioning a release.
- The record kept separately from the part that does the work. What ran, when, who approved it, what it decided. That record is the asset that survives every replacement, and it is the first thing lost when the working part is discarded.
None of the three is expensive at the time. All three are what make the replacement cheap later, and none of them can be added afterwards at the same price.
Two Questions That Settle It
You do not need to evaluate the technology to make this decision well. Two questions do most of the work, and both have answers you can check against a contract rather than against a demonstration.
When this needs to change in eighteen months, what will that cost, and who decides? A vendor who cannot answer with a number and a name is telling you that the answer will be set later, by them, when you have no alternative. The answer you want is boring: here is the rate, here is the notice, and you can also give the work to somebody else.
If I stop paying, what do I still have? Working software, the code, the history and the documentation is one answer. Access to a service that ends the day the invoice does is a different one. Both are legitimate purchases and they carry opposite risks, so the answer belongs in writing before the first payment, not in the renewal conversation eighteen months later.
Running something every day and changing it are different jobs, and a vendor who blends them is selling a permanent dependency at a monthly price. Ours stay separate on purpose: the monthly work is keeping the system running and never quietly includes new development, so any rework is its own engagement, decided by you when you want it.
Where This Argument Stops
It stops wherever the process you need is genuinely the same as the process a thousand other companies run. Payroll, expense claims, the general ledger — buy the packaged product, configure it, and build nothing. The argument here is about the work that is specific to your company, where no packaged product fits and the alternative to building something is continuing to do it by hand.
It also stops where the small thing is small because the scope was cut in the wrong place. A process split down the middle to fit a short timeline produces two half-processes and a person carrying items between them, which is worse than what you had. Small means one complete process end to end, with a written definition of what it must do. It does not mean part of one.
And it stops where the cost of being wrong is high enough that the slow, heavily controlled path is the correct path. Where a mistake reaches a patient, a regulator or a published figure, the controls come first and they set the timeline. That is a real constraint, and it is a different article from this one.
First Steps
- Find the payback period in the proposal on your desk and read it as a promise. Anything longer than about two years is a claim that the decisions made this quarter will still be right that far out. Ask what happens if they are not.
- Look for the work-around in something you already run. Every system built in the last two years has at least one piece that exists only because a tool could not do something yet. Ask the person closest to it whether it is still needed. That conversation is free and it is the whole argument in miniature.
- Price the smallest complete version of the thing you were about to buy large. One process, end to end, with a written definition of done. If the small version is not worth its price on its own, the large one was never going to be worth five years of its own.
Small Enough To Change Your Mind
The reader who raised the objection was right about the fact and wrong about the conclusion. Yes, this will need changing. That is an argument for buying something whose replacement is cheap, owned outright, and requires nobody's approval but yours — and it is an argument against a commitment long enough that the first change has to be negotiated.
The test is one you can apply to any proposal in front of you without knowing anything about the technology. How long before this pays for itself, what does the first change cost, and what do I keep if I walk away. A proposal that answers all three plainly is a proposal you can act on this quarter.
A fifteen-minute call — nothing paid, nothing signed — takes one process apart and says what it would take, what it would cost, and where the boundary should sit so that the next change is cheap. Sometimes the answer is that a packaged product already does it, and that answer costs you nothing.
References
- Flyvbjerg, B., & Budzier, A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, 2011.
- Flyvbjerg, B., Budzier, A., Lee, J. S., Keil, M., Lunn, D., & Bester, D. W. The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution. Journal of Management Information Systems, 2022.
- Lehman, M. M. Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE, 1980.
- Parnas, D. L. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 1972.
