The number on a build quote is almost always the smallest cost you will pay for custom software. If a supplier tells you a system costs sixty thousand to build, the honest way to read that is: the first version costs sixty thousand, and then you own it for the next five to ten years. Ownership is where the real money goes. I have watched businesses celebrate coming in under budget on a build, then quietly spend the same amount again over the following two years keeping the thing alive. That is not a failure of estimation. It is a failure to understand what custom software actually is.
Why the build is the cheap part
Software is not a purchase. It is a living asset that decays the moment it ships. Browsers update, dependencies release security patches, the payment provider changes its API, an operating system deprecates something you relied on. None of that is optional maintenance you can defer forever. It is the cost of the software continuing to exist. A rough working assumption I give clients is that annual maintenance and support runs somewhere between fifteen and twenty-five per cent of the original build cost, every year, and that is before you add a single new feature.
Then there is the cost of change, which is the whole reason you built custom software in the first place. You built it because your business is not standard. But a business that is not standard keeps changing, and every change is a small development project. If the software cannot flex with you, you have bought an expensive photograph of how you worked on launch day.
The total cost of ownership nobody quotes
When I help someone budget for a custom system, I make them write down every line below, because suppliers rarely volunteer them:
- Hosting and infrastructure. Servers, databases, storage, backups, a staging environment, monitoring. Modest for a small tool, meaningful at scale, and it never goes to zero.
- Maintenance. Dependency upgrades, security patches, fixing the things that break when the outside world changes underneath you.
- Support. Someone has to answer when it breaks at nine on a Monday. That is either a retainer with your supplier or a person on your payroll.
- The team to run it. This is the cost people forget entirely. Software creates operational work. Someone administers it, onboards users, manages permissions, runs reports, chases the edge cases. That is often a fraction of a salary, sometimes a whole one.
- Change and enhancement. The backlog that starts forming the day after launch.
Add those up over five years and the build quote frequently turns out to be a quarter or less of the true cost. That is not a reason to avoid custom software. It is a reason to go in with your eyes open, because a system that delivers real value is worth every line of that ownership cost. A system built on a whim is a five-year liability.
The most expensive mistake is architectural, and it happens early
The single costliest error in custom software is getting the architecture wrong in the first few weeks, when nobody is watching and everything still feels cheap to change. Early decisions about how data is structured, how systems talk to each other, and where the boundaries sit are the ones that compound. A poor choice made on day three is nearly free to fix on day three and can cost more than the original build to fix in year two, because by then real data, real users, and real workarounds are all wrapped around the mistake.
The cost of a bad architectural decision does not stay the same. It grows quietly until the day it becomes the reason a simple change takes three months.
This is why I am suspicious of quotes that skip straight to building. The cheapest insurance you can buy on a custom project is spending real, senior time on the architecture and the domain before anyone writes production code. It looks like the slow, expensive part. It is the opposite. Our custom software development work front-loads that thinking deliberately, and the methodology you choose shapes how forgiving the system is to later change.
Sometimes the honest answer is do not build
I have talked clients out of building software more than once, and I will keep doing it, because a consultancy that only ever recommends building is not giving advice, it is selling. The build-versus-buy question is fundamentally a cost question, and the maths is not complicated.
If there is a mature off-the-shelf product that does eighty per cent of what you need, the honest comparison is not features, it is total cost of ownership. That product spreads its maintenance, hosting, security, and support cost across thousands of customers. You would be carrying all of it alone. For a genuinely common problem, the vendor's price is almost always lower than your true ownership cost, and their software will be more robust because it has been battered by thousands of users you will never have.
Custom software earns its keep in a narrow band: when the thing you do is a real competitive differentiator, when no product fits without contorting your business to match it, or when integrating a patchwork of tools would cost more than building the right thing once. Outside that band, buying is usually the disciplined choice. The trap is emotional. People want the bespoke thing because it feels like theirs. Ownership pride is not a line item, but it quietly drives a lot of six-figure decisions.
How to think about it before you commit
Before signing anything, I would ask three questions. First, what is the five-year cost, not the build cost, and can the business carry it even in a bad year. Second, if this software disappeared tomorrow, would the business genuinely be worse off, or would it merely be inconvenient. Third, who owns this after launch, named individuals, not a vague intention to sort it out later. If you cannot answer all three, you are not ready to build, and that is a useful thing to discover before the money is spent rather than after.
Custom software is one of the highest-leverage investments a business can make, and one of the easiest to get quietly, expensively wrong. The difference is almost never the build. It is whether you understood what you were signing up to own. If you want a straight answer about whether your idea justifies the ownership cost, that is exactly the conversation to have in a free consultation before you commit a budget.