The useful starting point
Agree responsibility across the whole product. Ongoing engineering needs a clear scope, a release process and an understanding of the systems around the apps.
Start by drawing the product boundary
List the applications, services and operational tools the engineering team is expected to maintain. Include the accounts and outside providers they depend on. The word “support” is too broad to serve as the whole agreement.
Ask who takes responsibility for an app release, a failing integration or a change needed by the operation. A shared understanding of the boundary makes it easier to prioritise work and identify when another party needs to be involved.
Turn ongoing support into visible work
Illustrative example · a sample delivery cycle, not a promised schedule or response-time agreement
| Stage | Work to make visible | Artifact a product owner can review |
|---|---|---|
| Understand | Reproduce the issue or define the change | A short problem statement and acceptance examples |
| Plan | Identify affected applications, services and dependencies | A bounded scope and remaining unknowns |
| Implement | Make the agreed change and review its effects | A reviewable change with relevant tests |
| Release | Deploy through the agreed process | A release record, checks and a recovery approach |
| Observe | Check the behaviour that justified the change | A result against the acceptance examples and follow-up work |
The sequence can apply to a defect, a provider change or a small feature. Its value is the connection between a reason for doing work and evidence of what was delivered. The cadence and availability arrangements should be agreed separately.
Prioritise by the effect on the product
A backlog can contain an uncertain transaction state, a dependency update and a requested screen improvement at the same time. A useful conversation makes their consequences visible rather than treating all three as interchangeable tickets.
| Work item | What to establish before deciding |
|---|---|
| A transaction cannot be explained | Which users or operations are affected, whether money movement is uncertain and who is investigating |
| An outside service is changing | The required date, affected journeys and what needs testing before the change |
| A new feature is requested | The user need, first useful scope and dependencies on other work |
| Routine maintenance is due | Why it matters, the risk of delay and an appropriate release window |
These categories help organise a decision. They are not a universal priority policy or an implied support agreement.
Keep continuity transferable
The team that knows the product should still leave a clear trail for the next person. Useful handover material includes account ownership, the deployment path, current dependencies, significant design decisions and a record of changes that affect operations.
Our payments case shows a relationship that continued from an inherited codebase into multiple products and ongoing work. The practical value to discuss with a new client is how that continuity would be made visible and maintained for their product.
Keep releases connected to the operation
A change in a payment journey can affect more than the screen where it appears. The team should understand the related service calls, operational views and expected behaviour when an outside system responds differently.
Agree how changes are tested, reviewed and released. The useful question is whether the people making a change can explain its effect on the running product and how they will check that it behaves as intended.
Make room for maintenance and improvement
A live backlog includes defects, dependencies, release work and improvements requested by users or the business. Make those categories visible so decisions about them are explicit.
Planning every available hour around new features can leave routine engineering work without an agreed place. Discuss how the team will balance the next product goal with the work needed to keep making changes.
Keep knowledge accessible
Continuity helps when a team understands why the product works as it does. Documentation, accessible accounts and a clear record of significant changes also matter, including when the same team stays for years.
- Which parts of the product are in the agreement?
- Who owns the accounts and release access?
- How are changes prioritised and demonstrated?
- What is the process for an urgent issue?
- What would a future handover need to contain?
Exact availability, response arrangements and commercial terms should be agreed for the engagement. They cannot be inferred from a general promise of ongoing support.
Continuing engineering across apps and services
Our payments relationship continued from an inherited codebase through consumer apps and a business portal. The wider engineering work also includes mobile-device test rigs and API collections, alongside banking and payout integrations and operational systems.
That breadth explains why the delivery cycle needs visible evidence across more than the app interface. A product change can depend on a service response, a mobile journey and an administrative view. The exact checks should follow the change being made, rather than treating every release as the same checklist.
The payments case records the continuing engagement. Scope, availability and response arrangements for another client would be agreed for that product.
Common questions
Does ongoing engineering mean unlimited feature work?
It needs an agreed scope and a way to prioritise. Maintenance, urgent issues and product changes can compete for the same team’s time, so the arrangement should explain how those decisions are made.
What should we check before switching teams?
Confirm access and ownership, the release process, critical dependencies, current issues and the documentation needed to keep the product running. Agree the handover responsibilities before moving them.