After launch, someone needs to look after the application, its data and the services it uses. The work depends on what people rely on: a content website and an application taking customer orders need different checks and recovery plans.
Before agreeing to maintenance, define what needs attention, who owns each responsibility and what evidence you will receive. Here are the questions I would work through with you.
Separate hosting, maintenance and new development
Hosting provides the infrastructure that runs your software. Depending on the service, it may also manage parts of security, certificates or backups. It does not mean anyone is checking that your checkout, sign-in or notifications still work.
Maintenance covers agreed work to keep the current product operating. New development changes what it does. A care plan may include time for both, but a redesign, a new payment flow or a substantial integration needs its own scope. Write down that boundary before work starts.
Also ask what support is included after the initial handover, for how long, and what it covers. Knowing where that support ends makes it easier to plan the ongoing work.
Keep dependencies supported and updates checked
Applications rely on libraries, frameworks and external services that change over time. Security fixes and support deadlines need attention. Updates should be assessed for your application and checked against important user flows before reaching production.
The schedule depends on the risk and the product. A relevant urgent security issue should not wait for an ordinary monthly update slot. Agree on how those issues are reported and handled, including work that falls outside the plan.
Know what is backed up and how to restore it
Code in a repository is only one part of recovery. Your product may also depend on customer records, uploaded files and service configuration. Ask what is backed up, how often, how long copies are kept and who can restore them.
Choose backup frequency around how much data you could afford to lose. For example, if the last successful backup was at midnight and a database failed at 5pm, restoring that copy alone would leave the day’s changes missing. A product taking orders may need a different recovery approach from a site whose content changes weekly.
Separately, agree on how long the product can be unavailable while it is restored. The amount of data you can recover and the time needed to recover it are different questions.
A successful backup notification does not prove the application can be restored. Test recovery in an appropriate separate environment and record the steps. The NCSC’s backup guidance also recommends checking that backups contain the important data and that you know how to restore them.
Monitor the things customers need
An uptime check can tell you that a page responds. It may not reveal that emails are failing, a background job has stopped, or a customer cannot complete a purchase. Decide which checks matter for the product and where failures should be reported.
Availability of the application and its important services.
Errors in critical flows, such as sign-in, checkout or booking.
Failed background jobs, notifications and third-party integrations.
Domain renewal, certificate status, storage limits and service usage.
Every alert needs a recipient and an agreed response. Define the hours when someone will respond, how an urgent issue is reported and who is contacted if that person is unavailable. A monthly plan does not imply 24-hour incident coverage; that needs to be explicitly agreed.
Ask what a response commitment means. Acknowledging an issue, starting an investigation and restoring the service are separate steps. The wording should make clear which step is covered and what happens next.
Review performance and access as the product changes
Data grows, new features arrive and users behave differently from test accounts. Review slow pages and costly operations when there is evidence of a problem. Start with the user impact, then investigate the cause instead of upgrading infrastructure by habit.
Review account access when people join or leave. Keep ownership and renewal details current, and document where the important services live. A product should not depend on one forgotten account that nobody on the team can recover.
Ask for a maintenance plan you can understand
Before agreeing to ongoing work, ask these questions:
Which application, services and environments are covered?
What checks and routine work will actually happen?
Who owns backups, restore testing, renewals and service bills?
What response hours apply, and how do I report an urgent issue?
How is time for fixes or improvements used, and what needs a separate quote?
What record of completed work and remaining risks will I receive?
What happens to access and documentation if we stop working together?
Ask for a written record of completed work and open issues. For example, a maintenance update might say:
Completed: updated the application dependencies and checked sign-in, password reset and the main booking flow in staging before release.
Recovery check: restored the latest database backup into a separate environment and checked a sample of records. File uploads have not yet been included in this restore test.
Needs a decision: storage usage is increasing. The options and expected impact are listed for review before any change is made.
That is an example of the level of detail to ask for, rather than a promise of a particular monthly schedule. Your plan should say which checks apply to your product and how often they happen.
Start with the product you have
For a first look at a public website, you can run my website health check or whole-site audit. They can surface issues worth investigating. They cannot inspect private application code or prove that your backups and customer workflows work.
If you would like ongoing help, tell me about your product, the services it uses and what you need covered. We can define a care plan around those needs, or scope a particular set of improvements first.