What happens after launch: maintenance nobody budgets for
The work a website or system needs after delivery, where maintenance ends and development begins, and what a support agreement should state.
The website went live in March. The developer was paid, the handover meeting was friendly, and everyone went back to their other work. In November the contact form stops delivering messages, or the browser shows a warning page where the homepage used to be, and the developer's number no longer answers. Nothing dramatic happened in those eight months. A component went without its updates, or a renewal notice went to an address nobody reads.
Software is something you run, not something you finish. This post lists the work a website or business system needs after launch, shows where maintenance ends and new development begins, and sets out what a support agreement should put in writing.
The work that continues when nothing is broken
Six kinds of work carry on after launch even if no one reports a fault.
- Security updates. The platform the site is built on, its plugins or libraries, and the server software underneath all receive fixes for newly discovered weaknesses. A site left on its launch-day versions gets easier to break into as time passes.
- Renewals. The domain and the SSL certificate expire on fixed dates. Someone has to own those dates, and the reminder emails must go to an address that is read.
- Backups, and a test that they restore. A backup nobody has restored is an assumption. Our post on the backup you have never tested describes a short drill.
- Watching that the site is up. Software checks the site every few minutes and tells a person when it fails. Without it, your clients are the ones who find out.
- Changes forced by others. A payment gateway retires an old version of its interface. A messaging service changes how messages must be sent. Neither is your decision, and each needs work on your side by a date somebody else chose.
- Small content changes. A new phone number, a new branch, an employee who left and is still on the team page.
Maintenance and development are two different jobs
Maintenance keeps the system doing what it already does. Development makes it do something new. Updating the platform, renewing a certificate and restoring a backup are maintenance. Adding online payment, a new report or a second language is development.
Most arguments between a company and its developer start where the two are mixed. The client believes the monthly fee covers "changes". The developer believes it covers keeping the site alive. A request for a new booking form arrives, one side expects it at no charge and the other sends a quote. Both are reading the same vague sentence in the agreement.
The fix is to write down which is which, and to agree how new work is priced before the first request arrives. One grey area deserves its own line: changes forced by third parties. Decide in advance whether adapting to a gateway's new interface counts as maintenance or as quoted work.
What a support agreement should state
- What is covered, and what is excluded. A list: updates, backups, monitoring, renewals, and a stated amount of small changes each month.
- How to report a problem and how quickly someone answers. One channel, such as a ticket system or a shared address, with an answer time for urgent issues and another for ordinary ones. An arrangement that depends on calling one person's mobile stops working the day that person travels.
- Who holds every password and account. The domain, the hosting, the administrator login, the code repository, the app-store accounts. Your company should hold owner access to each of them. For the code, see our post on where your code lives.
- How new work is quoted. In writing, with a price, before it starts.
- A regular short report. Once a month is enough: updates applied, backups taken and tested, any downtime, requests closed.
- What happens if you part ways. Code, data and accounts are handed over, in a stated format and within a stated number of days.
A table for comparing offers
Put each offer you receive against this table. The middle column shows a sensible division of the work. If an offer leaves a row unanswered, ask about it.
| Item | Who does it | How often |
|---|---|---|
| Security updates to the platform and its components | The supplier | Monthly, and sooner for an urgent fix |
| Backups of files and database | The supplier | Daily for a site that takes orders or stores records |
| Restore test | The supplier, who shows you the result | A few times a year |
| Monitoring that the site is up | The supplier | Continuously, by software |
| Domain renewal | The account is in your name; the supplier reminds you | Before each expiry date |
| SSL certificate renewal | The supplier | Automatically, before each expiry |
| Adapting to changes by a payment gateway or messaging service | Agreed in advance: covered or quoted | When the provider announces a change |
| Small content changes | Your staff through the admin panel, or the supplier | As needed |
| Written report | The supplier | Monthly |
| Review of who holds the logins | You | Whenever someone leaves |
Warning signs in the arrangement you have now
- Only the developer has the logins. If that person stopped answering, you could neither renew the domain nor move the site.
- Nobody can say when a backup was last restored. Ask for the date of the last restore test and what was restored in it.
- Updates have not been applied since launch. Ask for the date of the last update. If nobody can give you one, assume there has been none.
The incident that skipping maintenance leads to
The typical case has the same parts each time. A component with a known weakness is never updated. An automated scan finds it, because attackers scan addresses in bulk and do not pick their targets by size. The site begins sending spam or redirecting its visitors elsewhere. The hosting company suspends it, and browsers start warning visitors away.
Then the second half begins. The developer has moved on to other work. The only backup dates from launch week, or it sits on the same server that was broken into. The logins are in an old phone. Work that would have been routine each month turns into days offline, a rebuilt site, and the orders and enquiries lost in between.
Three questions to ask this week
Ask whoever looks after your site or system: who holds the logins, when was a backup last restored, and when was the last update applied? If the answers are thin, turn the list above into a written agreement. Our post on what a fixed-price scope contains describes the same kind of document for the build itself.
At PearlFibers the period after launch is a monthly operate plan that covers hosting, monitoring and support. It is itemised in the client portal, where support tickets and invoices also live. The source code is yours on final payment, and ongoing hosting and support are optional. We can usually take over a system built by someone else, starting with a paid technical review that gives you a written assessment of what you have. To see what the plan covers, or to ask for that review, start at the software development page.