Most companies think they own their website. They paid for the design, they pay the monthly bill, their logo is on it. Then the platform changes its pricing tier, or the page builder they standardised on gets acquired, or the theme that made the site look expensive stops receiving updates, and they discover the truth: they were renting, on terms they never read, with an eviction clause they never priced.
Platform risk is not a doomsday scenario. It is a slow, ordinary cost that arrives as a renewal email. Here is how to see it before the invoice does.
What renting your website actually means
You are renting when you cannot stand up a working copy of your site on infrastructure you choose, from artefacts you already hold, without asking anyone's permission. Payment is not the test. Control is. If the answer to "where is the source, and can we deploy it elsewhere" involves a support ticket, you are a tenant.
There is a spectrum, not a binary:
- ▸Full tenancy. Closed hosted builders where the site exists only inside the vendor's editor. You can usually export HTML that looks like your site and behaves like a scrapbook of it.
- ▸Partial tenancy. Self-hosted open-source CMS plus a proprietary page builder and a premium theme. The platform is portable, your actual pages are not, because their layout lives in vendor-specific data structures.
- ▸Ownership. Source code in a repository you control, content in a database you can dump, infrastructure defined in files, and a deployment that runs without any vendor's licence server answering.
Most SMEs sit squarely in the middle band and believe they are in the third. That gap is the risk.
The five levers a platform can pull on you
A platform you depend on has five ways to change your economics without your consent: raise the price, change the tier boundaries, deprecate what you use, restrict export, or disappear. None of these require bad faith. They are normal commercial behaviour, and your contract usually permits all of them.
- ▸Price and tier changes. The lever is rarely the headline price. It is the boundary: a feature moves from your plan to the plan above, or usage limits tighten, and your bill doubles without any change on your side.
- ▸Deprecation. The vendor sunsets the API, editor, or integration your site depends on. You get a migration window and an unbudgeted project.
- ▸Acquisition. A plugin or theme with a dozen active installs of yours is bought. The new owner monetises differently, or lets it rot. Both are common.
- ▸Export restriction. You can get your content out and not your structure: no templates, no custom fields as they were configured, no redirect map, no form submission history.
- ▸Shutdown. Rare, loud, and survivable only if you already hold a deployable copy.
The pattern is identical to what happens one layer up the stack with business software, which we set out in The CRM Exit-Readiness Audit: Lock-In Mechanisms Hiding in Your SaaS Contract. The website is simply where most companies notice it first, because the website is the asset they thought was theirs.
Plugin abandonment is a supply chain problem
An unmaintained plugin is not just a stale feature. It is executable code running inside your site with the same privileges as everything else, and when maintenance stops, so does the security patching. The class of risk here is well documented: the majority of compromises on popular open-source CMS platforms trace to extensions rather than to the core.
The mechanism matters more than any headline count:
- ▸Extensions run with full trust. In most CMS architectures a plugin can read the database, write files, and call out to the internet. There is no meaningful sandbox.
- ▸Abandonment is silent. Nothing in your dashboard says "the author stopped answering issues fourteen months ago". The plugin keeps working, and keeps its privileges.
- ▸Disclosure creates a race. When a vulnerability in a widely installed extension becomes public, automated scanning follows quickly. An unmaintained plugin has no patch to race toward.
- ▸Removal is not free. The plugin that ran your forms, your redirects, or your layout is load-bearing. Removing it after abandonment means rebuilding the feature under time pressure.
Verify the maintenance status of anything you depend on directly at the vendor or repository, and do it on a schedule rather than after an incident. Every extension you keep is a supplier you did not vet.
What "you own the code and the data" has to say on paper
Ownership is a contract clause, not a feeling. If your agreement does not name the deliverables, assign the intellectual property on payment, and grant you the credentials, you do not own the site regardless of what anyone said in the kickoff meeting. Three sentences in a contract prevent most of this.
Insist on the following, in writing:
- ▸Assignment of IP on final payment. All bespoke code, templates, and design assets transfer to you. Where the agency reuses an internal framework, you get a perpetual, irrevocable, transferable licence to use and modify it. Both outcomes are acceptable. Ambiguity is not.
- ▸Named third-party components. A list of every open-source and commercial dependency, its licence, and who holds the licence key. A premium theme licensed to the agency is a dependency on the agency.
- ▸Repository and infrastructure access from day one. Not "on handover". You should hold owner rights on the code repository, the domain registrar, the DNS zone, and the hosting account throughout the build.
- ▸A documented, tested restore. The contract should require a deployment runbook and at least one rehearsed restore into a clean environment. Untested backups are folklore.
- ▸No dead-man switches. No licence server, no phone-home, no component that stops working if a subscription lapses on someone else's card.
None of this is aggressive. A supplier who will not put those five points in writing is telling you something useful about the relationship you are about to enter.
The EU angle: data location, GDPR duties, and exit rights
If you are established in the EU or serve EU residents, GDPR duties follow the personal data your website collects, wherever it is hosted. Your platform is almost always a processor, so you need a processing agreement, a record of what is collected, and the ability to fulfil access and deletion requests. Verify your own position with counsel.
The practical, non-legal-advice checklist:
- ▸Know where the data physically sits. Form submissions, analytics, session recordings and backups may live in different countries than your pages. Ask for the list, in writing, per subprocessor.
- ▸Hold a data processing agreement with every processor. Platform, host, email provider, analytics, chat widget, CDN. If a vendor cannot produce one, that is your answer.
- ▸Check subprocessor change notice. Many contracts let the vendor add subprocessors with short or no notice. Negotiate notice and an objection right where you can.
- ▸Test deletion end to end. A deletion request that clears the CMS but leaves the record in a third-party form service is not fulfilled.
- ▸Treat exit as a design requirement. Regulatory attention across the EU has been moving toward easier switching between digital services, which is a helpful direction, but do not wait for a rule to make your exit possible. Build the exit yourself.
For the wider picture on where systems and data should live, see EU Data Residency: Why Where Your Data Lives Matters in 2026 and Renting Software Is Renting Sovereignty: Why the EU SaaS Exit Ends in Custom Code.
What ownership does not buy you
Owning your code is not free and does not make maintenance disappear. It converts an unpredictable rent into a predictable operating cost that you control. You still patch dependencies, renew certificates, monitor uptime, and pay someone to care. Anyone selling ownership as the end of ongoing cost is selling badly.
Be honest about the trade:
- ▸You inherit the patching. Framework and library updates become your responsibility, typically a modest recurring budget rather than a monthly per-seat fee.
- ▸You need a person or a partner. Ownership without an operator is just a slower kind of abandonment.
- ▸Change velocity shifts. Adding a landing page may need a deploy rather than a drag-and-drop, unless you deliberately keep an editable content layer.
- ▸The build costs money up front. The honest year-two arithmetic is laid out in Custom Software Is Also a Subscription, to Yourself: The Honest Year-Two Ledger.
A one-hour ownership audit
Run this before your next renewal, not after. Set a timer, answer each question with a yes or a no, and write the name of the person who holds each credential. Any question you cannot answer in under five minutes is already a finding.
- ▸Can we deploy a working copy elsewhere this week using only artefacts we hold today, with no vendor approval?
- ▸Who is the registrant of the domain, and who controls the DNS zone? If it is an agency employee's personal account, fix that today.
- ▸Can we export content, structure, redirects and form history, or only content?
- ▸Which components are proprietary, and whose name is on each licence?
- ▸When was the last successful restore test, and who watched it happen?
- ▸What is the twelve-month cost if every platform and plugin in the stack raises prices by thirty percent?
Score it honestly. Companies that get past this audit tend to have built a deliberate exit, the pattern described in Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software.
How TuniCyberLabs helps
We build websites and platforms you actually own: source in your repository, infrastructure as code, EU or North Africa hosting of your choosing, no licence servers, and a handover that includes a rehearsed restore. Where a rebuild is not justified yet, we run the ownership audit against what you have and hand you a prioritised list of what to fix, renegotiate, or leave alone.
Bring us your current stack and your next renewal date: book an ownership review.