When is Webflow the wrong choice?

Most articles answering this are written by people selling the alternative, which makes them accurate about the limits and unreliable about how often those limits bite. We build on Webflow regularly and also move sites off it, so the useful contribution here is where the line sits in practice. Two notes before the list. The limits are published and they move, sometimes substantially, so check the current pricing page rather than any article including this one. And hitting a ceiling eventually is not a failure of the choice, it is a normal outcome of growth.

What are Webflow's actual limits?

Published, tiered by plan, and revised often enough that quoting numbers here would be a disservice. There are caps on how many content items a site can hold, how many collections it can have, how many static pages it can publish, and how many items a single list can render on one page. Some of those lift with a higher plan and some are fixed regardless of what you pay, and which is which has changed more than once. The correct move is to open the current pricing and limits documentation before designing a content model, and to write the numbers you find into the project brief so the decision is dated.

Far less often than the warnings suggest, because most businesses never approach it. A services company with a blog, some case studies and a team page is operating in a completely different order of magnitude from the caps, and will still be after a decade of publishing. The projects that genuinely collide with the ceiling are the ones generating content programmatically: a directory, a large property portal, a marketplace, a publisher with a deep archive. If you can plausibly estimate your item count in five years and it is in the low thousands, this is not your constraint and you should stop worrying about it.

What about anything behind a login?

This is the clearest case for building somewhere else, and it got clearer when Webflow retired its own membership and workflow features. Anything that stores per-user state, performs calculations, enforces permissions or does real work in response to input is an application, and Webflow is a publishing tool with a design surface. You can bolt third-party services on to approximate it, and for a simple gated resource library that is reasonable. Once the logged-in experience is the product rather than a courtesy, you are maintaining an application assembled from vendors nobody planned together, which is the expensive way to have built one.

Is Webflow wrong for a large multilingual site?

Not wrong, but priced and structured in a way worth modelling before you commit. Localisation is charged per locale and every locale multiplies the content that has to be created, reviewed and kept in step, so a site in six languages is a fundamentally different operating commitment from the same site in one. The technical support for right-to-left languages is real and does not remove the design work those languages need. The question to answer before choosing is not whether the platform can do it. It is whether the ongoing cost per locale, multiplied by the number you intend to run, still makes sense in three years.

Does the export option protect you?

Partially, and less than the existence of an export button implies. You can take the markup and styling out, which means the design is not trapped. What does not come with it is anything the platform was providing as a service: forms stop submitting because the endpoint receiving them was Webflow's, and content-driven pages need a new source once they are no longer being generated. Export is therefore a real safety net for a static marketing site and a partial one for anything else. Knowing precisely which of your site's behaviour is hosted rather than built is the useful audit, and it is worth doing before you need the answer.

What is the honest recommendation for a growing company?

Usually a split rather than a single choice, and the split follows who edits what. Marketing pages change weekly, are edited by people who do not write code, and benefit enormously from a visual tool, which is exactly what Webflow is good at. Product interfaces change on a release cycle, are edited by engineers and belong in a code stack. Running both, with one design system and a shared domain, is not a compromise; it is how most companies past a certain size actually operate. The mistake is not choosing Webflow. It is trying to make one tool serve both jobs because a single platform sounded simpler.