An off-the-shelf package updates itself: the vendor releases a new version and every customer gets it automatically. Custom software has no such vendor. A development team built the application for you, and everything needed afterwards, from security fixes to new functionality, has to be organised and assigned.
Can custom software receive automatic updates, then? Technically, yes, and for a good part of it that’s sensible too. But the question that matters more: who is responsible, after delivery, for keeping your application secure, stable and up to date?
Where updates for custom software come from
Every custom application relies on building blocks made by others: frameworks, libraries, the programming language, the server it runs on. New versions of those building blocks appear continuously, often fixing security flaws. The application itself changes too: bugs get fixed, functionality gets added, an integration with another system changes.
With a SaaS package, the vendor pushes through all those changes unasked, on its own schedule and in its own way; we describe how that plays out in the difference between custom web applications and SaaS solutions. With custom software, new versions of the building blocks do appear on their own, but reviewing, testing and rolling them out doesn’t happen by itself. That work has to be assigned to someone.
Technically, a lot can be automated
If your application runs as a web application on a central server, everyone automatically works in the latest version; nobody installs anything themselves. A new version can go live without interruption, even during working hours. And flagging new versions of frameworks and libraries is straightforward to automate: the system reports on its own what’s ready to go.
What we advise against is letting those updates install unseen. A new version of a building block can change behaviour or clash with the rest of your environment, and unlike a package with thousands of users, nobody else has run into the problem before you. Between flagging and going live there should therefore be a human step: a developer reviews the change, tests it in a staging environment and then rolls it out to production on a planned basis.
Without an agreement, nobody is responsible
Delivered software is never finished. Building blocks age, security flaws come to light, browsers and connected systems change. Organisations that make no agreement about this usually notice only once something breaks down or a flaw makes the news. Ask the question at the start of every project: who monitors the application, who reviews and tests updates, who rolls them out, and how quickly is action taken when an urgent security flaw appears?
What a maintenance agreement looks like
A good maintenance agreement makes that responsibility concrete. An example of what it covers:
- Monitoring: the application and the underlying servers are watched continuously, so a fault is spotted before users report it.
- A fixed update cycle, for example on a monthly basis, in which new versions of frameworks and libraries are reviewed, tested and rolled out.
- Security fixes outside that cycle, as soon as a vulnerability calls for one.
- Every change goes to a staging environment first, then to production in an agreed window.
- A fixed point of contact and clear response times when something breaks.
With an agreement like that, automatic updating isn’t a risk but a way of working: flagging and rolling out are automated, reviewing and testing stay human work. And you know in advance what it costs and who to call if something goes wrong.
Is there an application running in your organisation where nobody can say exactly who’s responsible for the updates? Have that conversation now rather than after the first outage. Our engineers monitor, maintain and improve custom applications, including software built by another agency. What a maintenance agreement like this covers, you can read at ongoing development and maintenance.