Model five layers of ownership
Code ownership means the business can inspect, build, license, and change the source. The practical test is whether a qualified replacement team can produce the same artifact from the transferred repository and instructions.
Account ownership means the business controls the cloud tenant, domain, identity provider, source host, billing relationship, and recovery contacts. A vendor-controlled production account creates leverage even when the contract says the customer owns the code.
Data ownership means more than a download button. The business needs a usable export, field definitions, file relationships, retention rules, and a way to verify completeness. An opaque database dump may preserve bytes without preserving a usable business record.
Operational ownership means someone can identify the live version, observe health, respond to an incident, restore required state, rotate credentials, and apply updates. Google's discussion of operational toil is helpful because it makes recurring human work visible instead of hiding it behind the word “maintenance.”
Exit ownership means the business can transfer or retire the system without the original builder's cooperation. That requires current access, documentation, known dependencies, export procedures, and a rehearsed handoff.
Separate observed evidence from the thesis
The Reddit discussions behind this article repeatedly confuse code possession with independence. That is a problem signal, not market proof. The strategic thesis is that value will accrue to operating models that make all five layers transferable while reducing the customer's recurring burden.
The NIST Secure Software Development Framework supports a lifecycle view: protecting software, producing well-secured releases, responding to vulnerabilities, and retaining evidence are continuing practices. It does not establish that customer ownership is always better than SaaS.
Garden's customer-cloud architecture offers one current first-party example to test against the five-layer model. It places application source, runtime, data, secrets, logs, and infrastructure state in the customer's Google Cloud project, but says portability still requires dependency, data-format, and independent-operation knowledge. The documentation shows an operating-model claim; it does not prove lower customer burden, successful handoff, or a durable business advantage.
Test the counterargument
The strongest counterargument is that customers rarely want operational ownership. They want outcomes. A well-run SaaS vendor may deliver better availability, recovery, security work, and product improvement than a small business could achieve in its own account.
That counterargument wins whenever customer control adds work without creating meaningful bargaining power, resilience, regulatory fit, or differentiation. The ownership stack is therefore not a recommendation to own every layer directly. It is a way to identify who controls each layer and whether the arrangement can change.
Use an ownership failure test
Score no points for contract adjectives. Ask one failure question per layer:
| Layer | Failure test |
|---|---|
| Code | Can a replacement builder reproduce the live artifact? |
| Accounts | Can the customer remove the current operator without losing production? |
| Data | Can the business restore a usable record somewhere else? |
| Operation | Can a named person diagnose and recover a failed critical workflow? |
| Exit | Can the system be transferred or retired on a defined timetable? |
An investment thesis should also name disconfirming evidence. If customers consistently refuse account control, never use export rights, and renew because managed convenience dominates, ownership may be positioning rather than a durable advantage. If handoffs are faster, outages are easier to recover, and switching costs fall without increasing customer labor, the stack may describe a real operating moat.