The build quote is the number that gets scrutinised, negotiated and approved. It is also the smaller number, and it covers the shortest part of the software's life.
A bespoke application that is genuinely useful will run for five to ten years. What happens across that period costs more in total than what happened before it went live, and it appears in a business case far less often. Getting it into the business case is the single most useful thing you can do to make the decision to build a sound one.
Keeping it running
Software needs somewhere to run, and that somewhere needs backups, monitoring, TLS certificates, and someone whose job it is to notice when it stops. For a modest internal application this is a small monthly figure. It is rarely zero, it never goes away, and it grows with usage rather than with features.
The part that surprises people is the attention rather than the hosting bill. Somebody has to respond when the alert fires at four in the afternoon on a Friday, and the arrangement for that is a cost whether it is a retainer, an internal rota, or an informal understanding that a particular person will pick it up.
Keeping it current
Every library the application depends on has its own release schedule and its own security advisories. Ignore them and the upgrade debt compounds: after two years the jump is large enough to need a project, and the project is unbudgeted because nothing appeared to be wrong.
The cheaper pattern is small and regular. A few hours a month keeping dependencies close to current, applying security patches as they land, and running the test suite afterwards. It feels like spending money on nothing, which is why it gets cut, and cutting it is how software turns into a commercial liability rather than an asset.
Runtime versions matter more than libraries here. A language runtime reaching end of life gives you a hard deadline set by somebody else, and meeting it is a project whether or not you had planned one.
Keeping it understood
This is the cost that never appears in a spreadsheet and does the most damage.
Bespoke software encodes decisions, and most of those decisions are not written down anywhere. Why the discount is calculated before tax for one customer group. Why that overnight job runs at 03:40 rather than 03:00. Why a field that looks unused cannot be removed. The people who know are the people who were there, and they eventually leave.
What follows is a period where every change takes three times as long because someone is reverse-engineering intent from code. The mitigation is unglamorous: decisions recorded as they are made, a test suite that documents expected behaviour, and more than one person who has worked on it. None of that is free, and all of it is cheaper than the alternative.
Change is the largest line
The application will not be finished. The business will reorganise, a customer will need something specific, a supplier will change a file format, a regulation will move. Each change is small and reasonable, and in aggregate they are the biggest ongoing cost by a wide margin.
This is worth planning for as a standing capacity rather than a series of surprises. An agreed number of days a month, with a queue the business prioritises, produces better outcomes than an emergency conversation every time something needs to move.
A figure to plan with
As a planning assumption, expect annual ownership to cost somewhere between a fifth and a third of the original build, every year, for as long as the software is in use. Simple applications with few integrations sit at the lower end; anything connected to several other systems sits at the higher end, because every one of those connections can change without asking you.
Over five years that means total cost of ownership lands somewhere near double the build quote. If the business case only survives at the build quote, it does not survive.
What this should change about scope
The useful consequence of counting properly is that it makes you build less.
Every feature is a permanent commitment: it has to be hosted, patched, understood, tested and changed for as long as the software exists. Features that were nice to have at the point of specification become obligations that outlive the person who requested them. Cutting the initial scope to what genuinely removes the measured cost is the only reliable way to keep ownership affordable, which is the same reasoning behind deciding whether to build at all.
The related question is who is responsible for all of this once the build team has gone, which is covered in owning what someone else built for you. To talk through a build and what it will cost to keep, see custom software development.
