Software maintenance after launch: what it includes and what drives the cost

On launch day, your software works. From the next day on, the world around it keeps moving. The platforms it runs on reach the end of their security fixes, the certificates that secure its web address expire, and the libraries it is built from get new versions. Maintenance is the work that keeps your software working and safe while all of that changes.

What does a web application need after launch?

Five kinds of work: monitoring, security updates, renewals, platform upgrades, and fixes and changes. Some of them come round regularly, others only when something changes around the software or in the way you use it.

• Monitoring: checks at set times that the software is up and doing its job, with an alarm when it is not.
• Security updates: the libraries and platforms your software is built from receive fixes for newly found weaknesses. The OWASP Top 10 of 2025 counts software that is "vulnerable, unsupported, or out of date" among the signs that an application is likely vulnerable.
• Renewals: the certificates that secure a web address are getting shorter lives. In April 2025, the browser makers and the certificate authorities voted to cut their maximum validity from 398 days to 47 days, in steps from March 2026 to March 2029.
• Platform upgrades: the versions of a platform reach an end of life. Node.js, one of the platforms that web applications run on, says that a version past that point "will no longer receive updates, including security patches". Its long-term support versions typically get critical fixes for 30 months in total.
• Fixes and changes: errors that only show in daily use, and the improvements you ask for once people work with the software.

If your software holds personal data, there is also a legal side. The Swiss Data Protection Act asks you, and anyone who processes the data on your behalf, to guarantee a level of data security appropriate to the risk (Art. 8). A breach of data security that is likely to lead to a high risk for the people concerned has to be reported to the Federal Data Protection and Information Commissioner as quickly as possible (Art. 24). Software that nobody watches or updates makes both harder.

What does monitoring check?

Monitoring checks, at set times, that your software does what people need from it: that it is up, that people can sign in and that its pages load. Good monitoring checks each part on its own, so an alarm tells you where the problem is, not only that there is one.

Our monitoring is a service you book with us once your software is live. Every hour we check that your software is up, that people can sign in and that its pages load. The website, sign-in, database, email and scheduled tasks each have their own check.

It comes with a status page of your own software, like ours at status.predivo.ch. Ours lists each part, such as the website, the client portal and the sign-in, with its current state, and keeps a record of past incidents.

What happens when a check fails?

A failed check raises an alarm. With our monitoring, the alarm goes to us, so you do not have to watch your software yourself. What follows the alarm is worth agreeing in writing before launch, whoever does the work: who looks into it, who decides on a fix, and how the work is paid.

A fix to live software is a change like any other, and it should be tested before it goes live, the same way the software was tested before launch. Where the software has its own automated tests, they can repeat that check after every fix; where it has none, someone has to click through it by hand. How such tests work is explained in end-to-end tests in plain words.

What drives the cost of maintenance?

The cost after launch depends on what your software is made of and on what you want from it once it is live. Six things drive it, from the parts it is built on to what you need when something fails:

• How many parts it depends on. Every library, platform and outside service brings its own updates and its own end-of-life dates.
• How much it changes. Software that you keep improving needs more work than software that only has to stay as it is.
• How sensitive its data is. The Data Protection Act asks for security appropriate to the risk, so software that holds sensitive personal data needs more care than a simple internal tool.
• How well it is tested. Automated tests repeat the checks after every update; without them, each update means testing by hand.
• What you need when something fails. An hourly check with an alarm is a different service from a fix when someone happens to notice a problem.
• How it was built. Clear code with documentation is easier for anyone to pick up, including a new developer years later.

Whatever you choose, ask for it in writing, with its price, before you agree to it. What it costs to build the software in the first place is the subject of what drives the cost of custom software.

Hand it over, or keep it watched?

Either your own team or another developer takes over, or the company that built the software keeps it watched. The two can be combined, and each needs something different at the end of the project:

• Your own team or another developer takes over. They then need the code, its tests, its documentation and access to where the software runs. What you receive at the end is agreed in the offer, so check that part before you sign. Who owns the code? explains what to look for.
• The company that built it keeps it watched. With us, monitoring is a service you book once your software is live: an hourly check, an alarm to us when a check fails, and a status page of your own software.

Either way, decide before launch, not on the day the first alarm would have mattered.

Tell us about your project. Send us a message and we will get back to you.