You have been asked to put a number in a spreadsheet. Someone above you wants to know what the software will cost so it can go in a plan, and the honest answer — it depends on what we learn — does not fit in a cell. So the number gets invented, the project is measured against it forever, and everyone spends the next year explaining a variance that was baked in from the start. Budgeting for software done well is not about producing that number. It is about buying certainty in the right order.
Budget for outcomes and phases, not one figure
The single most useful shift is to stop treating the budget as one commitment and start treating it as a sequence. You do not know enough on day one to price the whole thing accurately, and pretending you do just moves the reckoning to later. What you can do is fund the next phase with confidence and hold a rough envelope for the rest. Each phase ends with more knowledge than it started with, so the next estimate is better than the last.
This is not a trick to avoid commitment. It is an honest reflection of how much you actually know at each point. The first phase, discovery, is cheap and its job is to make the second phase estimable. By the time you commit real money to building, you are estimating something you understand, not something you hope to understand. A budget that respects that order costs less to be wrong about.
The parts people forget
Most budgets that blow up did not underestimate the obvious work. They forgot the surrounding work, which is often larger. The visible part is building features. The invisible part — the part that gets left out of the spreadsheet — is where the money actually goes.
Discovery is the first casualty: the time to understand the problem properly before building, which feels like a delay and is actually the cheapest insurance you will buy. Integration is the second: connecting to the systems you already run is rarely as simple as the vendor of those systems implies, and their documentation lies more often than it helps. Then data migration — moving years of real, messy data into the new system, which is almost always harder than building the system that holds it. Then testing, security, and the work of getting something into production safely rather than merely making it run on a laptop. And then the one nobody wants to write down: maintenance. Software is not a thing you buy once. It needs patching, updating, and adapting as the world around it changes, and a budget that ends at launch is a budget that has planned for the software to start rotting on day one.
There is a simple test for whether a budget has faced these costs or hidden from them. Ask what the number assumes about the year after launch. If the answer is nothing — if the plan quietly treats the software as finished the day it ships — then the real cost of ownership has been pushed off the page, and it will land on you later as an unbudgeted surprise dressed up as an emergency. A budget that names its running costs honestly looks larger on paper than one that does not. It is not larger in reality; it is only more truthful about a number you were always going to pay.
Contingency is not padding
Every real software budget needs a contingency, and it should be visible, not hidden. There is a difference between padding an estimate to protect yourself and holding a named reserve for the things you genuinely cannot foresee. The first is dishonest and erodes trust. The second is simply true to the nature of the work: you are building something that has not existed before, and some of what you will learn will cost money to act on.
Hold the contingency openly, agree on what it is for, and decide together how it gets spent. A reserve that everyone can see keeps the conversation honest — when it is used, there is a reason, and when it is not, it comes back. A budget with no contingency is not a tighter budget. It is a budget that will be broken quietly, one unplanned necessity at a time, until it stops meaning anything.
The size of the reserve is itself a signal worth reading. A tiny contingency on a large, novel project is not confidence — it is optimism that has not met reality yet, and it usually means the hard parts were never thought through. A very large one can mean the opposite: that nobody did the work to understand the project well enough to price it, so the uncertainty is being hidden in a cushion instead of reduced through discovery. The right reserve is proportional to how much is genuinely unknown, and it should shrink as you learn. Watch it move across the life of the project — a contingency that never gets smaller is a sign the learning is not happening.
The false economy of the lowest bid
When several quotes land on your desk, the lowest one is exerting a pull, and it is worth understanding what that number usually means. Sometimes it is genuine efficiency. More often it is one of three things: the vendor has not understood the problem and will discover the missing work later at your expense, they have deliberately underbid to win and will make it back on change requests, or they intend to cut exactly the invisible work — the testing, the security, the migration — that you were not watching for.
A low bid is not a saving if it buys you a system that fails in production, leaks data, or has to be rebuilt in two years. The relevant comparison is never the quoted number against another quoted number. It is the total cost of ownership — build, run, maintain, and eventually replace — and on that measure the cheapest quote is frequently the most expensive choice. Ask a suspiciously low bidder what they have assumed. The answer tells you more than the number does.
Fund a first phase to buy certainty
If there is one technique that changes the economics of a software budget, it is this: pay for a small, bounded first phase before you commit to the whole. A discovery or a proof-of-concept phase is cheap relative to the project, and what it buys is not code — it is a far more accurate estimate of everything that follows. You spend a little to know a lot, and then you decide whether to commit the rest with your eyes open.
This inverts the usual risk. Instead of committing a large budget to a vendor you have not worked with, against a plan neither of you fully understands yet, you commit a small budget to answer the expensive questions first. If the first phase goes well, you proceed with confidence and a better number. If it goes badly, you have learned that cheaply, before it became a crisis. The cost of the first phase is not overhead — it is the price of not being surprised later.
A first phase buys you something beyond a better estimate: it lets you test the partner, not just the plan. You learn how they estimate, whether they hit what they said they would, how they behave when something turns out harder than expected, and whether they tell you bad news early or let it accumulate. Those things predict the rest of the project far better than any proposal document, and you get to read them while the amount at stake is still small. Committing the whole budget before you have watched a team deliver anything is the single most common way a well-run company ends up locked into a partner it would not choose again.
Treat ranges as illustrative, always
You will want a number anyway, and there is a responsible way to give one. A range is fine as long as everyone understands it is illustrative — a way to check whether you are in the right order of magnitude, not a commitment. A simple internal tool might sit in one band; a system that touches money, or personal data, or many integrations, sits in a much higher one, and the difference between them is not detail, it is category. The mistake is to take an early range, strip off the caveats, and turn it into a fixed expectation. That is how a perfectly reasonable estimate becomes a broken promise.
Use ranges to plan and to sanity-check, never to commit. The commitment comes phase by phase, once you know enough for the number to mean something. A budget is not a prediction you are graded against. It is a plan for spending money in the order that keeps you safest — and the safest order is always to buy knowledge before you buy scale.
What good budgeting actually feels like
Done right, budgeting for software feels less like guessing a total and more like managing a series of small, informed decisions. You fund discovery. Discovery gives you a real scope and a better estimate. You fund the first build phase. That phase ships something you can see, and it sharpens every number after it. At each step you know what you are spending and why, you hold a visible reserve for surprises, and you retain the right to stop if the value is not there.
That is not a loss of control — it is the only real control there is. The alternative, a single number committed on the day you knew the least, feels like certainty and delivers the opposite. Budget for outcomes, fund in phases, name your contingency, and never confuse the lowest bid with the lowest cost. Do that, and the budget stops being a source of anxiety you defend and becomes a tool you steer with — which is exactly what it was supposed to be all along.