Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. How to Budget a Software Project Without Being Surprised
Hiring & Budgets

How to Budget a Software Project Without Being Surprised

What to include beyond the build price, how much contingency is realistic, and the costs that appear after launch.

Updated 2 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

Budget the build, then add 15–25% contingency, then add annual running costs of 15–25% of build for maintenance plus infrastructure and licences. A £40,000 build is realistically a £48,000 first year and £10,000–£15,000 a year thereafter.

The build price is roughly two thirds of year one

Most budget overruns are not overruns at all. They are costs that were always going to happen and were never in the budget: infrastructure, licences, the change everyone knew was coming, and internal time.

Building the full picture up front makes approval easier, not harder, because nobody has to come back for more three months in.

What belongs in a first-year budget

LineTypicalNotes
BuildThe quoted priceUsually the only line people include
Contingency15–25% of buildFor changes you will want, not for supplier error
Infrastructure£50–£500/monthHosting, storage, monitoring
Third-party servicesVariesAPIs, licences, per-transaction fees
Internal timeDays to weeksSpecification, testing, training — real cost
Maintenance after launch15–25% of build annuallyStarts sooner than expected
Training and rollout£1,000–£5,000Documentation, sessions, the first weeks of support

Contingency is for changes, not for errors

Contingency does not exist because your supplier will get it wrong. It exists because you will see the software and want something different, and you should — that is what seeing working software is for.

Budget the change you know is coming. Every project has a moment in week six where someone says “now I see it, we actually need…” A project with no contingency has to say no to that, which is how good ideas get lost.

The costs that appear after launch

  • Bug fixes beyond the warranty period
  • Changes as the business changes — which is a sign of success, not failure
  • Dependency and security updates, which are not optional
  • Support for users, whoever ends up doing it
  • Integration repairs when a third party changes their API

A business that budgets nothing for these ends up with software that degrades and eventually needs replacing early. The maintenance line is cheaper than the replacement.

Phasing beats a single large commitment

Splitting a £60,000 project into a £25,000 phase one and a £35,000 phase two is usually better in every respect. You get value sooner, phase two is scoped with real knowledge, and you can stop if phase one disappoints.

It occasionally costs slightly more in total. That premium buys a genuine option to change course, which is worth considerably more than the difference on most projects.

How to present it internally

Show three years, not one. Software compared over one year against an alternative that recurs annually always looks worse than it is.

Include the do-nothing cost — the current process, the errors, the missed capacity. A budget paper without that line is asking for an expenditure without showing what it replaces.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

How much contingency is enough?

15% for a well-specified project after discovery, 25% where scope is less certain. If you feel you need 50%, the project is not ready to be quoted and a discovery phase would be cheaper than the risk.

Should we budget for a rewrite eventually?

Not a rewrite, but do budget for continuous maintenance, which is what prevents one. Software that is maintained can run for a decade; software that is not needs replacing in three or four years.

What if we cannot afford the maintenance?

Then reconsider the build. Unmaintained software becomes a liability — security exposure, breaking integrations and nobody who understands it. It is better to build something smaller you can sustain.

How do we handle currency and payment terms with overseas suppliers?

Agree the currency, who bears exchange risk, and payment timing in writing. On longer projects, currency movement can be a meaningful share of the difference between suppliers.

Keep reading

More on Hiring & Budgets

Start here

Preparing a budget paper for a build?

We will give you the full first-year and three-year picture rather than just our fee, including the lines that are not paid to us.

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →