Budgeting for bespoke software: what a small business should set aside, and when

Most advice about the cost of custom software answers a different question from the one a small business owner is actually asking. You do not only want to know what it costs. You want to know what to put in the budget, which year it lands in, when the invoices arrive, and whether the business can carry it without a difficult month.

That is a finance question, not a price question, and it is the one that decides whether a project happens.

Get the price range out of the way first

The number itself is the easy part, and we publish it rather than making anyone ask. Most bespoke business software for a UK SME lands between £15,000 and £60,000, and the bespoke software cost page sets out what drives a project up and down that range, how the pricing models differ, and how to read a quote you have been given by anybody. The three bands we quote in, and what moves a project between them, are on the bespoke software development page.

Take a working figure from those, then stop thinking about it as a single price. For budgeting purposes it is never one number.

Budget three numbers, not one

The build. The one-off cost of getting the system designed, built, migrated and live. This is the figure everyone quotes and the only one most businesses plan for.

Running it. Hosting, monitoring, backups and a support arrangement, every month, for as long as you use the system. It is not large next to the build, but it is permanent, and it belongs in the operating budget rather than being paid out of goodwill.

Changing it. The number almost nobody sets aside. A system people use every day generates ideas: a new report, an extra field, a process that changed when you took on a different type of customer. If there is no budget line for change, every improvement becomes an argument, and the software slowly drifts out of step with the business until someone starts keeping a spreadsheet alongside it. Which is, of course, where you came in.

A reasonable habit is to treat the build as a project cost and the other two as a standing annual line, agreed before you sign anything. If a supplier has not given you figures for all three, ask, because the answer tells you whether they have thought past handover.

When the money actually leaves the bank

Cash flow, not total cost, is what kills SME software projects. The total is usually affordable. The problem is a large payment landing in the same month as the VAT bill.

Bespoke work is normally invoiced in stages tied to progress rather than as one payment at the end. A common shape is a deposit to start, one or more payments against agreed milestones, and a balance on go-live. Since most SME projects run over a matter of months rather than weeks — our guide to how long bespoke software takes sets out realistic timescales — that spend is spread across a quarter or two, not concentrated in one week.

Two things worth doing before you commit. Write the expected payment dates into your own cash flow forecast, not just the total. And ask the supplier to confirm the schedule in writing, including what happens to the timetable if your side is slow to review something, because that is the most common cause of a project stretching and it changes when the invoices arrive.

Phase it so the first part pays for the next

The single most useful budgeting technique in software is refusing to buy all of it at once.

Almost every system has one process at its centre that carries most of the pain. The quotes that take three days to produce. The stock figure nobody trusts. The job sheets typed in twice. Build that first, get it live, and let it start saving time while the rest is still a plan.

Phasing does three things for the budget. It moves a smaller number into this financial year and pushes the rest into the next. It means the second phase is specified by people who have used the first one, which reliably produces a better and often cheaper brief. And it gives you a genuine exit: if the first phase does not deliver what you hoped, you stop, having spent a fraction of the total.

The trade-off is honest. Phasing usually costs a little more in aggregate than building everything in one pass, because there is a small amount of rework at each boundary. For most small businesses that premium buys real risk reduction and is worth paying.

The costs that sit on your side of the line

A quote covers the supplier's work. These are the costs that fall to you, and they are the ones that get missed.

Your people's time. Someone from your business has to be available for workshops, decisions and testing. Not full time, but not nothing either, and it is usually your most capable person, whose time is not free.

Cleaning your data. Migration is priced on the assumption that your data can be understood. Fifteen years of a spreadsheet where the same customer appears four ways costs money to untangle, and some of that untangling only you can do because only you know which record is right. Starting early is the cheapest version of this.

Running two systems for a while. Sensible go-lives overlap with the old way of working for a short period. That double running is a real cost in hours, and it is worth it.

Training and the dip. Productivity drops slightly for a fortnight after launch while people learn. Plan around it rather than scheduling go-live for your busiest week.

Capital or revenue: worth one conversation

How the spend is treated in your accounts, and what tax relief may be available, depends on the nature of the work and your circumstances. Some software spend is treated as capital, some as revenue, and the treatment affects the timing of the benefit. HMRC's guidance on capital allowances is the starting point, but this is genuinely a question for your accountant, and a ten minute call before you commit is worth more than anything a software supplier tells you about tax.

How to tell your budget is realistic

Three checks, in order.

1. Does the figure include the running and change lines, for three years? If not, you have budgeted for a purchase rather than a system.
2. Have you costed the current way of working, honestly? Hours a week lost to admin, re-keying and correcting errors, at what those people are paid. If the build does not pay that back inside a small number of years, keep your money.
3. Could you stop after the first phase and still be better off? If the answer is no, the phases are drawn in the wrong place.

None of this requires a finance function. It requires deciding the numbers before a supplier gives you one, so that a quote is something you judge rather than something that sets your expectations.

If you would like help with the first half of that arithmetic, the free process audit is sixty minutes, usually on site, mapping what actually happens and where the hours go. You will get a straight answer at the end of it, including "this will not pay for itself" where that is the right one. Get in touch if that would be useful.