The Quiet Cost of Ownership: Budgeting for Year Two of a UK Software Product

Custom software is often approved as a capital project. The business case focuses on build cost, launch date and the process that will be improved. Year two receives less attention. That is a mistake. The period after launch is when the product starts to age, when security patches arrive and when the small changes that users need begin to accumulate.

For UK businesses, the risk is not usually a dramatic failure. It is a quiet drift: the supplier becomes less responsive, the hosting bill creeps up, a third-party component reaches end of life and nobody owns the roadmap. By the time the issue reaches the board, the product may already be unsupported.

Launch is a capital question; year two is an operating question

The first year often includes a warranty or hypercare period. That can create a false sense of security. Once the warranty ends, the buyer needs an operating model with named responsibilities, service levels and a budget. Without that, maintenance becomes a series of unplanned purchases, each one easy to defer and collectively damaging.

The operating budget should be approved before launch, not after. It is part of the total cost of ownership and should sit alongside the build cost in the business case.

The costs that rarely appear in the business case

Security patching and dependency updates

Every software product depends on frameworks, libraries and services that change. Security patches are not optional, and delaying them creates risk. The work is often small but irregular, which makes it hard to plan without a support arrangement.

Hosting, monitoring and backups

Cloud hosting is usually a monthly cost, but monitoring, logging, backup storage and disaster recovery testing are often omitted. For a UK business handling customer data, backup testing is not a technical nicety. It is part of resilience and, depending on the data, part of regulatory good practice.

Third-party licences and services

Maps, payment providers, email delivery, authentication and analytics may each carry a subscription. Some are cheap at launch and expensive at scale. The business case should identify who owns these accounts and what happens if usage grows.

Compliance and accessibility updates

Regulations and standards change. Accessibility expectations, data protection practice and sector-specific rules can all require product changes. A product that was compliant at launch is not automatically compliant two years later.

Small improvements and user support

Users will find friction that was not visible in testing. A finance team may need a new report; an operations manager may need a different approval step. These requests are often too small for a project but too important to ignore. Without a route to handle them, the product loses goodwill and workarounds multiply.

A simple operating model for year two

A workable model does not need to be complicated. It needs three things: a support tier, a roadmap cadence and a review point.

Support tiers

A sensible split is essential support, standard support and a partner arrangement. Essential cover should include security patching, monitoring, backups and a defined response for critical incidents. Standard support adds a monthly allowance for small changes and advice. A partner arrangement provides ongoing product direction, architecture review and a quarterly roadmap.

The labels matter less than the commitments. Each tier should state response times, included hours, exclusions and the process for urgent issues. The buyer should also know what happens outside business hours.

Roadmap cadence

A quarterly roadmap review is usually enough for an SME product. It gives the business a regular moment to prioritise improvements, review support trends and decide whether to invest more or reduce scope. Monthly steering groups can become administrative; annual reviews are too slow.

The roadmap should be owned by the business, not the supplier. The supplier can advise, estimate and challenge, but the buyer should decide what matters commercially.

A service review

Once a year, the buyer and supplier should review the product against its original purpose. Is it still used? Are hosting costs proportionate? Are there components approaching end of life? Is the documentation current? This review is also the moment to test the exit plan: could another supplier take over if needed?

Avoiding a product that quietly becomes unsupported

The most common cause of an unsupported product is not a bad supplier. It is the absence of an owner. A named product owner inside the business, even part-time, makes a significant difference. That person should hold the supplier to account, maintain the backlog and understand the operating budget.

Documentation and account ownership are equally important. The business should control domain names, cloud accounts, source code repositories and third-party subscriptions. If the supplier holds everything, the buyer has less leverage and a harder exit.

Finally, the contract should include a handover clause. It need not be used, but it should exist. A product that cannot be moved is a product with a hidden cost.

Approve the operating budget before launch

Year two is not an afterthought. It is the point at which a custom product becomes either a durable business asset or a slowly decaying liability. UK SMEs should treat maintenance as a planned operating cost, agree support commitments and set a roadmap rhythm before the launch celebration fades.

The alternative is familiar: a product that still works, but nobody is quite responsible for it. That is not a saving. It is a deferred cost, and it usually arrives at the least convenient moment.