I've been involved in software projects where the original estimate bore little resemblance to the final cost, and the pattern of what gets underestimated is consistent enough to be predictable.
Custom software costs more than quoted. This is not a generalisation — it is a documented pattern across the industry, consistent enough to be treated as a planning assumption rather than a risk. The visible cost estimate covers development time. The hidden costs cover everything else, and they add up to a figure that routinely surprises teams who did not account for them.
Maintenance
The most significant hidden cost in custom software is ongoing maintenance. A system that works correctly on launch day requires continuous investment to keep working correctly as the environment around it changes: dependencies update and introduce breaking changes, the codebase surrounding the tool evolves and creates conflicts, infrastructure providers change APIs, browsers update and break frontend behaviour, and security vulnerabilities are discovered in libraries the tool depends on.
Industry estimates for ongoing software maintenance cost range from 15% to 25% of initial development cost per year. A system that cost £80,000 to build requires £12,000 to £20,000 per year in maintenance investment just to remain functional and secure — without adding any new features. Teams that do not budget for this discover it when the system starts breaking and nobody has time to fix it, or when a security audit identifies vulnerabilities in an unmaintained codebase.
Maintenance costs also grow with codebase age. A system maintained consistently over five years costs less to maintain than one that was neglected for two years and then requires emergency remediation. The choice is between consistent maintenance investment and periodic expensive rescue operations.
Time Delays
Software projects run late. This is so consistent across the industry that it has its own name — Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law." The practical planning implication: double the estimated timeline and double the estimated cost as your realistic scenario, not your optimistic one.
The causes of delay are well understood: requirement changes during development, integration complexity that was underestimated, QA revealing issues that require rework, key personnel availability, and the inherent difficulty of estimating software work accurately from a specification rather than from working code.
Each week of delay has a direct cost — the engineers are paid regardless of progress — and an indirect cost in delayed value delivery. A system that was supposed to automate a manual process in three months still requires the manual process for six months when the build runs late. The cost of the continued manual process (additional staff time, error rate, scaling limitation) adds to the total cost of the build decision in a way that rarely appears in the original analysis.
The Build vs Buy Software Calculator allows you to enter a delay factor — a multiplier on the estimated timeline — to model realistic rather than optimistic build costs. Running the comparison at 1.5× and 2× estimated timeline shows the sensitivity of the build economics to delivery risk.
Opportunity Cost
The most underestimated hidden cost of building software is opportunity cost: the value of what the engineering team could have built instead.
Engineering capacity is finite and in most product companies it is the primary constraint on growth. Every month an engineer spends building an internal tool is a month not spent on product improvements that drive customer acquisition, retention, or expansion revenue. The explicit cost of building is captured in salaries. The implicit cost — the product improvements that did not happen — is rarely calculated.
A useful approximation: if your engineering capacity produces, on average, £X of customer value per engineer-month (measurable from historical feature releases and their revenue impact), then building a four-engineer-month internal tool has an opportunity cost of 4 × £X in foregone customer value. For a product team where each engineer-month of product work correlates with £15,000 to £25,000 in LTV across new customers retained or converted, the opportunity cost of a modest build project is a six-figure number.
Commercial software vendors are also investing engineering capacity in the product — but their investment is amortised across hundreds or thousands of customers. The per-customer cost of a commercial vendor's R&D is a fraction of the cost of a single company building the equivalent capability themselves. This is the structural argument for buying wherever the commercial solution is adequate: the vendor has more resources, more focus, and a larger return on that investment than any single customer building for themselves.
The combined effect of underestimated maintenance, time delays, and opportunity cost is why build vs buy analyses that look at only initial development cost consistently understate the true cost of building — typically by a factor of two to four over a five-year horizon.
Related calculator: Use our Burn Rate Calculator to track how quickly development and operating costs consume cash.
What to do next
Use the ideas above as a starting point — then connect them to your own numbers and related guides on Calc It Anything.
- Read the small business finance and growth guide for the wider cluster.
- Compare with Hidden Costs in Small Business: The Expenses Owners Forget.
- Compare with How Small Costs Destroy Profitability.
- Run the relevant calculator on this site with your own inputs before making a decision.
Related reading
- small business finance and growth guide
- Hidden Costs in Small Business: The Expenses Owners Forget
- How Small Costs Destroy Profitability
- Markup vs Margin: The Difference That Trips Up Business Owners
Frequently asked questions
Why do small costs hurt profitable businesses?
Fixed overheads and low-margin revenue mean recurring £50–£200 leaks compound across dozens of line items. Margin looks fine on paper until you aggregate subscriptions, fees, and unused seats.
How often should I review business running costs?
A lightweight quarterly pass on software, payment fees, and contractor spend catches drift early. Tie the review to one metric — gross margin or monthly burn — so it stays actionable.
Is cutting costs always the right response?
No. Cut spend that does not protect revenue or retention first. Protect customer-facing delivery and anything with measurable ROI before across-the-board austerity.