Software Maintenance and Support: What Happens After Launch

Picture a system that’s been running quietly for three years. It takes orders, sends invoices and takes card payments. Nobody has touched the code since launch, because nothing has gone wrong.

Then one Monday, payments stop going through. The payment provider retired an older version of its service months ago, and sent emails warning about it. Those emails went to a developer who’d since left. Now the fix is urgent, the code is three years out of date, and it needs bringing up to date before anyone can even start on the payments problem.

Launch day feels like the finish line. In reality, it’s the start of the longest part of your software’s life. This guide explains what software maintenance and support should look like once your system is live: what happens in the first few weeks, what ongoing care involves, how it’s usually paid for, and what to agree with your supplier before you go live.

Why does software need looking after?

Software doesn’t wear out, but the world around it keeps changing. A system that’s left alone slowly becomes harder, riskier and more expensive to change. The main reasons are:

Security fixes. New weaknesses are found in widely used software all the time. Fixes are released quickly, but they only protect you once someone applies them.
End of support. Your system is built on a programming language, a framework (the toolkit developers build with) and a server. Each version of these has a limited lifespan. Once it reaches end of support, it stops getting security fixes.
Third-party services. Payment providers, email services, mapping tools and accounting packages change how other systems connect to them, and retire old versions on their own timetable.
Browsers and devices. New browser and phone updates occasionally break things that used to work.
Your business. New staff, processes, customers and regulations all mean the system needs to keep up.

The longer updates are left, the bigger they get. Small, regular upgrades are routine work. Skipping several years of them can turn into a project in its own right.

What happens in the first few weeks after launch?

The first few weeks are about bedding in. Real people start using the system with real data and real deadlines, in ways testing didn’t cover. Expect a few small bugs and plenty of “could it just…” requests. That’s normal, and not a sign the build went wrong.

A good supplier will keep a close eye on the system during this time. They’ll watch error alerts, check how it copes with real use, and fix problems quickly while the build is still fresh in the developers’ minds.

Many suppliers include a short warranty period after launch, often around 30 days, where bugs are fixed at no extra cost. Check whether yours does, how long it lasts and what counts as a bug. Get it in writing, because warranties are often agreed informally and remembered differently later.

Ideally, ongoing support starts the day you go live, so there’s no gap between “the project” and “looking after it”. Keep a list of the change requests that come up in these weeks too. Most are better grouped and prioritised once things settle than rushed in one at a time.

What does ongoing software maintenance and support cover?

Ongoing software maintenance and support covers four things: keeping the system running, keeping it secure and up to date, fixing problems, and improving it over time.

Keeping it running

This means hosting, monitoring and backups. Someone should be alerted automatically when the system goes down or starts throwing errors, ideally before your users notice. Backups should run on a schedule and be stored separately from the live system. Security certificates (what gives you the padlock in the browser) need renewing too, though this is usually automatic now.

Keeping it secure and up to date

This means applying security fixes regularly and upgrading to supported versions of the language and framework, often once a year. It’s the least visible part of maintenance, so it’s the easiest to skip. Systems holding sensitive data may also need an independent security test (a penetration test) from time to time. Many agencies arrange these through a specialist rather than doing them in-house.

Fixing problems

When something breaks, you need to know who to contact, how to report it and how quickly someone will respond. Response times are normally tiered by how serious the problem is, so a full outage gets a faster response than a typo.

Improving it

Most systems keep growing after launch: new reports, new integrations, tweaks to how a process works. This is usually kept separate from maintenance, and either quoted per change or paid from a set budget.

All of this should be reported back to you regularly in plain English.

Is it a bug or a change request?

A bug is when the system doesn’t do what was agreed. A change request is when you want it to do something different or new. The difference matters because bugs are usually fixed at the supplier’s cost, while changes are usually paid for.

Situation	Usually treated as
An invoice total is calculated wrongly	Bug
A page shows an error when a field is left blank	Bug
You’d like invoices to show an extra column	Change request
A process works as agreed, but staff find it clunky	Change request
A connected service changes and the link to it breaks	Maintenance

The grey areas cause most disagreements. The best protection is a clear written record of what was agreed during the build, such as a specification or signed-off requirements. It also helps to have a supplier who tells you how they’ll treat something before they start work on it, not after. Many suppliers are generous with small grey-area fixes, but it’s better not to rely on that.

How do you pay for bespoke software maintenance?

There are three common ways to pay for looking after bespoke software. Each suits a different situation.

Pay as you go. You pay for time as and when you need something. It looks cheapest on paper and can suit small, stable systems that rarely change. The catch is that nobody is looking after the system between requests. Updates tend to get skipped, and there’s often no agreed response time when something goes wrong.

A block of time. You buy a set amount of time in advance and use it as needed. This gives you a predictable budget and some priority. But hours tend to go on visible requests rather than background upkeep, and it’s not always clear what happens to unused hours.

An aftercare agreement. You pay a fixed monthly fee for a defined service: monitoring, security updates, regular upgrades, support with agreed response times, and regular reporting. New features are usually quoted separately or paid from an improvement budget. In a quiet month it costs more than pay as you go. In return, someone is responsible for your system all the time, and your costs are predictable.

For a system your business relies on every day, an aftercare agreement is usually the safest choice. For a small internal tool that rarely changes, pay as you go can work, as long as someone still applies updates.

What to agree with your supplier before launch

The time to agree aftercare is before go-live, not when something breaks. Before you launch, make sure you know:

who to contact for support, and how (email, portal or phone)
the response times for critical, high and normal problems, and what counts as critical
whether there’s a warranty period, how long it lasts and what it covers
what’s included in ongoing support, and what’s charged separately
how often security updates and upgrades happen
how you’ll hear about errors, outages and planned work
where backups are kept and how often they run
whose account the hosting is in
who manages the domain name and security certificates
where the code is stored, and whether you can get a copy
what documentation you’ll get at handover

On hosting, it’s worth insisting that your system runs in a hosting account owned by your business, with your supplier given access to manage it. That way, if you ever change supplier, the system, its data and its backups stay with you.

What you need to look after yourself

Some parts of aftercare sit with you, not your supplier.

Name an internal owner. One person in your business should own the system. They collect feedback, prioritise changes and act as the main contact. Without one, requests arrive from everyone and nothing gets decided.

Keep your domain renewed. Domain names are often registered in the client’s name. If yours lapses, your system goes offline however well it’s maintained. Turn on auto-renew and keep the payment details up to date.

Keep a wishlist. Note ideas and frustrations as they come up, then go through them with your supplier every few months. Grouped changes are cheaper and fit together better than one-off requests.

Keep your supplier in the loop. New processes, new regulations, a new accounting package or a jump in users can all affect the system. The earlier your supplier knows, the easier it is to plan for.

When does it stop making sense to maintain a system?

A well-built, well-maintained system can keep going for many years. It’s worth thinking about a rebuild when:

upgrades get harder and more expensive every year
the technology it’s built on is out of support and can’t easily be upgraded
your business has changed so much that most of the system is workarounds
small changes regularly take far longer than they should

A rebuild is a big decision. Ask your supplier for an honest view, and get an independent second opinion if you’re unsure.

How we look after software at Yammayap

At Yammayap, aftercare is built into how we work. Our aftercare service, Depend, is the final stage of the Yammayap Advantage Methodology. It’s optional, but we strongly recommend it to every client.

Depend covers error and uptime monitoring, security updates, annual upgrades and support with set response times. Every quarter, clients get a plain-English health report and an in-person review, where we agree what to improve next. Clients can also add an improvement budget for new features, with each one priced up front.

Thinking about what happens after your system goes live? Get in touch and we’ll talk it through.

Frequently asked questions

What is software aftercare?

Software aftercare is the ongoing support and maintenance a system gets after it launches. It usually covers monitoring, security updates, regular upgrades, bug fixes and support with agreed response times.

What’s the difference between software maintenance and support?

Maintenance is the planned work that keeps a system healthy, such as security updates and upgrades. Support is the help you get when something goes wrong or someone has a problem using it. Most aftercare agreements include both.

How long is a typical warranty after software launch?

Often around 30 days, during which bugs are fixed at no extra cost. Terms vary between suppliers, so check what yours covers and get it in writing.

Can I stop paying for maintenance once my software is finished?

You can, but bespoke software is never really finished. Without updates it becomes less secure and harder to change. Fixing that later usually costs more than keeping on top of it would have.

Does software maintenance include new features?

Usually not. New features are normally quoted separately, or paid for from an agreed improvement budget.