Wall & FifthMaintenance & Support
Launch is a milestone.
Care comes next.
Decide who maintains the product, who responds when something changes and what recovery should look like. Put the agreement in place before you need it.
The principle
Confidence starts with knowing the arrangement.
You should not have to guess who to contact or what is included. A useful support plan makes the practical details visible: what is being looked after, when help is available and what happens next.
Post-launch support should define covered systems, support hours, responsibilities, response targets and costs. Build defect cover, routine maintenance, new features and incident assistance are different services and need clear boundaries.
The support agreement
Make the cover specific.
A build agreement may include a period for correcting defects against the agreed specification. That is different from an ongoing commitment to monitor services, update software or respond to incidents. Your contract determines which cover applies.
For ongoing care, discuss the systems included, service hours, contact route, prioritisation, response targets and the work allowance. A response target is not a guaranteed time to resolve every issue, particularly where third-party services are involved.
- Build defect cover
- Corrections against the agreed specification, for the period and terms in your project agreement.
- Ongoing maintenance
- An agreed schedule and scope for updates, checks and operational work.
- Product development
- New features and larger changes, with their own priorities and estimates.
Updates & monitoring
Keep the product’s foundations current.
Frameworks, dependencies and integrations change over time. Maintenance needs a way to review relevant updates, prioritise security fixes and check important customer journeys before a release goes live. The cadence should match the product and the level of support agreed.
Monitoring also needs an owner. Uptime checks and error alerts are useful only when somebody is responsible for reviewing them and taking action. Agree which signals are monitored, who receives them and what happens outside support hours.
Hosting fees, monitoring tools, backup storage and other provider charges may sit outside a maintenance fee. Keeping those costs explicit helps you understand the real operating budget.
Backups & continuity
A recovery plan you can understand.
Decide what needs backing up: the database, uploaded files, configuration and other business-critical information. Source control preserves code history, but it is not a backup of the live customer data stored elsewhere.
Recovery planning should define how much recent data the business could tolerate losing and how long it could operate without the service. These are often called the recovery point objective and recovery time objective. They guide the backup and recovery design; they are not automatic guarantees.
Backup frequency, retention, access and restoration checks need to be agreed against the chosen provider and plan. A stored backup is useful only if the right person can restore the right information when required.
When something goes wrong
A clear route to the right people.
An incident arrangement should identify the reporting channel, the person coordinating the response and the providers or specialists who may need to be involved. It should also define authority for actions such as disabling access or pausing a service.
Investigation, containment, recovery and communication can require different skills and decisions. Any specialist incident-response work or independent assessment should be expressly covered or commissioned when needed. Do not assume a development retainer includes a continuously staffed security operation.
Our Embedded Partner offer covers broader product and commercial work. Any operational maintenance or incident assistance needs to be agreed explicitly alongside that relationship or in a separate support arrangement.
Understand Embedded PartnerClarity from the start
The right protection.
The right agreement.
Your product’s risks, controls and support needs belong in the project conversation. We’ll help you define the brief and identify what needs a separate assessment or specialist input.
Talk through your requirementsStraight answers
Before you
put your trust in it.
Is support included after launch?
Your project agreement sets out any included defect-fix period. Ongoing updates, monitoring, incident assistance and feature development should be agreed separately where required. Ask us to help define the arrangement before launch.
Is support available 24/7?
Do not assume round-the-clock cover. Support hours and any out-of-hours escalation need to be explicitly agreed. Monitoring software running continuously does not mean a person is available continuously.
How often will my data be backed up?
That depends on the provider, plan and configuration agreed for the project. The support brief should record frequency, retention, access, restoration checks and the level of potential data loss the business can tolerate.
Can another team maintain the product?
A handover should make that possible with the relevant source code, documentation and properly transferred account access, subject to your agreement and third-party licensing. The incoming team also needs a clear understanding of the infrastructure and existing responsibilities.
How do I report an urgent issue?
Existing clients should use the contact route in their support agreement and the relevant provider’s incident channel where appropriate. The general contact form is for project enquiries; it does not establish an emergency response time.
Keep exploring