David Tovar · Practical guide
Handover begins a new stage
An application may need changes because your business evolves, an external tool changes or an incident occurs. Planning maintenance establishes who handles these situations and how they are prioritised, before a failure forces the decision.
Distinguish between correcting an agreed behaviour, adapting an integration and developing a new feature. The agreement should explain what is covered and how additional work is assessed.
Ownership and access that support continuity
Identify who administers the domain, hosting, repository and provider accounts. The business should know how to access the resources it is entitled to and which documentation another developer would need to continue the work.
Agree who receives alerts, which channel the team uses to report issues and what a report should include: the affected operation, when it failed and steps to reproduce it, without passwords or unnecessary personal data.
An example: a connected CRM changes
Imagine an integration stops saving requests because a provider changes its API. The homepage may still work while requests remain pending. Maintenance should cover detecting the issue, checking which operations completed and recovering the rest without creating duplicates.
This illustrates why checking that a website loads is not enough for an integrated application. Tests should cover the user’s main workflow.
What to specify in the agreement
Review updates, backups, recovery tests and the release procedure. A backup is useful when there is a tested way to restore it; it also matters which data it contains and how much work could be lost.
Support hours, response times and priorities are agreed around business needs. New features can be organised as an ongoing engagement, separately from incident support so both have clear priorities.
Discuss your project
I’m David Tovar. If you want to apply these ideas in your business, we can review your requirements and the options for developing a solution.