What software maintenance actually looks like after launch

Teams celebrate launch because it is visible. The more expensive period is the year after, when real users find the gaps, vendors change an API, and someone asks for “a quick extra report.” If you do not plan for that work, the application starts to rot while still looking finished.

Maintenance is a queue, not a vibe

Treat incoming work as a backlog with types: a defect, a risk (a dependency, a backup, a certificate), and an enhancement. Mix them on purpose. A month of only enhancements is how you wake up with an unpatchable framework. A month of only defects is how the product stops matching the business.

Watch the jobs that nobody clicks

The fragile parts of business software are usually scheduled. Imports, reminders, reconciliations, webhook retries. If those fail silently, customers will notice before you do. A boring dashboard of failed jobs and queue depth is more valuable than another chart on the marketing site.

Document the decisions that will be rediscovered

Why this status cannot skip a state. Why this integration is eventually consistent. Why a user can see a row but not edit it. Those notes are cheaper than a Slack archaeology session. We leave them next to the code and in a short operational guide, not in a slide deck that nobody opens.

Leave a way to stop

A healthy maintenance relationship includes the option for your team to take over. That means a repository you own, credentials in your accounts, and a handover that is more than a zip file. Long-term support should be a choice, not a trap.