Software Maintenance After Launch: What It Involves

Software maintenance after launch is the ongoing work that keeps a system secure, running and useful: updating the libraries it depends on, applying security patches, paying for and managing hosting, monitoring for errors and downtime, fixing bugs, and making small changes as the business changes. Budget for it from the start as a recurring cost, and agree in writing what your vendor covers, how fast they respond, and who owns the code.

Launch day feels like the finish line. For the software, it is the start of its working life, and the conditions around it begin changing the next morning. Browsers update. Libraries publish fixes. Your team asks for a new report. None of that stops because the project is closed.

What software maintenance after launch involves

Dependency updates

Modern software is built on open-source libraries and frameworks, often dozens of them. Each one releases updates with fixes, and occasionally with changes that break the code that uses it. Updating regularly in small steps is routine work. Leaving it for two or three years turns it into a project, because several major versions have to be jumped at once and each jump can break something.

Security patches

When a vulnerability is published in a library, a framework or the server operating system, the clock starts. Attackers read the same advisories you do. Patching is mostly fast when the system is kept current and slow when it is not, which is the strongest argument for regular dependency updates.

Hosting and infrastructure

Servers, databases, domain names, SSL certificates and email sending all cost money and need looking after. Certificates expire. Disks fill up. A cloud provider retires an old database version and gives notice to upgrade. Someone has to watch for these, and someone has to hold the account logins, which should be your organisation, not a single freelancer.

Backups

Backups run automatically, but they still need checking. A backup job can fail for weeks without anyone noticing if nobody looks. A test restore every few months is the only way to know the backups work.

Monitoring

At minimum: an uptime check that alerts someone when the system is down, error logging that records what broke and where, and a watch on disk space and slow responses. Without monitoring, your users are the alerting system, and they will tell you late and without details.

Bug fixes

Every system has bugs that only show up with real use: an unusual name that breaks a form, a report that times out once the data grows, a browser that renders a screen oddly. These are normal, and a good maintenance arrangement fixes them without a new contract each time.

Small changes

A new field, a changed tax rate, a new branch, an extra column in an export. Businesses change constantly and their software has to keep up. In Nepal, payroll rules and tax slabs change with the fiscal year, so an HR system that is not maintained is wrong within a year.

Maintenance versus new development

Agree where the line sits before it causes a dispute. A practical split:

• Maintenance: keeping existing features working, security and dependency updates, hosting, monitoring, backups, bug fixes, and small changes inside an agreed size.
• New development: new modules, new user roles, new integrations, and anything that changes how a core workflow behaves. These get scoped and quoted separately.

The grey zone is "small change". Define it by effort, such as anything that takes under a set number of hours, rather than by description. "Just a small tweak" covers a lot of ground.

How to budget for maintenance

There is no honest single figure for software maintenance cost, because it depends on the system. These are the things that move it:

• Size and number of moving parts. More screens, roles and integrations mean more to keep working.
• Integrations. Every connection to another system breaks when that system changes, and you do not control when that happens.
• How critical it is. A system that stops sales or payroll when it goes down needs faster response and closer monitoring, and that costs more.
• Rate of change in the business. A company adding branches or products every quarter will ask for more changes than one that is stable.
• Age and condition of the code. Well-tested, current code is cheaper to maintain than old code nobody has touched for years.

Two habits keep the budget realistic. First, ask for maintenance to be priced in the original proposal, as a separate line from the build, so you see the total cost of owning the system before you commit. Second, separate the fixed part (hosting, monitoring, updates, backups) from the variable part (bug fixes and changes). The fixed part is predictable every month. The variable part is easier to manage as a monthly block of hours you can use or roll over.

If you are still deciding whether to build at all, maintenance belongs in that comparison too. Our guide to off-the-shelf versus custom software covers the ongoing costs on both sides.

What happens when maintenance is skipped

Nothing, for a while. That is what makes it easy to cut. Then a certificate expires and the site shows a security warning, or a security advisory lands for a library three major versions behind, or the developer who knew the system has moved on and nobody else can get it running locally. Each of those is more expensive to fix in a hurry than it would have been to prevent.

Questions to ask a software vendor before you sign

• What exactly is included in maintenance, and what is billed as new work?
• How often do you update dependencies and apply security patches?
• What are your response times for an outage, a serious bug and a minor one, and during which hours?
• Who monitors the system, and who gets alerted when it goes down?
• How often are backups tested with a real restore?
• Whose name are the hosting, domain and code repository accounts in? They should be in yours.
• Do we own the source code, and is it documented well enough for another team to take over?
• What happens to the system and our data if we end the contract?

Clear answers to these tell you more about a vendor than the build price does, and they belong in the software maintenance contract. A team that cannot say how it handles a security patch has probably not planned to handle one.

The short version

• Maintenance starts on launch day and never really ends.
• Update dependencies in small, regular steps.
• Monitor uptime and errors so you hear about problems first.
• Test backups with a real restore.
• Price maintenance alongside the build, not after it.
• Keep the accounts and the code in your organisation's name.

Yoddha Lab builds custom software from Kathmandu, Nepal, for businesses that need it to keep working well after launch. If you are planning a build, or have a system that has gone a while without updates, see our software development services, read how to scope a software project, or ask us about maintaining your system.