What depending on an agency looks like
Dependence rarely shows up on launch day. It shows up three months later, when someone needs to change a phone number in the footer, add a job opening or publish an article, and the only way is an email to the agency and a wait. Then come the harder cases: the domain was registered in the agency's account, nobody in the company has the hosting password, a plugin licence expires on a card that is not yours, or the theme was customized so heavily that every update breaks something.
It helps to separate two kinds of change. Content changes are text, images, a new article, a new page built from an existing template. Structure changes are a new page type, a new field, a new form that sends data somewhere, an integration with the CRM. A well set up site lets your team make every content change alone. Structure changes will always need a developer, but they should be possible for any competent developer, not only the one who built the site.
Four things that decide independence, whatever the CMS
1. The content model
The content model is the list of content types (page, article, service, job, case study) and the fields each one has. When the model matches how your company thinks, an editor finds the right place for every piece of content. When everything is one long page with free-form blocks, the site looks good at launch and drifts after six months, because each person improvises.
2. The editor experience
The editor is the screen your marketing or sales colleague sees when publishing. The test is simple: can a person who did not build the site add a page, change an image and publish a correction in under an hour, without breaking the layout? If the answer needs a call to the agency, the CMS brand did not matter.
3. Accounts and hosting in your name
The domain, the DNS, the hosting, the CMS licence or subscription, the code repository, analytics and every paid plugin should sit in accounts owned by the company and billed to the company. The agency gets its own user, which you can remove. This is the single most important item, and it costs nothing at the start of a project.
4. The handover
A handover is documentation plus a session with the people who will run the site: how the content model works, how to add each type of page, how updates are applied, how to export everything. Without it, the knowledge stays in the agency's heads, whatever the CMS.
The four options, defined
WordPress: the open-source default
WordPress is an open-source CMS released under the GPLv2 (or later) licence. It runs on almost any hosting provider, and it is the most widely used CMS by a wide margin: 39.6% of all websites, according to W3Techs. In practice this means that if your agency disappears, finding another developer is easy. Its built-in export creates an XML file (WXR) with posts, pages, custom post types, comments, custom fields, categories, tags and users, which can be imported into another WordPress site (WordPress documentation). The lock-in risk is not WordPress itself but what is built on it: a custom theme only the agency understands, a heavy page builder, dozens of plugins with licences in the agency's name.
Webflow: a hosted visual builder
Webflow is a hosted platform where the design, the CMS and the hosting live together. Content editors can update text and CMS items without touching the design, and nobody has to apply server updates. The trade-off is that the site lives on Webflow. According to Webflow's help center, code export produces HTML, CSS and JavaScript, but CMS content, user accounts, ecommerce data and localized content are not included, and Site plans do not include code export at all. CMS collections can be exported separately as CSV files. So moving away from Webflow means rebuilding the site and importing the content, not copying it.
A headless CMS: Strapi, Sanity and similar
A headless CMS stores and edits content but has no website of its own: the site is a separate application, built by developers, that reads the content through an API. Strapi's Community Edition is open source under the MIT licence (code outside its enterprise directories) and can be self-hosted or run on Strapi Cloud; its export command includes content, relations, uploaded files, schemas and configuration, but not admin users or API tokens (Strapi documentation). Sanity's editing interface, Sanity Studio, is open source under the MIT licence, while the content itself is hosted by Sanity in its Content Lake; a dataset can be exported with documents and files to a local archive (Sanity documentation).
The point that matters for independence: in a headless setup, editors can change content in the fields that exist, but every new page type, layout or field also needs code in the front-end application. That is a developer's job, every time.
A static site with Markdown in Git
A static site keeps content as text files (usually Markdown) in a code repository, and a build step turns them into pages. It is fast, cheap to host and has almost nothing to update or hack. The editor is a text editor and Git, or a Git-based editing interface on top. It fits a technical team. For a sales or marketing team that publishes weekly, it is usually the wrong choice.
Comparison table
| Criterion | WordPress | Webflow | Headless CMS (Strapi, Sanity) | Static site (Markdown in Git) |
|---|---|---|---|---|
| Who can edit content | Anyone trained, in the admin panel | Anyone trained, in the visual editor | Anyone trained, in the CMS interface, within the fields that exist | People comfortable with text files and Git, or a Git-based editor |
| Who can change structure | A WordPress developer; many are available | A Webflow designer or developer | A developer, in both the CMS and the front-end code | A developer |
| Hosting and account ownership | Any host; account can be in your name | On Webflow; workspace and site plan can be in your name | Strapi: self-hosted or Strapi Cloud. Sanity: content hosted by Sanity. Front-end hosted separately | Any static host; repository and host in your name |
| Typical lock-in risk | Custom theme, heavy page builder, plugin licences in the agency's name | The platform itself: code export leaves out CMS content, forms need Webflow hosting | The front-end code and the developer who knows it | The developer who set up the build |
| Needs a developer for | New templates, plugins, updates on complex sites | New layouts and integrations beyond the builder | Every new page type, field or layout, and hosting operations | Almost any change beyond editing text |
| Fits when | A content team publishes often and wants the widest choice of future developers | A small team wants a polished site with no server to manage, and accepts the platform | The site is part of a product, content feeds several channels, and a developer or retainer partner stays involved | The team is technical and the content changes rarely |
When the honest answer is WordPress
If your company publishes articles, news, jobs or case studies regularly, has no developer on staff and wants to be able to change agency without rebuilding, WordPress is usually the right answer. The condition is discipline in the build: a lean theme, native blocks or one well-known builder, as few plugins as possible, every licence in your name, and automatic updates for minor versions. A plain WordPress site with a clear content model is more independent than a sophisticated headless site that only one developer understands.
When a hosted builder like Webflow fits
Webflow fits a company that cares about design, has a small content team and does not want to think about servers, updates or security patches. You accept the platform as part of the deal: the subscription is ongoing, and leaving means rebuilding. If that is acceptable, open the workspace in the company's name, give the agency a collaborator seat and ask for the content model in writing. That is independence on Webflow's terms, and for many companies it is enough.
When headless makes sense, and when it does not
We build with Next.js and have used Strapi, so this is not a criticism of headless. It is the right choice when the website is part of a product: content that also feeds an app, a customer portal or several sites in several languages; complex structured data such as a product catalogue; or performance and security needs that a classic CMS makes harder. It is the wrong choice when the only reason is that it sounds modern. A headless site has two systems to host and maintain, and every new page type needs code. Without a developer on staff or a partner on retainer, it creates exactly the dependence you wanted to avoid. If the website is really a product, our Product Development service is where that work sits.
When a static site with Markdown is enough
A static site fits a technical company: a software firm whose people already work in Git, a documentation site, a small site that changes a few times a year. It is cheap, fast and safe. For a company where content is written by sales, HR and marketing, a Git workflow is a barrier, and the site will slowly stop being updated.
What to demand from the agency at handover
Whatever the CMS, these items decide whether you can run the site alone or change partner later. Ask for them in the contract, before the project starts, not at the end:
- The domain registered in the company's name, with DNS access for someone in the company.
- Hosting, CMS subscription, licences and paid plugins in accounts opened in the company's name and billed to the company directly, with no markup.
- An administrator account for a named person in the company. The agency works with its own user, which you can remove.
- The code in a repository owned by the company, if the site has custom code.
- A tested export of all content (WordPress WXR, Webflow CSV, Strapi or Sanity export) and of media files.
- Written documentation: the content model, how to add each page type, how updates are applied, what not to touch.
- A training session with the people who will publish, and a list of every external service the site uses (analytics, forms, email sending, maps, cookie banner).
This is how we work ourselves: provider and hosting accounts are opened in the client's name and billed directly, admin access stays with the client, and a clean handover is part of every scope. See how we price. For the broader checks to run on any partner before signing, see how to choose a digital transformation partner, and for who fits which kind of work, freelancer, agency, SaaS or studio.
The website is the entry point, not the end
A company refreshing its site usually discovers that the real problem is not the CMS. It is who writes the content, who approves it, where product and price data come from, and why the same information is updated by hand in three places. Getting those processes in order is what makes a team actually run the site after launch. It also makes the content easier to find and cite, a topic we cover in how to get cited by ChatGPT and Claude. For the sequence of a redesign itself, see a website redesign, week by week.
If you are not sure which option fits, our diagnosis maps how content and the processes around it move through the company today, and ends with a written plan you keep, whoever builds the site.
Summary
- Independence comes from the content model, the editor, the accounts and the handover, not from the CMS brand.
- WordPress: the honest default for content teams without a developer, if the build stays lean.
- Webflow: independence on the platform's terms; leaving means rebuilding.
- Headless (Strapi, Sanity): right when the site is part of a product and a developer stays involved; wrong as a fashion choice.
- Static with Markdown: right for technical teams and rarely changing sites.
- In every case: domain, hosting, licences and admin access in the company's name, plus a tested export.
