A company builds a small internal tool to manage orders. The build is paid for and everyone is pleased. Eight months later the hosting plan needs an upgrade, a library needs a security update, and the sales manager asks for a new report. Nobody planned for any of it, so each item becomes a small argument about who pays.
This article is for the owner of a small internal tool, or the person who pays for it. It describes a yearly budget with three lines, shows how to fill them in, and ends with a routine that takes about an hour.
Why the build is not the whole cost
A tool that is used stays in contact with a changing world: staff change, suppliers change file formats, browsers and server software are updated, and the business asks for new things. Software that is not looked after does not stay the same; it slowly stops fitting.
Budgeting only for the build means these costs arrive as surprises. Budgeting for them in advance makes them ordinary.
The three lines
1. Running cost
Everything that is paid or done regularly to keep the tool working, whether or not anything changes:
- hosting and database,
- domain, certificates, email sending and other services the tool depends on,
- licences for any components or tools,
- backups, and a check once or twice a year that a backup can actually be restored,
- monitoring and a person who looks at the alerts,
- routine security and dependency updates.
Most of this is predictable. Collect the invoices from the last twelve months and the numbers are mostly there. For work done by a person, estimate the hours per month and multiply.
2. Planned changes
Improvements you already know you want: a new report, a second approval step, an import from another system. List them, give each a rough size (small, medium, large), and decide which ones the year can afford. A short list of named changes is better than a vague amount "for development", because it forces a priority decision.
3. Reserve
Money for what you cannot name yet: an urgent fix, a supplier who changes a file format, a request from a new manager. As a rough starting point, many teams hold back somewhere between a tenth and a fifth of the yearly total. A tool that changes often needs more; a stable one needs less. Adjust after the first year, when you can see what was actually used.
The reserve is not a hidden slush fund. When it is spent, note on what, so next year's number is based on evidence.
A worked example
This example uses invented numbers for a small ordering tool. Replace them with your own.
Running cost: hosting and database 1,200; email service 150; domain and certificate 60; monitoring and routine updates, 3 hours a month at 70 per hour, 2,520. Subtotal: 3,930.
Planned changes: monthly sales report (small) 1,400; manager approval above a limit (medium) 3,500. Subtotal: 4,900.
Reserve: 15% of the subtotals, 1,325.
Yearly total: 10,155.
Two things are worth noticing. The running cost is less than half of the total, but it is the part that cannot be skipped. And the planned changes are specific enough that someone can say "not this year" to one of them, which is exactly the decision a budget is for.
Who owns the budget
One named person should approve spending and decide priorities. Without that, requests come from five people and the developer is left to choose. The owner does not need technical knowledge, but needs to understand what each line buys.
Agree also what happens when the reserve runs out mid-year: either the owner approves more, or the lowest-priority planned change moves to next year.
Common mistakes
- No budget after launch. Every fix becomes a negotiation.
- Counting only the invoices. Time spent by your own staff on the tool is a cost too.
- A reserve that is spent on wishes. Planned changes belong in line two.
- No restore test for backups. A backup that has never been restored is only a hope.
- Never reviewing. A budget copied from last year drifts away from reality.
A one-hour routine
- Collect last year's invoices and note the hours spent on the tool.
- Fill in the running cost line.
- List wanted changes, size them roughly and choose what fits.
- Set the reserve and write down your reasoning.
- Name the owner and the rule for when the reserve runs out.
- Put a review in the calendar for the same month next year.
For thinking about the cost of a larger build before it starts, see the real cost of custom software, and for what neglected maintenance does over time, see the hidden cost of technical debt. A short budget will not remove surprises, but it will turn most of them into decisions made calmly.
Sources
- Practical guidance based on common small software project practice, offered as a planning aid. The categories, percentages and example amounts are illustrations to adapt to your own tool. The opening scenario and the worked example are invented. No client results or performance figures are claimed in this article.