When you're comparing proposals for a new business application, it's natural to focus on the number at the bottom of each quote. A smaller figure means less risk, right? Not always. The build cost is only the part of the iceberg you can see. Everything below the waterline – ongoing hosting, security patches, bug fixes, updates and the cost of getting someone else to work on code they've never seen – can dwarf the original invoice within a few years.
This isn't a reason to distrust developers who offer competitive prices. Many talented, professional developers work lean and price fairly. But 'cheap to build' and 'cheap to own' are two different things, and confusing them is one of the most common and costly mistakes a business owner can make when commissioning software.
The build cost is only the part you can see. The real cost of a poorly documented, hard-to-change application reveals itself slowly – one small request at a time.
Why the cheapest quote isn't automatically the best value
A low quote can reflect several very different things. The developer may genuinely be efficient, experienced and confident in their process. Or the quote may be low because corners are being cut: in testing, in documentation, in the choice of tools, or in how carefully the code is structured for future change.
The problem is that both scenarios look identical at proposal stage. Nothing in that document tells you whether the resulting application will be clean, well-commented code that another developer could pick up in a day – or a tangled, undocumented system that only its original author fully understands.
This is sometimes called the 'bus factor': how many people in your supply chain need to be unavailable before your application grinds to a halt? If the answer is one – specifically, the one freelancer who built it at the lowest price – you have a risk that isn't priced into any quote.
The hidden costs beneath the build
Most business owners focus on the build cost because it's visible and comparable across proposals. The ongoing costs are vaguer and easier to underestimate. Here's what typically accumulates after launch:
- Hosting and infrastructure. Even a simple application needs a server, a domain, an SSL certificate and backups. These costs are modest individually but recur every month and can escalate if usage grows.
- Security patches and dependency updates. Software doesn't stand still. The frameworks your application was built on release updates, and some of those updates are security-critical. If nobody is maintaining your application, you may be running known vulnerabilities within months of launch.
- Bug fixes and edge cases. No application ships without defects. Some will be caught in testing; others emerge when real users interact with the system in unexpected ways. The cost of fixing them depends heavily on how well the code is structured.
- Change requests. This is where poor initial builds become genuinely expensive. When your business evolves – and it will – you'll need the application to evolve with it. A well-structured application makes changes straightforward; a poorly structured one turns every small modification into a substantial project.
- Handover and continuity. If your original developer becomes unavailable, a new developer will need to understand the existing system before they can work on it. With good documentation, that might take a day. Without it, it could take weeks – and you pay for every hour.
Why code ownership and documentation matter
Documentation is often treated as an optional extra – something to produce if there's budget left over at the end. In practice, it's a fundamental part of what you're buying.
When you commission software, you should receive not just a working application but the means to understand and maintain it. That means source code stored in a version-controlled repository that you have access to – not a zip file on a file-sharing service. It means a README that explains how the application is deployed. It means comments in the code that explain why particular decisions were made.
If you can't access your own codebase, you don't own your application – you're renting it.
Version control is the most important of these. A repository service such as GitHub or GitLab gives you a complete record of every change ever made to your application, makes it straightforward for a second developer to review the work, and enables rollback if something goes wrong after a deployment. Without it, you're buying access to software on terms that may not suit you when circumstances change.
Questions to ask before accepting a proposal
You don't need to be technical to ask the right questions. What you need is clarity on the things that will affect your costs and your control after launch:
- Where will the source code be stored, and who owns the repository? It should be in an account you control – not the developer's personal account.
- What documentation will be delivered at the end of the project? A responsible developer will include this as a deliverable, not an afterthought.
- What are the estimated annual running costs? Hosting, backups, security updates and monitoring should all be quantified, even roughly.
- Who else could work on this codebase if you were unavailable? A confident professional won't be defensive about this. They'll be able to point to documentation or colleagues that would make handover manageable.
- What's your process for testing? A very low quote may indicate testing has been minimised – meaning you'll encounter in production the bugs a more thorough process would have caught.
How to think in total cost of ownership
Total cost of ownership (TCO) is the discipline of looking at the full lifecycle cost of an asset, not just its purchase price. It's standard thinking in operations and capital equipment – but it's applied far less consistently to software, where the headline build cost is salient and the long-term costs feel abstract until they arrive on an invoice.
A simple way to apply TCO thinking is to project costs across three years. Start with the build cost, then add estimated annual hosting, a maintenance allowance expressed in hours at a typical day rate, and a rough figure for changes you know you'll want as the business evolves. Compare proposals on that basis, not the headline figure alone.
Three years of hosting, fixes and change requests will often cost more than the original build. Model the whole picture before you decide.
If you're struggling to get estimates for ongoing costs, that's useful information in itself. A developer who can't give you a rough hosting figure, or who deflects questions about maintenance, is implicitly telling you that these things aren't part of how they think about their work.
Practical steps before you sign
- Ask for a three-year cost model. Request that each proposal include estimated annual running costs so you can compare total cost of ownership, not just the build price.
- Specify repository ownership in writing. Include in the contract that source code will be stored in a repository under your control from day one, not transferred at the end.
- Name documentation as a deliverable. A brief technical handover document – architecture overview, deployment steps, third-party dependencies – should be a contractual output alongside the application itself.
- Ask what happens six months after launch. A thoughtful, specific response suggests long-term thinking. Vagueness or impatience suggests the opposite.
- Test continuity as a scenario. Ask: 'If you were unavailable for three months, what would we need to do?' The honest answer tells you more about actual risk than any figure in the proposal.
Choosing on value, not price
None of this means you should always choose the most expensive proposal. Plenty of skilled developers work at competitive rates and deliver well-structured, well-documented code. The point is that price alone is not a reliable guide to value – and the gap between the two reveals itself slowly, one small request at a time.
The questions above don't require technical knowledge. They require the same commercial instinct you'd apply to any supplier relationship: what am I actually buying, what does it cost to run, and what happens if circumstances change? Start now – ask your current or prospective developer what happens six months after launch when you need a change. Their answer will tell you almost everything you need to know.
