A letter to whoever is holding December's leftover software budget

Dear whoever is holding the leftover budget

You know who you are. It's the middle of December, the year's numbers are nearly final, and there's an amount left in the software or IT line that will disappear if it isn't spent. Someone has already suggested what to spend it on. It was probably in a demo.

I'm writing because we've seen this moment from the other side many times, and the decision made in the last two weeks of the year tends to stick around for a long time. A new subscription renews. A half-started project needs another budget to finish. A tool nobody adopted still shows up on the card statement in June.

There's a quieter way to spend it. The best year-end purchase is the one nobody will mention in March, because the thing it fixed stopped being a problem.

Please don't buy the thing everyone demoed, yet

I'm not against new tools. Some of them are excellent. But December is a bad month to choose one.

Half your team is away. Nobody has time to set it up properly, so it will be set up quickly by whoever is around. Its real cost starts next year, when the subscription renews at full price and the training and integration work show up. If it's an AI tool, its pricing may also change between now and renewal, which we've written about before.

If the tool is genuinely the right choice, it will still be the right choice in February, when you can trial it with the people who'll use it. Put it on the list for then.

The same goes for big rebuilds. If someone wants to use the money to start replacing a core system, ask whether the remaining budget would finish anything usable on its own. Usually it would pay for the discovery and leave the build waiting. Discovery is useful, but only if next year's budget for the build is already agreed.

Spend it on the boring fix

Instead, look for work your team does every week that software could make smaller. It's rarely exciting. It's usually obvious once you ask.

Ask around for things like these:

• The export someone does by hand every Monday, copying numbers from one system into a spreadsheet for someone else.
• The spreadsheet that has quietly become your software, which only one person dares to edit.
• The admin screen that takes four clicks and a page reload to do something the team does sixty times a day.
• The integration that breaks every month and gets fixed by restarting something.
• The process that lives in one person's head, and would stop if they were out sick in January.

Pick one. Not three. Choose the one where the people doing the work will notice the difference within a week of it shipping.

Here's a composite of how that goes. An office manager spends every Monday morning pulling last week's orders out of the store's admin, pasting them into a spreadsheet, fixing the dates that paste as text, and emailing the result to the owner and the bookkeeper. It takes about two hours, and it's wrong whenever she's on holiday and someone else does it. A small piece of work that builds the same sheet from the store's data and sends it at 8 AM gives her Monday mornings back. Nobody will ever present it at a meeting. Everybody will notice if it stops.

Make it small enough to finish by March

The danger with year-end money is starting something that needs next year's money to finish. So scope it so that a sensible amount of work, a few weeks rather than a few months, produces something your team uses by the end of the first quarter.

That means describing the outcome, not the system. "The Monday report builds itself and arrives by 9 AM" is a scope. "A reporting platform" is a project. Our note on cutting the first version to one job has more on this.

It also means deciding what done looks like before the work starts: who will use it, what they'll stop doing, and how you'll know it worked. If you can't describe that in a paragraph, the fix isn't ready to buy.

Keep ownership in mind too. Whoever builds it, make sure the result lives in accounts you control, with a short note on how it works and who to call when it breaks. A fix that only the builder understands just moves the problem from one person's head to another's.

Ask a few questions before you sign

Year-end spending has its own practical wrinkles, and they're different everywhere, so check before you commit.

Ask your finance team whether paying in December for work delivered in January counts against this year's budget, and what paperwork they need. Some organizations allow prepaid work, some don't, and some need it described a particular way. Ask any vendor or partner whether they can start before the holidays, or whether you're buying a January start. And ask who on your side will be available to answer questions and test the result in early January, because a fix nobody tests doesn't get used.

One more question is worth asking of yourself. If this fix works, what happens next? Sometimes the honest answer is "nothing, and that's the point." Sometimes a small fix shows that a bigger piece of work is worth planning for next year. Either is a good result, as long as you decided it on purpose.

If the honest answer to all of that is "nobody until February," it's fine to let the money go. That's better than buying something that turns into next year's problem.

Put this into practice

This week, ask three people who do repetitive work: "What do you do every week that you wish the software did for you?" Write down the answers. Pick the one with the clearest outcome and the smallest scope. Describe done in a paragraph. Check the finance rules. Then decide.

With best wishes for a calm January,

The studio at TWIMCO

Small, well-scoped fixes to the tools teams use every day are a big part of our web application development work. If you have a December budget and a Monday chore, talk to us.

Related work: Howcast.