Are teams really leaving Webflow? Here's what we're seeing

If your team is deciding whether to stay on Webflow, start with what you need your website to do. We're hearing more questions from companies who've used it for two or three years. Webflow hasn't got worse, but the alternatives have improved. Here's where we think Webflow still fits, why some teams are leaving and how to make the decision.

The tools that started the conversation

AI development tools have prompted much of the conversation. v0 by Vercel, Bolt.new, Lovable and Cursor let developers generate front-end code ready for production. They've changed what a small technical team can ship in a week.

A developer with good prompting habits can now scaffold a Next.js application, connect it to a headless CMS and deploy it to Vercel in a day, without using a visual editor. For projects with complex application logic, that gives you code you own, room to extend it and a familiar CI/CD pipeline.

Two years ago, building a polished marketing site without a visual editor took a significant amount of time. AI tools have shortened that work enough for some teams to question whether they still need the visual editor.

What Webflow still gets right

We still recommend Webflow in many situations. Before looking at why teams leave, it's useful to be clear about what it does well.

Marketing team control. Webflow's Editor lets non-technical teams update copy, swap images, publish posts and adjust layouts without raising a ticket. Replicating that in a code-first setup takes custom tooling or time to get people comfortable with the CMS.

CMS sites without extra infrastructure. For marketing websites, landing pages and content sites with moderate complexity, Webflow handles the data, front-end, hosting and CDN. A headless stack such as Sanity, Next.js and Vercel has its own running costs and needs someone to maintain it.

Time to launch. A competent Webflow developer can take a Figma design to a responsive, CMS-powered, SEO-optimised marketing site in two to four weeks. The equivalent custom build takes longer and usually costs more to maintain.

Working from the design. Webflow's visual editor is good at turning designs into working code. Animations, scroll triggers and hover states that take a developer hours to implement can be built in minutes on the canvas. Seeing those changes as you work helps design teams make decisions.

So why are some teams leaving?

We've discussed this with clients. The same issues tend to come up.

1. Complex application logic

Webflow is a website builder. Once you need authenticated sessions, data beyond CMS collections, real-time features or forms beyond what Memberstack or Outseta can handle, the platform becomes harder to work with. Teams building SaaS products, client portals or other logged-in services reach for tools they can write code against.

2. Code ownership and version control

You can't manage Webflow's output through GitHub in the usual way, run a CI pipeline against it or roll back to a specific commit. That makes it harder for engineering teams used to git workflows, particularly as the site and team grow.

3. Component architecture at scale

Webflow's component system has improved, but React still offers more ways to combine and reuse components at scale. On sites with hundreds of pages and dozens of design variations, the limits become clearer. Teams end up duplicating styles and working around the platform.

4. The "we can just generate this" moment

A developer can open Cursor or v0 and generate a Next.js landing page that closely matches the design in 20 minutes, with Tailwind, responsive layouts and accessibility included. That changes the appeal of a visual editor for developers who used Webflow to avoid writing CSS: AI can now write it for them.

We're not anti-Webflow. We're a Webflow agency. But we'd rather give clients an honest framework than defend a tool that doesn't fit their situation.

Where teams are actually going

The most common destinations we see in practice:

Next.js + Vercel + Sanity. We commonly see this choice when teams want a CMS their editors can use, full code ownership and a modern deployment process. Sanity Studio provides the writing interface, while v0 by Vercel helps generate the front-end. These tools sit at the centre of Vercel's AI approach.

Astro + Sanity. For content sites where page performance matters most, Astro's approach of sending no JavaScript by default helps deliver Core Web Vitals scores that heavier frameworks struggle to match. Our own site uses this stack. We recommend it for projects where SEO matters and developers are comfortable working in the terminal.

Framer. Framer has gained traction for portfolios and marketing sites with plenty of movement and animation. It uses a visual editor, like Webflow, with better support for React components and a cleaner codebase underneath.

Who should stay on Webflow

Many teams questioning Webflow would be better off staying.

If marketing and content teams run your site, Webflow is still the right platform. Moving has a cost: you lose the Editor, depend on a developer for content schema changes and take on infrastructure that someone needs to maintain.

For service-business marketing websites, which make up most of our client work, Webflow's developer tools have improved. Webflow Attributes, Client-First and the Logic feature address many objections we heard two years ago. The platform continues to change.

Teams that publish and change content frequently also benefit from seeing layout updates straight away, without waiting for a build.

How we advise clients on this

We work with both Webflow and headless stacks at Hilvy. We recommend the one that fits the project. Here's how we make that decision.

Choose Webflow if: your primary site users are marketers and content editors; you need to move fast without a dedicated front-end developer; the site is marketing-led with standard content types; or you want an agency to maintain it with predictable ongoing costs.

Consider a headless stack if: you need authenticated experiences, user data, or real-time features; engineering is driving the project and a git-based workflow is non-negotiable; you're building something closer to a product than a website; or you're willing to invest in setup time for a more extensible long-term architecture.

AI tools have made the headless route faster and cheaper. That gives teams more options, but the decision still comes down to who will run the site and what it needs to do.

Book a 15-minute call to talk through which approach fits your project.