Software Maintenance Checklist for Growing Businesses

Most businesses don't know their software is falling behind until something breaks. By then, what should have been a routine check becomes an emergency.

I've watched this happen many times. A team builds something solid, ships it, and then moves on to the next thing. Nobody's job becomes keeping an eye on what's already running. Six months later, a dependency hasn't been updated, the SSL cert is about to expire, and the error logs are full of warnings that nobody reads. Then one morning a customer can't log in and everyone's scrambling.

Maintenance is keeping what you have working. Bugs fixed, security patched, dependencies current. It's not glamorous, and nobody celebrates a dependency update. But skipping it long enough turns a codebase into a liability.

Security

Security is where ignored maintenance causes the most damage. Vulnerabilities don't announce themselves. They sit in your dependency tree until someone exploits them.

Run through these first. Everything else can wait if security is failing.

• All dependencies updated in the last 90 days?
• Security patches applied for your language runtime and framework?
• No known vulnerabilities flagged in your package audit (npm audit, pip-audit, bundle audit, or equivalent)?
• SSL certificates valid and not expiring within 30 days?
• User data encrypted at rest and in transit?

Here's a real example. A client came to us after a data incident. Their Node.js app was running on a version that had a known RCE vulnerability, patched eighteen months earlier. The fix was one command. The cost of not running it was substantial. Not because anyone was lazy. Because nobody owned it.

That's what unattended software does.

Reliability

Reliability problems are quiet until they're catastrophic. You don't notice them until a user tells you something's broken, or until the whole thing goes down at the worst possible moment.

• Monitoring in place, not just uptime pings but application-level alerts that catch errors before users do?
• Error tracking active, Sentry or equivalent, so you know what's failing and how often?
• Backups tested recently, not just scheduled to run, but actually restored and verified?
• Recovery time objective documented and known by at least two people on the team?

The backup question catches people every time. Most teams have backups running. Almost nobody has tested restoring from them.

Running a backup and verifying a restore are two different things. You want to know the second one works before you need it.

"Backups that haven't been tested are just hope stored on a server."

Performance

Performance degrades slowly. A page that loads in 400ms this month might load in 1.2 seconds next quarter. No single change caused it. It just drifted. And users notice before you do.

• Core user workflows completing within acceptable time, meaning times you've actually measured, not guessed?
• No slow queries sitting unaddressed in your database logs?
• Database growing at a rate that's been planned for, with indexes reviewed as the data scales?

Your business moved. The software didn't. That gap shows up first in performance. Users change behavior, volume increases, new features add joins to queries that used to be fast. If you're not checking, the slowdown is already happening.

Code Health

Code health is the hardest category to take seriously because nothing breaks immediately when you ignore it. The cost shows up when you need to move fast and can't.

• No critical bugs open and sitting ignored in your tracker?
• Test coverage on the core workflows that, if they broke, would stop the business?
• A new developer can get the codebase running locally in under a day?
• Technical debt documented somewhere, prioritized, not just vaguely known about?

The onboarding question is a reliable proxy for code health. If it takes three days for a new developer to get things running, that's not an onboarding problem. It's a documentation and environment problem that your existing team is just too familiar to notice.

If technical debt lives only in people's heads, it doesn't get addressed. It gets inherited.

Business Fit

This is the category most technical checklists skip. Software doesn't just need to run. It needs to still match how the business works.

• Does the software still reflect how your team actually operates, including changes in process, team size, and workflow that happened in the last year?
• Workflows that were automated twelve months ago still automated, or has someone quietly been doing them manually?
• Reports and dashboards producing accurate data, not just any data?

Businesses change faster than software does. That's the gap worth checking.

I've watched teams accumulate three or four spreadsheets running alongside their software because the software stopped fitting how they work. Nobody killed the software. Nobody updated it either. They just routed around it. That's expensive in a way that doesn't show up on any invoice.

If you're doing software maintenance in Nepal or anywhere else at scale, the business fit check often surfaces more actionable work than the technical checks.

What to Do With the Results

Going through this checklist produces one of four situations. Each has a clear response.

Green on most items: Schedule a review in 90 days. Don't let it slip past that. Make it a calendar event that doesn't get moved.

Red on security: Fix it now. Not this sprint. Not after the current feature ships. Now. A security vulnerability doesn't care about your roadmap.

Red on reliability: Fix it within the week. A system without working backups, monitoring, or error tracking is one incident away from a very bad day. Reliability is not a background priority.

Multiple reds across categories: This is no longer a checklist situation. It's an audit. You need someone to go through the codebase properly, understand the full scope of what's been deferred, and build a prioritized plan. Trying to fix everything at once without that context usually makes things worse.

At Asteroid Studio, we run this kind of check for every client on retainer. Not as a formality. Because catching a failing dependency or an expiring certificate before it causes an incident is worth far more than the time it takes. We stay on the codebase, watch how it's holding up as the business grows, and flag things before they become emergencies.