Establish what is being supported
We identify the application, hosting, database, external services and people responsible for each dependency. This matters when a visible website fault is actually caused by email delivery, an expired service subscription or a vendor interface.
The scope should distinguish corrective maintenance, routine updates, operational monitoring and new development. Calling everything support makes expectations difficult to manage and hides the cost of substantial changes.
Understand faults before patching them
A useful incident description includes what happened, who was affected, when it began and a way to reproduce the issue where possible. Logs, error records and recent release information can help distinguish a one-off symptom from a recurring cause.
We agree the urgency and a practical response for the problem. Availability and response commitments must be part of the service agreement; they should not be implied by a generic promise of ongoing support.
Make changes traceable
- Record the requested behaviour and affected journeys.
- Use a suitable test environment before a production release.
- Keep configuration and required access documented.
- Identify dependencies and recovery steps.
- Check the released behaviour and communicate any exceptions.
- Retain enough release history for another developer to understand what changed.
The process should fit the system. A simple content correction and a database schema change need different levels of preparation.
Backups and continuity
Having a backup file is not the same as knowing the application can be restored. We establish what data and configuration are covered, who holds the copies and how restoration can be checked within the agreed scope.
Source code, hosting accounts and critical vendor access should not be known only to one individual. Continuity includes leaving the system in a state another competent team can understand if your arrangements change.
Maintenance or modernisation?
Some problems can be resolved with a bounded improvement. Others keep recurring because a dependency, release process or application structure needs more substantial work. We distinguish those decisions and explain the trade-off.
Send the platform details, current support arrangement, known issues and the systems affected by downtime. We can then propose defined support responsibilities rather than a vague retainer whose boundaries become apparent only during an incident.
Common questions
Do you support systems built by another developer?
A takeover may be possible after assessing code, access, documentation and dependencies. We need to understand the condition before accepting responsibility.
Does maintenance include new functionality?
Only when agreed. New features, substantial integrations and redesigns should have explicit scope rather than being assumed to fit within ordinary support.
Is round-the-clock support included?
No such commitment should be assumed. Coverage, escalation and response arrangements must be agreed specifically for the service you buy.