Define the role
The operational owner does not need to write every line of code. The owner must be able to:
- identify the current live version;
- receive and triage user-impacting failures;
- add and remove access;
- coordinate dependency and platform updates;
- verify backups and restores;
- approve or route changes;
- manage provider and cloud accounts;
- maintain a support and escalation path; and
- transfer or retire the system.
Work may be delegated to a vendor. Accountability for knowing who is doing it and whether the service is working remains named.
Google's toil framework helps identify manual, repetitive, reactive operational work. A small business should not copy a large SRE organization, but it should avoid pretending recurring work disappears because an app has few users.
Apply the hard stop
Do not build when the proposed owner:
- has no allocated time;
- lacks required account access;
- cannot authorize incident containment or rollback;
- has no backup person;
- cannot obtain support from the builder;
- has no budget for hosting, updates, and repair; or
- is the temporary employee or friend who created the prototype.
The enthusiasm of the original builder is not a succession plan.
Consider alternatives first
Choose an established product when it solves the important job and bundles an acceptable operating model. Choose a configurable platform when the business can own configuration and administration without owning a complete runtime. Choose a genuinely managed arrangement when responsibilities, response, recovery evidence, change work, and exit are written down.
Garden's fleet-governance page is one first-party example of managed visibility a buyer can inspect. It says the current pilot exposes owner context, app stage, live releases, and failures, then hands changes to the responsible owner's workbench. That reinforces this hard stop rather than removing it: the same page says fleet visibility does not replace application-specific backup, restore, or incident response.
Narrow the custom boundary when one distinctive workflow justifies code but identity, storage, payments, or records can remain with proven systems.
Use the owner acceptance card
Before approval, fill in:
| Field | Required answer |
|---|---|
| Named owner and backup | People, not a department |
| Weekly capacity | Time reserved for routine work |
| Incident authority | Actions allowed during failure |
| Account control | Cloud, repository, domain, data, support |
| Evidence | Health, releases, backup and restore records |
| Vendor boundary | Included, excluded, response, escalation |
| Replacement | How another operator assumes the role |
If any required row is blank, the decision is investigate, not build.
Revisit the decision after launch
Ownership can decay when staff leave, vendors change, or the application becomes more important. Review the card quarterly and whenever the system adds external users, sensitive data, integrations, money movement, or regulated records.
The recommendation is simple: buy or configure when those models provide a better owner; build narrowly only after a person accepts the role and the business funds it; do not build when operation remains everybody's implied side job.