Vendor lock-in and Webflow

Vendor lock-in is the state where you cannot edit or further develop your own website without a developer at hand. A typical example of vendor lock-in in practice: you want to fix one sentence on a landing page, you write to your supplier, you wait three days and you pay for an hour of work.

What is interesting about it is that this dependency almost never comes from the choice of platform. It comes from how the site was built in the first place and how it was handed over afterwards.

Webflow is no exception here – a site can easily be built so that you manage the content yourself, but just as easily so that you need a developer for every small thing.

Vendor lock-in is the most common worry I hear from clients, and at the same time the most common reason they migrate to Webflow from whatever they are running now.

Two different things with the same name

Vendor lock-in hides two worries that have little to do with each other. It pays to separate them, because each has a different remedy and a different urgency.

Operational dependency

Who you have to think of when you want to change something. It concerns everyday running: a text, an image, a new subpage, another article. This is the expensive one, because it shows up every week.

Platform dependency

How easily you could move elsewhere if you had to. It concerns every hosted platform and it is harder to solve, but you solve it once every few years.

Most writing about vendor lock-in deals only with the second one. It is the first one that actually costs clients money.

What Webflow removes from the operational side

A well-built Webflow site rests on four things. None of them comes for free with the choice of platform. They are decisions made during the build, and they need to be agreed with your developer up front.

• Components. Ready-made blocks with the content already built in, easy to edit and just as easy to reuse on existing pages or when creating new subpages.
• Page builder. New subpages are very easy to create. You pick the components, fill in the content and publish.
• A content management system with custom fields. Collections have a clearly defined structure, so adding new content, whether a case study or a standalone article page, cannot disturb the design, the SEO or any other technical setting.
• An editor with a live preview. Content is edited directly on the page, published with one click and reverted just as easily.

The last point deserves particular emphasis. The content editor has no access to the design settings themselves and therefore cannot break anything there. It is precisely the fear of breaking something that most often pushes editors into handing the change to a developer instead. And that is exactly where vendor lock-in begins.

Where it usually goes wrong

Vendor lock-in can be built in Webflow too, and I have seen it many times. The site looks just as good, but every change goes through the supplier. You can spot it by a few things:

• Every page is built statically in the code, without using components.
• The site is built primarily in the designer, with no way to edit it from the other access levels. The Editor role practically cannot reach the content.
• Custom code where the native solution would have done.
• Confusing naming of variables and of the custom code that was used.

The dependency here was not created by Webflow. It was created by how the site was built, and it carries the name of that particular developer, not of the platform.

A handover that leaves you on your own feet

In my case that means four things:

• I transfer the project to your account, not mine. You pay the Webflow invoice and you hold complete access under your own credentials.
• The rights to the project are yours. Once it is finished and tested, the site is yours along with everything belonging to it.
• The handover includes a walkthrough of how to manage things. Not a link to documentation, but going through your site and your collections. Later support and recorded how-to videos by arrangement.
• No mandatory retainer. Later changes are charged at an hourly rate and only for the time actually spent. If you manage on your own, you pay nothing.

The last point is the one that makes the difference. A retainer is optional with me and comes up on large projects; most sites I hand over so that running them and developing them further stays in the client's hands.

And platform dependency?

Webflow is a hosted, closed platform, but should you migrate to another platform or decide to host the site entirely on your own server or hosting, the whole site can be exported as standalone HTML, CSS and JavaScript. Content from the content management system is exported into separate CSV files or retrieved through the API.

Three questions for your supplier

When you are choosing who will build your site, these are the questions that separate a good solution from a good-looking trap:

• Whose account will the project sit in once it is finished?
• What exactly will I be able to change myself, and what will always go through you?
• What happens if we end the collaboration?

The answers tell you more about your future dependency than the name of the platform does.