Ownership & operations
Plan who will own the system
Ownership means being able to access, understand and change a system—or choose someone who can. Possessing the code alone is insufficient.
Pattern Engine · Practical field notes
A business can own every line of its software and still be unable to change it. The only deployment account may belong to a former contractor. Nobody may understand an important rule. A recovery procedure may depend on the person who is unavailable.
Ownership is practical when the organization can access the system, understand its important behavior and arrange a safe change. Legal rights and delivered files matter, but they do not establish those abilities by themselves.
Separate control from self-sufficiency
Owning a system does not require doing all its maintenance yourself. It requires enough control to choose who does that work and enough understanding to recognize whether the arrangement is adequate.
For a small scheduling application, an operations lead might own priorities and user access while an external engineer maintains the implementation. The business should be able to replace that engineer without losing its accounts, records or explanation of the rules.
The GOV.UK guidance on running a live service treats support and continued improvement as part of delivery. At a smaller scale, the same principle can mean a modest support arrangement and a usable handover. The test is whether responsibility can transfer, rather than whether every capability sits inside the company.
Check control of the essentials
Before accepting a handover, confirm that the organization can access the assets it depends on. A practical inventory includes:
Domain registration, hosting and billing accounts.
Source code, deployment instructions and configuration records.
Data storage, backups and tested export procedures.
Third-party services, integrations and renewal dates.
Administrator access, recovery methods and support contacts.
Access should use appropriate organizational accounts and permissions. Avoid a setup in which a former employee’s personal email is the only recovery route for a critical service. Record where credentials are managed without placing secrets in ordinary documentation.
Match the system to available capacity
A tool that requires daily specialist attention may be unsuitable for a team that can provide only occasional administration. Ask what routine work the system creates and who is expected to perform it.
Have the intended operator carry out common tasks before launch: invite a user, correct a record, find a failed job and request help. Their experience is stronger evidence than an assurance that the dashboard is easy to use. If the handover requires extensive explanation, simplify the process or provide a clearer support arrangement.
Make support specific
Distinguish fixing a defect, maintaining dependencies, answering user questions and developing new features. A vague promise to “support the system” can hide very different expectations about availability and cost.
Agree on the contact route, response expectations and what information makes a report actionable. Include a route for urgent disruption and a plan for ending or transferring the relationship. These are operational decisions to make together, not details to discover in a crisis.
Our test is simple: could another capable person take over the responsibility with the access and information provided? Documentation and handover explains how to make that transfer practical without producing a binder nobody uses.