This is a planning framework, not a client case study, a description of existing support engagements or a standard Tanvora quote. Support terms must be agreed for the system and the people responsible for operating it.
Begin with the responsibility map
List the production services, deployment accounts, data stores and third-party integrations. For each, identify who monitors it, who may make changes and who handles an incident. A support agreement should close gaps in that map rather than merely reserve an unspecified amount of development time.
Distinguish launch support and any agreed warranty from ongoing maintenance and product development. Work that belongs to an unfinished build should not quietly become a new retainer obligation.
Separate maintenance, incidents and changes
Maintenance can include dependency updates, backup checks and access reviews, as agreed. Incident work responds to a failure or suspected security issue. Product changes add or alter behaviour. Each category needs a clear intake and approval process.
A defect is evaluated against the agreed acceptance criteria. A new request is evaluated against scope and capacity. Whether either is included, chargeable or covered by warranty must be written in the engagement terms; the label alone does not decide the commercial outcome.
Make incident coverage specific
Agree severity definitions, operating hours, notification channels and an escalation owner. State response expectations separately from investigation, workaround and resolution expectations. Third-party outages and missing access should have explicit handling rules.
Do not infer continuous coverage from the presence of a support inbox. The contract should say who is reachable, when they are reachable and how the buyer escalates if the expected response does not arrive.
An illustrative support-scope discussion
Consider a stable internal application with an external accounting connection. The business wants maintenance and incident help, while new reporting features need separate approval. This is an illustrative scenario, not an account of a retainer Tanvora operates.
The support scope could list dependency review, backup verification and integration-error triage. A failed posting could enter the incident process; a new report could enter change planning. The monthly record could explain what changed, what remains unresolved and what requires a decision.
The right capacity and fee would depend on the agreed coverage and actual system demands. This article asserts no hourly allowance, recurring price, response-time guarantee or relationship to the original build cost.
Reporting and exit
Keep a shared record of incidents, releases, open risks and approved changes. Include the evidence needed to understand recovery checks and any outstanding maintenance.
Agree renewal, termination and handover terms before the arrangement starts. Document how account access, repositories, operating instructions and unresolved work would transfer to another responsible team.
Turn the framework into a support plan
The post-launch support approach is the relevant next step: agree the support scope, incident expectations, maintenance responsibilities and change process in the proposal. It describes how to frame the engagement, not proof of past retainers. Discuss your project with the current system, its operating owner and the coverage you need.