Are Teams Really Leaving Webflow? Here's What We're Seeing

Something has shifted in how teams talk about Webflow. We're fielding more questions than ever from companies who've been on the platform for two or three years and are now wondering if they should stay. Not because Webflow has gotten worse (it hasn't) but because the alternatives have gotten dramatically better. Here's our honest take on what's driving the shift, where Webflow still wins, and how to decide which path fits your team.

The tools that started the conversation

The honest catalyst isn't any single Webflow decision. It's the emergence of AI-native development tools that let developers generate production-quality front-end code directly. v0 by Vercel, Bolt.new, Lovable, and Cursor have fundamentally changed what a small technical team can ship in a week.

For the first time, a developer with good prompting habits can scaffold a Next.js application, wire it to a headless CMS, and deploy it to Vercel in a day, without touching a visual editor. The appeal is obvious if you're building something with complex application logic: you own the code, you can extend it without hitting platform boundaries, and your CI/CD pipeline looks like every other modern web project.

That's a genuinely new dynamic. Two years ago, building a polished marketing site without a visual editor was a significant time investment. Today, the AI layer has compressed that gap to the point where some teams are asking whether the visual editor was ever the point.

What Webflow still gets right

Before we diagnose the departures, it's worth being honest about where Webflow still wins and why we still recommend it as a first choice in many situations.

Marketing team autonomy. Webflow's Editor gives non-technical marketing teams genuine control. They can update copy, swap images, publish blog posts, and adjust layouts without raising a ticket. That's genuinely hard to replicate in a code-first stack without investing in significant custom tooling or CMS onboarding.

CMS-powered sites without backend overhead. For marketing websites, landing pages, and content-heavy sites with moderate complexity, Webflow handles the data layer, the front-end, the hosting, and the CDN in one platform. The operational cost of a headless stack (Sanity plus Next.js plus Vercel) is real and needs someone to own it.

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

Visual design fidelity. Webflow's visual editor is genuinely good at translating design intent into working code. Subtle animations, scroll triggers, and hover states that would take a developer hours to implement precisely can be done in minutes in the canvas. That feedback loop changes how design teams work.

So why are some teams leaving?

We've had this conversation with real clients, and the pattern is consistent. Teams tend to hit the same walls.

1. Complex application logic

Webflow is a website builder, not an app platform. Once you need authenticated user sessions, dynamic data beyond CMS collections, real-time features, or form logic that goes beyond what Memberstack or Outseta can handle, you're fighting the platform. Teams building SaaS products, client portals, or anything with a logged-in experience inevitably reach for something they can write code against.

2. Code ownership and version control

Webflow's output isn't yours in the traditional sense. You can't check it into GitHub, run a CI pipeline against it, or roll back to a specific commit. For engineering-led teams accustomed to git workflows, this is a genuine friction point, especially as the site grows and collaboration becomes harder.

3. Component architecture at scale

Webflow's component system has improved, but it still doesn't match the composability of React at scale. When you're managing a site with hundreds of pages and dozens of design variations, the abstraction limits become visible. You end up duplicating styles and working around platform constraints rather than with them.

4. The "we can just generate this" moment

This is the newest pressure and the most interesting one. When a developer opens Cursor or v0 and generates a pixel-perfect Next.js landing page in 20 minutes, complete with Tailwind, responsive design, and accessibility baked in, the value proposition of a visual editor narrows. Particularly for developers who were using Webflow precisely to avoid writing CSS, and are now finding that AI writes it for them anyway.

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. The default choice for teams that want editorial experience (Sanity Studio gives non-technical editors a genuinely good writing interface) with full code ownership and modern deployment. v0 by Vercel accelerates the front-end scaffolding significantly. This is the stack the Vercel AI story is built around, and it's compelling.

Astro + Sanity. For content-heavy sites where page performance matters above everything else, Astro's zero-JS-by-default approach delivers Core Web Vitals scores that are hard to match on heavier frameworks. Our own site is built on this stack. It's our recommendation for SEO-critical projects where developers are comfortable in the terminal.

Framer. For design-forward portfolios and marketing sites where the audience expects a high-motion, heavily animated experience, Framer has earned real traction. It's closer to Webflow in the visual-editor paradigm but with better support for React components and a cleaner codebase underneath.

Who should stay on Webflow

This is the part that gets left out of most of these takes. A lot of teams questioning Webflow shouldn't leave.

If your team is primarily marketing and content (not engineering) Webflow is still the right platform. The switching cost is real: you lose the Editor, you add a developer dependency for every content schema change, and you inherit infrastructure complexity that needs someone to own it.

If your site is a marketing website for a service business (which describes the majority of our clients) Webflow's developer tooling has improved significantly. Webflow Attributes, Client-First methodology, and the Logic feature cover a large percentage of the objections we heard two years ago. The platform is not standing still.

And if you're a team that ships frequently and iterates on content constantly, the visual feedback loop of Webflow is genuinely valuable. Seeing layout changes in real time without a build step changes how teams operate, in a good way.

How we advise clients on this

At Hilvy, we work across Webflow and headless stacks. We're not ideologically committed to either. Our honest framework:

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.

The AI tools have made the headless path faster and cheaper than it's ever been. That's a genuine shift worth taking seriously. But it doesn't make Webflow the wrong choice, it just narrows the situations where the trade-offs clearly point somewhere else.

If you're mid-evaluation and want an honest 15-minute take on which direction fits your specific project, that's exactly what we're here for.