Separate fixes, operations and development
Different tasks arise after launch. One concerns a bug in an agreed feature, another an environment update and a third a new business request. Calling all of them “support” makes it difficult to compare proposals and plan the work.
List bug fixes, regular technical maintenance and further development separately in the agreement. A new integration or catalog redesign usually needs its own estimate, even when the team already maintains the website.
Define responsibilities too: who owns the domain, server, email, external services, content and analytics? A contractor's contact details do not replace a process owner within the company.
AI-generated illustration. A backup is verified by restoring it and completing working journeys in a separate environment.
Monitor user journeys
A server response confirms application availability but does not prove that a customer can submit an inquiry. Forms, account login, checkout and notifications need separate checks.
Choose a few important journeys and agree on how often to check them. For a service website, this could mean submitting a test inquiry and confirming that a manager receives it. For a store, it could mean completing an agreed test order without an actual charge.
Every signal needs a recipient. If incident notifications go to an inbox nobody reads, monitoring does not help restore service. Check contact details, a backup communication channel and the escalation process.
Test restoration from a backup
Backups need to cover the data required to restore the project: the database, uploaded files and necessary settings. The specific method depends on the system. For example, the PostgreSQL documentation describes several database backup approaches; copying the website directory is not a universal substitute for them.
The mere existence of an archive does not show that the data can be recovered. A useful test is to restore the backup in a separate environment and follow the main journeys. The live database must not be used as a training ground for restoration.
Discuss acceptable loss of recent changes and the expected recovery time. These are different constraints. They determine backup frequency, retention and preparation of a recovery environment.
Response time and resolution time differ. Every signal needs a recipient and a response process, while backup data is verified independently of code releases.
Plan updates and rollback
Updating the application, a library or the server can affect forms, images and external connections. Support should therefore include checks before publication and a brief check afterwards.
Before making a change, understand how to return to a working version. For code, this could be the previous application image; for data, it requires a separate compatibility and restoration plan. Returning to old code does not always undo database changes.
Maintenance frequency and urgency depend on the project's condition. Updates are not equally critical; discuss priorities based on their effect on security, availability and user journeys.
Define the response process for requests
Response time and resolution time are not the same. The former specifies when the team will start investigating, while the latter depends on the cause and the availability of external systems.
Clarify support hours, the channel for registering tasks and urgency criteria. A broken payment flow and a request to replace an image require different responses. For a serious incident, identify in advance who can approve temporarily disabling a feature.
A regular report can be brief: completed work, check results, issues found and next actions. Its purpose is to show the project's condition and the decisions needed from its owner.
What to give the support team
Before work begins, prepare:
- a list of domains, environments and external services;
- owners for content and technical matters;
- the main user journeys;
- a description of current backups and the last restoration test;
- the update and rollback process;
- agreed contact hours and request priorities.
Service terms depend on the system and scope of work. Discuss them in the website support section or describe your task to the DDRW team.
