A website or application is never finished the day it goes live. Updates, backups, monitoring and renewals all continue. What ongoing care involves and what happens when nobody does it.
There is a common misunderstanding that software is like a building: once it is complete, it stays as it is until someone chooses to change it. It is closer to a vehicle. It works well on the day it leaves the workshop, and then it needs regular attention to keep working, however carefully it was made. Understanding this before a project starts saves a great deal of disappointment later.
The reason is that software does not run in isolation. It depends on a web server, a database, a programming language, a set of libraries, an operating system and a certificate that proves the site is genuine. Every one of these is updated by its maintainers, who fix bugs and, more importantly, close security holes that have been found. When your application sits on versions that no longer receive those fixes, it becomes an easy target, and automated tools scan the internet constantly looking for exactly those sites.
Security updates are the most important part of ongoing care. This means keeping the framework, its packages and the server software current, and applying patches soon after they are released. It is routine work, but it is what prevents a defaced site, stolen customer data or a server quietly used to send spam. Delay makes it harder, too. An application that has skipped four years of updates cannot be brought up to date in an afternoon, because each change may break something that depended on the old behaviour.
Backups are the second essential. Hardware fails, mistakes happen and attacks succeed, and a good backup is what turns any of those from a disaster into an inconvenience. A sound approach is automatic and regular, keeps several past versions, stores copies away from the server they protect and, above all, is tested by actually restoring from one now and then. A backup that has never been restored is a hope, not a plan.
Monitoring is the third. Somebody or something should notice when the site goes down, when the disk is nearly full, when the database slows or when errors start to appear in the logs. Without monitoring, the first sign of trouble is often a customer telling you. With it, a problem is usually fixed before anyone outside notices.
Then there are the renewals that quietly expire. The domain name. The SSL certificate, which some providers issue for only ninety days at a time and renew automatically, provided the renewal keeps working. Hosting plans. Third-party services such as email delivery, payment gateways and map keys. An expired domain can take a business offline overnight, and recovering it is not always possible. Keep a list of what expires and when, and make sure the renewals are tied to an email address that somebody actually reads.
Beyond keeping things running there is ordinary improvement. Real users find things that testing did not. Business needs change, and a report or a field or a rule that was not needed at launch becomes essential six months later. Small, steady changes are far cheaper than a big rebuild every few years.
When you agree a project, ask what happens afterwards. Who applies updates? How quickly would a critical problem be fixed? Where are the backups and who can restore them? How are changes requested and priced? A clear support arrangement, even a modest one, is worth more than a promise to sort it out when something breaks. We are happy to set this out for any project we build, and to review one built by someone else.