What keeping a custom tool alive costs after launch
The real running cost of custom software after the build invoice is paid, which businesses should not commission one and the handover to insist on.
The invoice is settled and the obligation starts
Custom software gets budgeted like a purchase and behaves like a vehicle. The build has a price and a delivery date. After that it needs fuel, servicing and someone who knows how to open the bonnet, and none of those appear in the project proposal.
This is not poor workmanship. A working tool sits on hosting that gets patched, libraries that publish security fixes, browsers that change, payment and messaging services that retire old interfaces, and a business whose process shifts. A tool nobody touches for two years does not stay still. It quietly stops working.
What the build fee excludes
Read the proposal for what it leaves out. The build fee normally excludes hosting, backups, monitoring, third party service charges, library and platform upgrades, bug fixes beyond a short warranty window, any change of feature and any guarantee that the developer is available next year.
The recurring bill has a predictable shape. Hosting and storage, domain and certificate renewals, charges from any external service the tool calls such as messaging or payments or maps, and either a maintenance retainer or an hourly rate you hope to need rarely. GST at 18% applies on service fees. Many contracts set annual maintenance as a percentage of the build fee, so ask for that percentage in writing before signing rather than discovering it at the first renewal.
A custom corporate website is the most common custom build a small business commissions and the same pattern applies to it. Scope and rates for custom corporate website development are published on the service page. The build is the purchase in every case. The upkeep is a separate and continuing commitment.
Who should not commission custom software
If you cannot fund the second year then do not build the first. A business that can raise a one time capital amount but has no room for an annual maintenance line is buying an asset that will decay into a liability. Subscription software is the honest alternative because the upkeep is inside the price.
Do not build custom where your process changes every few months. Custom tools encode decisions. A business still experimenting with how it quotes or fulfils will spend more on changes than on the original build and will resent the tool for being rigid.
Do not build if you cannot name the person responsible in year two. Not the agency. The person inside your business who holds the credentials, approves changes and notices when something breaks. Without that name the tool has no owner and an unowned system is the most expensive kind.
Custom earns its place when the process is settled, central to how you make money and not served by any product on the market.
How the costs actually arrive
They arrive in lumps rather than evenly. The warranty window closes and small fixes become chargeable. A few months later a library you depend on publishes a security advisory and the upgrade touches code nobody has opened since launch. A payment or messaging provider retires an old interface and gives a deadline.
Then the human event. The developer who built it moves on. A new developer has to read unfamiliar code before changing a line and that reading time is billable at the same rate as building something new. This single factor explains most cost blowouts in small business software.
The defence is a handover taken at launch rather than requested in a crisis. Source code in a repository you own. Every credential in your own accounts. Written deployment steps someone else could follow. A list of external services with renewal dates. Insist on these while the final payment is still outstanding because that is the only moment you have leverage.
The figure that keeps it honest
Calculate the all-in monthly cost per active user. Add hosting, external services, the maintenance retainer and any tax, then divide by the number of people who actually used the tool last month. Compare that against the subscription product you rejected. Many custom tools look expensive on that measure after two years.
The flattering position is that the tool is paid for. The build is paid for. The tool is not. Treating sunk build cost as a reason to keep running something few people use is how businesses carry dead software for years.
The mistake that forces a rebuild
The expensive error is launching with no maintenance budget and no handover. Nothing visible happens for a year. Then something breaks urgently, the original developer is unavailable or no longer interested at the old rate, and nobody can locate the credentials or the current code. At that point a rebuild is often genuinely cheaper than recovery, which means paying twice for the same tool.
The quieter version is skipping updates to save money. Deferred upgrades compound. Three years of skipped versions turn a routine patch into a migration project and the quote for that arrives at the worst possible moment.
Decide the retirement date too
Give the tool an expected life when you commission it. Three years or five. At that point you review whether to invest again or to move to a product that has caught up with your requirement, because the market usually has.
Having that date written down changes the conversation from loyalty to arithmetic.
This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.