Budgeting for Internal Tools: Licences, Build Time and the Costs After Launch

The budget line said “platform licence: 40 seats”. Eight months later, the finance lead is asking why the tool has quietly cost three times that, and nobody can point to a single invoice that explains it. The licence was never the expensive part. It was just the only part anyone wrote down.

This post is about building the budget itself: the line items, the year-one versus year-two shape, and the reserve you will need for changes. If you are still working out what the spreadsheet costs you today, start with The Hidden Cost of “It’s Just a Spreadsheet”. If you need to win approval, Getting Buy-In: Pitching an Internal Tool to Leadership covers the pitch. Here we assume you have the green light and need a number you will not regret.

The five buckets

Every internal tool budget, whether you buy, configure or build, fits into five buckets. Most teams estimate the first and guess at the second. The other three tend to show up later as surprises.

1. Licences and hosting. Seats, usage tiers, add-ons, storage, and any connectors to your CRM or accounting software that cost extra.
2. Build time. Hours spent designing the data, configuring views and forms, writing automations and testing. Internal hours count even if no invoice arrives.
3. Migration. Cleaning the old data, mapping fields, running old and new in parallel, and the cutover itself.
4. Rollout. Training sessions, written guides, office hours, and the productivity dip while people learn.
5. Running costs. Ongoing administration, fixes, change requests, integration upkeep and annual price increases.

A useful habit: put a number in every bucket, even a rough one. A zero is a decision, and you should make it on purpose.

Pricing the hours honestly

The biggest budget errors come from treating staff time as free. Say your operations analyst spends 120 hours configuring the tool over two months. At a loaded cost of, say, 60 per hour, that is 7,200 of real money, plus whatever the analyst normally does that is not getting done.

Estimate build time per piece, not as a single lump. A rough worksheet for a mid-sized process might look like this:

Then add a contingency of 30 to 50 percent. Not because you are bad at estimating, but because every process has edge cases that only appear once real records go in. Exception Handling: Designing for the Cases That Don’t Fit explains where those hours tend to go.

Year one is not year two

Year one is front-loaded: build, migration and rollout dominate. Year two looks quieter, which is exactly when budgets get cut and tools start to decay.

Here is an illustrative shape for a tool used by 40 people:

Notice that running costs more than double in year two. That is normal. Once people trust the tool, they ask for more from it: a new report, a second team onboarded, an approval step for a policy change. Licences also tend to creep up, both from price increases and from headcount growth.

If your year-two number is just the licence fee, the tool will stop improving the day the project team disbands.

Budgeting for change requests

Change requests deserve their own line because they are the cost most likely to be ignored and most likely to determine whether the tool survives.

A simple approach is a reserve expressed as hours per month. For example, set aside eight hours a month of a named person’s time for small changes, and agree that anything bigger goes through a proper request with its own estimate. This turns “can you just add a field?” from an untracked favour into a visible draw on a known allowance.

Track the reserve. If you burn through it every month, either the tool is genuinely growing in value or the original design missed something. Both are worth knowing, and Who Maintains the Tool? Assigning Ownership After Launch covers how to run the backlog that feeds it.

The quiet costs to check for

A few items routinely slip through. Run down this list before you finalise the figures:

• Integration upkeep. Connected systems change. Someone has to fix the sync when your CRM renames a field.
• Tier jumps. Usage-based pricing can step up sharply when you pass a record or automation limit. Check where your limits are and how close you will be in eighteen months.
• Occasional users. People who need access twice a month can inflate seat counts. Per-Seat Pricing and the Occasional User Problem has strategies.
• Admin time. Adding and removing users, adjusting permissions, answering “how do I” questions. Even an hour a week adds up to over fifty hours a year.
• Exit costs. Exporting and migrating out one day is real work. You do not need to fund it now, but you should know roughly what it is. Backups, Exports and Exit Plans has more.
• Parallel running. Paying for the new tool while people still maintain the old sheet is a cost, and the longer it lasts the more it costs.

Presenting the budget so it survives review

Finance teams are rarely upset by a large number. They are upset by a number that changes. A budget that shows all five buckets, with assumptions written next to each figure, survives scrutiny far better than a single tidy licence line that later triples.

Write the assumptions plainly: “40 users, growing to 50 by month 18”, “loaded rate 60 per hour”, “8 hours a month change reserve”. When reality differs, you can update the assumption rather than defend the whole budget.

It also helps to set a review point. Agree now that you will compare actuals to estimates at six months, when the post-launch review happens, and adjust year two accordingly.

Where to start this week

• Open a blank sheet (yes, really, budgeting is analysis, not process) and create the five buckets with a number in each, even if it is a guess.
• Break build time into the pieces listed above and add a 30 percent contingency.
• Check your chosen platform’s pricing tiers and note the next limit you are likely to hit.
• Name the person whose time will cover change requests, and agree a monthly hour allowance with their manager.