The most useful thing anyone said to me about that budget came from the business side rather than from engineering. Connectivity had no freedom when it came to maintenance, because there wasn’t capacity for the roadmap and the constant maintenance requirements at the same time. That one sentence explained more about the budget than the budget did.

It was a multimillion-dollar group, engineers and suppliers together.

The committed fraction #

Committed doesn’t mean every task is known in January. It means experience tells you the capacity will be consumed whether you put a name against it or not. Every integration we ran had a standing cost that had nothing to do with building anything: dependency upgrades, partner-initiated changes, certificate rotations, incidents, compliance requests, and the steady drip of work that arrives because somebody else changed something. None of it appears on a roadmap. All of it gets paid for.

That’s the number worth knowing, and almost nobody can tell you theirs. Not the total, the fraction of it you can still direct. If four fifths of your capacity is committed before the year starts, then your real budget is whatever the remaining fifth costs, and every prioritisation argument you have is really an argument about that slice.

Estimates stop being about value and start being about capacity. When somebody asks what a new integration will take and the answer is three weeks, the real question isn’t whether it’s worth three weeks. It’s which of the other three-week things isn’t going to happen. Nobody frames it that way in the meeting, and it’s what everybody is actually deciding.

Reducing the committed fraction is some of the most valuable work available to you, and it rarely gets funded on its own merits, because “we will spend less time on maintenance next year” is not a thing anybody can put in a board pack.

When you buy, you’re not buying the feature list #

For most of what a payments group needs, building is the wrong answer and everybody knows it. The interesting question is what you’re actually purchasing.

You’re not purchasing the feature list. You’re purchasing the vendor’s roadmap, their operational behaviour when things break, and the cost of leaving them later. I’ve argued before that you should qualify suppliers on how they behave when they’re broken, and this is the same idea from the budget side: the feature comparison is the cheap part of the decision and the part everybody spends their time on.

The line item that goes missing from the business case is the exit. What it costs to migrate off, how long you’d be running both, and whether your own architecture makes that a project or a piece of contained work. If you can’t answer that at the point of signing, you haven’t priced the purchase, you’ve priced the first year of it.

Build is what you do when nobody else will carry the risk #

We ended up building things that a vendor could technically have done, and the reason was almost never cost.

The shape repeats. Some third party has to approve what you are launching, the approval takes work, and the vendor whose product you are using has no particular reason to do that work for you. The compliance effort lands where the liability lands, and no amount of vendor relationship changes who is answerable when a regulator asks the question. So you do it yourself, not because it is cheaper, but because the alternative is depending on somebody with no exposure to the outcome.

Build when the critical risk stays with you regardless of who supplies the software. Buy when the supplier can genuinely absorb enough of the execution burden to make the dependency worth having. Note what that isn’t: a claim that buying moves accountability. In a regulated business you will still be the one explaining a vendor’s failure, which is exactly why the question is about execution risk rather than about whose name is on the invoice.

Cost belongs later in the decision than most organisations put it, and moving it to the front is how they end up outsourcing exactly the things they cannot afford to outsource.

Killing is the part that actually takes skill #

Everyone finds starting things easy. Stopping them is where the money is, and it’s harder than it looks because a supplier you’ve decided against is still carrying live traffic.

There was a provider relationship that had stopped working. What strikes me now is the sequencing. Not “cancel them”. Instead: establish whether the relationship is genuinely dead, and only if it is, move to the named alternative. That ordering matters. Until you know what replaces a supplier and what the migration costs, cancelling isn’t a decision, it’s a wish, and you’ll discover the real number halfway through the quarter.

The same applies to internal work. The must-have lists we kept before any launch were mostly useful as kill lists, because writing down the four things that genuinely blocked going live made everything absent from the list explicitly optional. That’s a cheap trick and it works. People will argue for hours about priority and agree in minutes about what blocks a launch.

The only spending that compounds #

If most of the budget is committed and the discretionary slice is small, then the slice shouldn’t be spent on whatever is loudest that quarter. It should be spent on things that reduce the committed fraction or buy you options later. Anything that makes a supplier easier to replace. Anything that turns recurring manual work into something that doesn’t need a person. Anything that shortens the distance between deciding and shipping.

None of that is exciting and none of it demos well. It’s also spending this year’s capacity to buy back next year’s.

The part I got wrong for a while #

For my first few months I thought my job was allocating the discretionary slice well. Choosing between the good options in front of me, defending the choices, delivering them.

It took longer to notice that the size of the slice was itself something I could change, and that nobody was going to ask me to. The committed fraction is invisible in every reporting structure I’ve worked in. It doesn’t show up as a line, it shows up as slowness, and slowness gets attributed to the team rather than to the shape of what the team is carrying.

If you’ve found a clean way to present that to a board, I’d genuinely like to hear it. I haven’t.