Website maintenance and development

We hand over access and instructions, record a working release and document connected services. We then agree how to continue: individual tasks or ongoing support. The client has a clear point of contact for questions about the product.

Warranty corrections are separated from new functionality. Warranty terms are defined by the contract; an extension to the agreed scope is estimated separately. Support does not mean the website must be rebuilt every month.

A useful request includes the page URL, expected outcome and current behaviour. For a fault, include its time, device and steps to reproduce it. Passwords and personal data should not be placed in a publicly accessible task description.

We assess business impact first: an unavailable service, a broken essential journey or a planned improvement. Response time and resolution time are different measures. Working hours, priorities and emergency contact arrangements are agreed in advance; round-the-clock staffing is not included by default.

Changes are prepared in a separate staging environment. Before release, we check dependencies, the backup and a recovery plan. Staging is access-restricted, excluded from indexing and disconnected from real payments and notifications.

Testing goes beyond opening the homepage: enquiries must be stored, messages sent and orders delivered to the back office. Essential checks are repeated on production after deployment. Automated checks complement manual interface review.

A file archive without a database will usually not restore the entire product. We define backup coverage, frequency, retention and storage outside the primary server, together with access to that data.

A restoration test establishes whether the project can actually run from a backup. Acceptable data loss and recovery time depend on order volume and update frequency. Restoring an old database may erase enquiries received since the backup, so rollback must account for new data.

URL availability, application errors, disk capacity and queue state answer different questions. A server may return a successful response even when emails are no longer sent. Monitoring is therefore designed around meaningful journeys, rather than one green indicator.

Alerts and responsible people are defined within the agreed scope. Each incident records the cause, action and verification. Recurring failures become tasks to remove their cause rather than a permanent manual workaround.

Before adding a feature, we identify how it changes data, permissions and the interface. Small changes receive individual estimates; larger work is divided into design, implementation and verifiable milestones. This keeps product development understandable.

Instructions are updated when the interface changes. Reports record completed tasks, time spent, released versions and the next plan. Code and documentation should explain how the product works and how to maintain it.