Every asset in this cluster sits somewhere on a spectrum, and almost nothing sits at either extreme. A domain isn't fully owned — it's a conditional, renewable registration governed by ICANN policy. A social media account isn't fully rented in the sense of having zero value to you — it's just entirely revocable by someone else's decision. The interesting question was never 'is this owned or rented,' phrased as a binary. It's 'who holds the option to end this,' which is a spectrum with a clear direction, even if nothing sits at its absolute ends.
What actually determines where something sits on this spectrum?
One question does almost all the work: if the provider decided, unilaterally and for its own reasons, to end this relationship tomorrow, could you reconstruct the value elsewhere — and how much would that cost you, in time and in money? A domain scores well here: move it to a new registrar, and nothing external-facing changes at all. A Wix site scores badly: the underlying design has no portable export, so 'moving' it means rebuilding it. A social media following scores worst of all: there's no reconstruction path whatsoever, because the relationship with each follower was never something you held independently of the platform showing them your content. Turning what's the difference between renting and owning your infrastructure into something a commercial team can run is the problem works on. Turning what's the difference between renting and owning your infrastructure into something a commercial team can run is the problem XenGrowth's revenue operations work works on.
Asset | Who holds the option to end it | Cost to reconstruct elsewhere |
|---|---|---|
Domain name | You — subject to ICANN transfer rules and a 60-day lock in some cases | Low — a transfer process, some friction, no rebuild |
Email on your own domain | You, if routed through a swappable managed provider | Low to moderate — repoint DNS, migrate mailboxes |
Website builder design (Wix, Squarespace) | The platform — no full export exists | High — a full rebuild of the design from scratch |
Cloud hosting account | The provider, per its terms of service, as AWS demonstrated with Parler | High if a suspension happens without warning; otherwise moderate for a planned migration |
Social media following | The platform, entirely | Effectively unrecoverable — there's no path to reconstruct the same relationship elsewhere |
Doesn't this just collapse into 'self-host everything'?
It's also worth being honest that 'own the core, rent the operations' has a cost of its own — it's more effort up front than simply accepting whatever a single all-in-one platform defaults you into. Buying a domain, configuring DNS, choosing a managed email provider and wiring it all together takes an afternoon that clicking 'sign up' on an all-in-one platform doesn't. That afternoon is the entire price of the ownership this post is arguing for, and it's worth being explicit that it is a real, if small, price rather than pretending the owned architecture is strictly easier in every respect.
No, and this is the part worth being careful about, because the framework can be misread as an argument for maximal self-sufficiency, which isn't what it's actually recommending. Owning the core — the domain, the identity, the data — while renting the operational layer built on top of it is frequently the right architecture, not a compromise. Google Workspace behind your own domain gets you address ownership without taking on mail-server operations. A CDN in front of your own site gets you performance and resilience without owning the physical infrastructure. The spectrum this post describes isn't 'own everything' versus 'rent everything' — it's about being deliberate regarding which specific layer you're renting, and confirming the layer underneath it, the one that actually identifies you, stays owned. If the operations side of this is the part you are stuck on, is the better reference. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
Are there layers that can never move to the 'owned' side, no matter what you do?
Yes, and being honest about this is what keeps the framework from overpromising. The domain registry itself — Verisign for .com, DENIC for .de — is a structural monopoly with exactly one operator per top-level domain. In May 2026, DENIC distributed faulty DNSSEC signatures and broke resolution for every DNSSEC-signed .de domain for roughly three and a half hours. No registrar choice, no DNS provider choice, no amount of careful planning by any individual registrant could have prevented that outage or diversified around it, because the registry itself has no competing alternative to switch to. This is the honest limit of the whole framework in this cluster: some layers genuinely cannot be moved toward ownership, and the practical response to those layers isn't better vendor selection — it's accepting the residual risk and planning your incident response around it rather than assuming a perfect setup eliminates it. Who Controls Your DNS, and What Is That Control Worth? covers this specific layer in more depth.
The goal was never a setup with zero rented dependencies — that setup doesn't exist. The goal is knowing exactly where your dependencies sit, so a provider's decision is a known risk you've planned for, not a surprise that reveals how little control you actually had.
Architecture pattern | What's owned | What's rented | Why this split works |
|---|---|---|---|
Domain + managed email provider | The address and domain identity | Mail delivery, spam filtering, storage | Deliverability is genuinely hard to run well; identity is what actually needs to survive a provider switch |
Domain + CDN in front of your own site | The content, the code, the domain | Edge caching, DDoS mitigation, global distribution | A CDN can be swapped without changing the address visitors use or the content they see |
Domain + managed hosting | The code and data (if regularly exported) | Servers, uptime, scaling | Hosting failures are common enough that provider flexibility matters more than owning hardware |
No domain, platform-only presence | Nothing durable | Everything | This is the pattern this whole cluster argues against — there's no owned core to fall back on |
The first three rows in that table are all legitimate, common, sensible architectures — none of them require self-hosting anything. What separates them from the fourth row isn't how much is rented. It's whether anything underneath the rented layer is actually owned, because that's the layer that has to survive if the rented part above it changes hands, changes price, or simply goes away. There is a longer treatment of AI agents and marketing automation in . There is a longer treatment of AI agents and marketing automation in XenGrowth on AI agents and marketing automation.
How does this play out across the cases this whole cluster has covered?
Every incident referenced across this cluster is the same underlying pattern, recurring at a different layer. Parler's AWS suspension: a rented hosting relationship, ended on the provider's timeline. Wix and Squarespace's export limits: a rented design layer with no path to ownership at all. The Google Domains sale to Squarespace: a rented registrar relationship, reassigned without customer input when the original provider exited the business. DENIC's 2026 outage: a layer that was never rentable to begin with, because there's no alternative provider in the market. Kremen v. Cohen: the one case in this whole cluster where a court drew a hard, tested line between property and license, and put a domain registration on the property side of it. None of these are separate problems. They're the same question — who holds the option — asked about a different layer of the same stack each time.
What should you actually do with this framework?
List every piece of your online presence — domain, email, website, social accounts, hosting — and apply the reconstruction test to each: what would it cost to rebuild elsewhere if this provider ended the relationship tomorrow
Prioritize moving the identity layer (your domain, your email address) toward ownership first, since everything else can be rebuilt on top of it, but nothing rebuilds cleanly if the identity itself is gone
Keep renting the operational layers that are genuinely expensive to self-manage — mail delivery, CDN, hosting — as long as the identity underneath them stays portable
Accept, rather than fight, the layers that structurally cannot move toward ownership (the registry itself), and plan your incident response for those specifically rather than assuming better vendor selection fixes them
Revisit this audit periodically — a setup that was fully owned at the identity layer two years ago can quietly drift back toward rented if a domain lapses or an account access process goes undocumented
There's a reason this pattern keeps recurring rather than being solved once and forgotten: every provider in this cluster has a business model that benefits, at least somewhat, from customers finding it hard to leave. That's not an accusation of bad faith — a website builder that let you export a perfect, portable copy of your design would be handing you the exact tool you'd need to switch to a competitor, and few businesses build that tool for free. Lock-in isn't usually a conspiracy. It's just what happens by default when nobody on the vendor's side has an incentive to fix it, and nobody on the customer's side asks the question early enough for it to matter. approaches this from the AI search, GEO and discovery side. XenGrowth on AI search, GEO and discovery approaches this from the AI search, GEO and discovery side.
None of the incidents across this cluster required an adversary, a mistake by the victim, or even bad luck in the ordinary sense. They required a provider making a decision in its own interest, which every provider is entitled to do, and every customer of every provider should assume will eventually happen. The only real defense is knowing, in advance, which parts of your online presence are built to survive that decision and which aren't — and doing that audit while the answer is still cheap to change, rather than discovering it for the first time on the day the decision actually lands and there's nothing left to do but rebuild. On the commercial side of building infrastructure that survives a vendor's own decisions, is a useful companion to this framework.
Further reading from XenGrowth
Where this work meets go-to-market
Auditing which parts of your business infrastructure are actually owned versus rented? publishes operator guides on building infrastructure that survives any single vendor's decisions.
Further reading from XenGrowth
Where this work meets go-to-market
For the marketing and revenue operations view of what's the difference between renting and owning your infrastructure, see .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of what's the difference between renting and owning your infrastructure, see XenGrowth's growth operations team.
Five questions applying the 'who holds the option to end it' test to real, documented cases from across this cluster.
