Insight

What happens after custom software launches? Maintenance, support and ownership explained

11 Aug 2026

• Custom software
• Maintenance
• Software ownership

Launch day starts the period in which the software does real work for real people and needs ongoing attention.

That distinction matters when a business is comparing proposals. The initial project pays for getting the software designed, built, tested, and released. It should also establish what happens afterwards: who keeps it healthy, who responds when somebody needs help, how future changes are handled, and who owns what.

None of this should arrive as a surprise six months after launch. Maintenance and support are normal parts of running custom software. Ownership should be agreed before the work begins.

Launch changes the work; it does not end it

Before launch, most attention goes into deciding what the software should do and making sure it is ready. Afterwards, the priorities become more practical.

Is it working reliably? Can people get help? Are backups running? Do small changes elsewhere affect it? What have users learned now that the system is part of their day rather than something they are testing?

Some projects settle into a quiet rhythm. An internal tool used by a small team may need only occasional attention. A customer-facing platform handling payments, subscriptions, or daily orders will usually need more active care. The right level of support depends on how important the system is and what happens to the business when it is unavailable.

The sensible time to discuss this is while the project is being quoted. A proposal does not need to predict every future request, but it should explain the expected support arrangement and the costs that continue after launch.

Maintenance is ordinary care, not evidence of a bad build

All software sits in a changing environment. Browsers update. Mobile operating systems change. Payment providers revise their requirements. Services the software connects to release new versions. Security updates become available. The business itself changes too.

Maintenance is the work that keeps the existing system dependable through those changes. It may include:

• applying important updates;
• checking backups and monitoring;
• keeping mobile applications compatible with new phone software;
• responding to changes in connected services;
• fixing faults found in normal use;
• reviewing performance as usage and data grow.

A well-built system should make this work more predictable. It should not remove the need for it entirely.

It helps to think of maintenance in the same way as servicing a vehicle or maintaining business equipment. Good initial work reduces avoidable problems, but leaving something untouched for years is not a maintenance plan.

Support is about people as much as software

Maintenance looks after the system. Support helps the people relying on it.

A user may be unsure how to complete an unusual case. An administrator may need help correcting a mistake. A manager may report that a figure looks wrong. Sometimes the software is working as designed, but the real process has changed and the old behaviour no longer fits.

The support arrangement should make a few things clear:

• where questions and problems are reported;
• who decides how urgent something is;
• when the team is normally available;
• how quickly serious problems are acknowledged;
• what is included in the ongoing agreement;
• how work outside that agreement is approved.

Round-the-clock cover is unnecessary for many businesses. The response should match the consequence. A system used during office hours by eight colleagues needs a different arrangement from a booking platform taking customer payments every evening and weekend.

Improvements are different from keeping the current system running

Once people use new software, they usually see opportunities that were difficult to spot earlier. A report could save another hour each week. A customer asks for self-service access. A manual approval step is no longer necessary. These are good signs: the business is learning from the product.

They are also new work.

A clear agreement separates maintenance, support, and product improvements. Maintenance keeps agreed behaviour working. Support helps users and handles incidents. Improvements change or extend what the software does.

This separation avoids an awkward conversation later. The client should not be charged for correcting work that does not meet the agreed result. At the same time, an ongoing support fee cannot reasonably include an unlimited stream of new features.

Good partners make the boundary visible, discuss small requests sensibly, and estimate larger changes before starting them.

What should ongoing software cost?

There is no useful flat percentage that suits every project. Ongoing cost depends on the importance of the system, the amount of change around it, the number of users, and the response the business expects.

Common arrangements include a monthly support agreement, a reserved number of hours, work requested as needed, or a continuing product team. Hosting and fees for outside services may be billed separately because they change with usage.

The original quote should state what is included around launch. That may cover a settling-in period, correction of faults, monitoring setup, store releases, or a certain amount of user support. It should also explain what happens when that period ends.

The aim is not to make every future cost fixed. It is to prevent the ongoing part from being invisible when the investment decision is made.

Ownership should be decided before development starts

“We paid for it, so we own it” can mean several different things unless the contract is specific.

The agreement should say who owns the custom source code and when ownership transfers. It should also cover the less obvious parts needed to operate the product:

• the domain and hosting accounts;
• app store accounts;
• design files and written documentation;
• access to the source-code repository;
• business data and the ability to export it;
• accounts for analytics, email, payments, and other services;
• any third-party components that are licensed rather than owned.

Some reusable parts may remain the property of the development company. Some components may be open source. That can be perfectly reasonable, provided it is understood from the beginning and does not prevent the client from operating or continuing the product.

Ownership on paper is only half the question. The business should also have practical control. If every account is registered to the supplier, the client may technically own the software while still depending on that supplier to access it.

Staying with the original team should be a choice

There are good reasons to keep the same software partner after launch. They know the decisions behind the product, can respond without relearning the whole system, and can continue improving it as the business changes.

That relationship is healthier when it is chosen because the service is good, not because leaving would make the software impossible to run.

Another capable team should be able to take over with access to the code, accounts, operating instructions, and a sensible handover. The change may still take time. Context cannot be transferred instantly. But the route should exist.

Before signing a development agreement, ask a few direct questions:

• What support is included immediately after launch?
• What maintenance do you expect this system to need?
• How are urgent problems handled?
• How are future improvements priced?
• Who owns the code, data, and operating accounts?
• What would a handover to another team include?

Clear answers are a good sign. They show that the supplier is thinking beyond the launch date and treating the software as something the business will need to rely on for years.