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 is true. The tools these systems are built on improve every few months. Each improvement makes some of the machinery around them unnecessary, and part of it worse than unnecessary. A work-around added to compensate for something the tool could not do yet becomes, once the tool can do it, the reason the result is weaker than it should be.
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.
Small enough that changing it is your call.
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, an implementation partner, a discovery phase, and a year or more of custom work built around a vendor's platform. The business case runs five years, because five years is how long it takes for the payback number to work.
The second is one process. Written down, built and live in about a month, inside a three-month initial term, and yours as it is paid for: the code, its history and documentation.
Both need rework within a year or two. Only one can absorb it without a negotiation.
A five-year payback is a commitment that the decisions in month three are still correct in year five. 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%. The exposure is proportional to what you committed.
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
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. For a buyer, that becomes three things to ask for by name, before anything is built.
One connection for each system you own. When the tool underneath changes, or your system gets upgraded, you replace one connection instead of reopening the build.
The rules held as values that you can read and change, each one dated, rather than buried inside the working parts of the system. When a threshold moves, it should be moved by editing a single number, not by commissioning a new 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.
The thin proposal is the one you can undo.
Two Questions That Settle It
You do not need to evaluate the technology to decide this well. Two questions do most of the work, both with answers you can check against a contract, not 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. The answer belongs in writing before the first payment.
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. The service determines the commitment: Advisory can operate a system already built, while Engineering includes ongoing development and operation. Each release is prioritized and agreed with you.
Where This Argument Stops
It stops wherever the process is the same as the process a thousand companies run. For payroll, expense claims and the general ledger, buy the packaged product, configure it, and build nothing. This argument is about work specific to your company, where no product fits and the alternative to building is to continue doing the work by hand.
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 the vendor what happens if they are not.
Look for the work-around in something you run. Ask the person closest to it whether it is still needed. That conversation costs nothing and is the 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.
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 against a commitment long enough that the first change has to be negotiated.
A fifteen-minute call, nothing paid, nothing signed, takes one of your processes 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 does the job.
