Software maintenance after launch: what should your development partner commit to?

Software maintenance after launch should define what keeps working, who handles a failure and how long the commitment lasts. Before agreeing terms with a software development company, establish supported environments, support hours, security updates and a process for ending support. Extra service provided repeatedly can become an expectation even when the original proposal did not include it. Each extension should therefore be a visible decision, with a defined scope and a date for review.

What does Fairphone tell us about support expectations?

In March 2023, Fairphone announced the end of software support for Fairphone 2 after more than seven years. Its official announcement described an original ambition of supporting the device for three to five years. This is a historical example from a phone manufacturer, not a Julius project. The details are in the company announcement about the end of support.

Our reading of the story is that extending a service can move the user's reference point: something that started as an extra becomes something they plan around. That is a management interpretation, not a measurement of the views of all Fairphone customers. For a business product, the practical question is how to let a customer plan the next year without having to guess whether the next fix is included or is a one-off favour.

Separate defect responsibility from ongoing maintenance

Responsibility for correcting a defect in the delivered product is different from adapting it to a new operating system. Adding a field to a report is not necessarily a defect either. A useful maintenance document describes examples from your own system: a form that does not save data as specified, a new browser that changes behaviour, and an integration whose provider changes its interface. Each example needs an owner and a decision about how the work is priced.

Ask the supplier to distinguish response time from resolution time. Acknowledging a report does not restore a system. A failure involving an external provider may not have a resolution date anyone can promise in advance. You can still define when investigation starts, who updates you and which workaround will be considered. This makes proposals comparable by expected behaviour rather than just by a monthly allocation of hours. Our guide to clear software development contracts covers the wider engagement.

What belongs in the supported-environment inventory?

Record the product versions in use, the browsers or operating systems that matter to customers, and the external components the business depends on. Beside each component, identify who checks its support lifecycle and when that information was last reviewed. You do not need to promise support for every device in existence. You do need to understand whether an important group of customers uses an environment the team never tests.

Server infrastructure needs an explicit decision as well. For example, the Node.js release policy recommends using Active LTS or Maintenance LTS releases for production applications. The operational implication is to schedule an upgrade assessment before support ends, with an owner and a budget. Changing a version number without checking important user journeys is not a maintenance plan.

The Julius website itself has distinct Hebrew and English behaviour, small-screen adaptations and support for the reduced-motion preference. These are details visible on the site and inspectable in its code. They demonstrate why a visual update needs checking in more than one environment. They do not promise support for every browser or establish a service level on another customer's project; this is a specific example from the product we operate.

How do you end support without surprising customers?

Start with the action the customer will need to take. If ending support requires an upgrade, identify who installs it and what happens to existing data and integrations. If it requires a different supplier, prepare permissions and documentation that allow the next team to work. An announcement containing only a date leaves most of the work with the recipient, without establishing whether they can carry it out.

An illustrative internal policy could say: before ending support for a version, identify active users, test a migration path in a test environment, notify the customer's responsible person and confirm who performs the migration. This is a proposed process, not a binding Julius policy or a universal timetable. A system supporting critical business activity may need different preparation from a small content website.

Document exceptions too. If you agree to keep fixing an old version for a particular migration, state which fixes are covered and when the exception ends. Otherwise, a fast response on one occasion can be interpreted as a standing commitment. Do not leave this knowledge in a private conversation with a single developer: the product manager and the support contact need access to the same information.

Four questions for the next maintenance meeting

What happens if an essential action fails on a day when no developer is available? Which components are approaching the end of their support window? Which requests count as new work rather than corrections? And how will the team demonstrate that the next version preserves existing business activity? Ask for answers that point to an owner, a document or a test. A general promise that someone is always available provides little information for planning budget or staffing.

If you have not launched, include these decisions in the technology product specification before implementation settles around assumptions. If the product is already running, start with its dependencies and one business journey that must keep working, then expand the assessment from there. Through Julius development services, you can discuss the current system and the maintenance scope it needs. The aim is continuity that can be explained and checked, rather than an indefinite promise of support.