A software project does not become maintenance-free when it reaches production.

Browsers change. Dependencies publish fixes. Providers deprecate APIs. Certificates expire. Content becomes inaccurate. Traffic patterns shift. A workflow that made sense for ten customers may become painful for a thousand.

“We will fix things when they break” is not a maintenance plan. It is an unpriced incident strategy.

A useful plan tells the client and technical team what is watched, who owns the response, what routine work is included, and how new product work enters the system.

Start with a service inventory

You cannot maintain what nobody has recorded.

The inventory should identify:

• production application and domains;
• hosting and deployment services;
• databases and object storage;
• email, payment, authentication, analytics, and other providers;
• scheduled jobs and queues;
• source and artifact ownership;
• DNS, certificates, and renewal behavior;
• environment variables and secret owners;
• monitoring and alert destinations;
• backup locations and retention.

Do not put secret values in the inventory. Record where they are managed and who can rotate them.

The goal is to remove the moment during an incident when everyone asks, “Which account controls this?”

Define what “healthy” means

An uptime number alone is incomplete.

A server may return a successful response while checkout, signup, email, or data processing is broken.

Health should reflect the product’s important paths. Depending on the system, that may include:

• application availability;
• error rate and latency;
• successful authentication;
• payment or order completion;
• queue age and failed jobs;
• webhook delivery;
• database capacity;
• certificate expiry;
• backup completion;
• synthetic checks for a critical journey.

Each signal needs a threshold, destination, and owner. An alert that nobody receives is only a log.

Write the incident path before the incident

The plan should answer:

1. Who receives the first alert?
2. How is severity decided?
3. Who can change production?
4. When is rollback preferred?
5. Who communicates with stakeholders?
6. Where is the incident timeline recorded?
7. When is a follow-up review required?

For a small product, one person may fill several roles. The roles should still be explicit.

Useful incident communication states what is affected, when it began, what users should do, what the team is doing, and when the next update will arrive. It should avoid speculation presented as fact.

Make backups testable

“Backups enabled” is not the same as recoverability.

A maintenance plan should define:

• what data is backed up;
• how often;
• how long it is retained;
• whether backups are encrypted;
• who can access them;
• expected recovery time;
• acceptable data loss window;
• how restore tests are performed;
• when the last restore test succeeded.

The restore process deserves documentation. A backup that has never been restored is an assumption.

Plan dependency and platform updates

Updates need prioritization, not blind automation and not indefinite delay.

I normally separate them into:

• urgent security fixes;
• provider or platform deprecations;
• runtime and framework compatibility;
• routine patch updates;
• major upgrades that require planned product work.

Before applying an update, check release notes, compatibility, tests, migration requirements, rollback options, and production risk.

A major framework upgrade should not quietly enter a small bug-fix ticket.

Include security operations

Security is not completed by a launch review.

Ongoing work may include:

• dependency and platform advisories;
• access reviews;
• credential and key rotation;
• log review and alert tuning;
• suspicious request investigation;
• domain and certificate monitoring;
• data retention and deletion;
• provider permission review;
• vulnerability intake and response.

The plan should also define who can authorize emergency changes and how evidence is preserved without exposing private data.

Separate maintenance from product development

This distinction prevents recurring conflict.

Maintenance may include:

• fixing a regression;
• restoring a failed service;
• applying a supported security patch;
• routine monitoring review;
• small compatibility work;
• backup verification.

Product work may include:

• a new workflow;
• a new integration;
• changed business rules;
• redesign;
• major data migration;
• new reporting capability.

The contract should define the boundary, response expectations, and how out-of-scope work is estimated. Otherwise every request becomes an argument about the word “support.”

Keep a controlled change process

Even a small system benefits from a lightweight release record:

• request or reason;
• owner and approver;
• affected areas;
• risk level;
• test evidence;
• data or configuration changes;
• deployment time;
• rollback path;
• verification result.

This creates continuity when the original developer is unavailable and makes repeated failures easier to diagnose.

My production code-review checklist provides the technical questions before a release.

Review performance and cost

Maintenance is also the right time to notice gradual degradation.

Review:

• Core Web Vitals and important route performance;
• server response time;
• database query patterns;
• queue throughput;
• storage growth;
• provider usage;
• hosting cost;
• unused resources;
• cache behavior;
• traffic and error trends.

Do not optimize from a single isolated score. Use representative routes, real-user evidence when available, and a defined performance budget.

Schedule content and SEO hygiene

For public websites, technical maintenance should include:

• broken internal links;
• incorrect redirects;
• sitemap generation;
• canonical and language alternates;
• indexation changes;
• outdated claims and biographies;
• structured-data validity;
• missing or duplicated metadata;
• pages that no longer satisfy their intent.

Publishing more pages is not automatically the answer. Updating, consolidating, or removing unhelpful content can be the better decision.

A practical maintenance cadence

The exact cadence depends on risk, traffic, and contract, but a plan can use:

• continuous alerts for critical failures;
• weekly review of errors, failed jobs, and provider notices;
• monthly access, backup, cost, and performance checks;
• quarterly restore tests and roadmap review;
• scheduled review before provider or framework support deadlines.

Every item needs an owner and evidence of completion.

The handover question

At handover, I ask:

Can another authorized person understand the system, recognize a serious failure, reach the right account, and take the first safe recovery step?

If not, the project still depends on undocumented memory.

A maintenance plan turns that memory into an operating system for the software.

If you need a maintenance plan for an existing application, send me its main services, critical user path, and current support arrangement.