Webflow, Framer and the new builders: our honest view
What the modern visual builders do well, where they stop being the right tool for a business, and how we decide between a builder and a coded site.
The short answer
The current generation of visual builders is a real step up from the page builders of the past. They produce clean, fast pages on good hosting, handle responsive design properly, and give designers a tool they can iterate in without a developer. For a design-led marketing site of modest size, with a designer who wants to move fast visually, no custom logic beyond forms and a business that accepts the platform dependency, they can be the right choice, and we say so when they are. Their limits are structural rather than qualitative. The site lives on the builder’s platform, in its formats, at its prices, with ceilings on content volume and structure, on logic and integrations, and on what can be exported. When a business needs large or structured content, custom features, integrations with its own systems, strict ownership of the code or a horizon of many years, a coded site on owned foundations is the better tool. The honest view is that the builders are good at what they are for, and that many business sites are not that.
Where builders shine and where they stop
| Dimension | Builders do well | Builders stop |
|---|---|---|
| Visual design iteration | Excellent; designers work directly | Design systems shared with an application |
| Output quality | Clean markup, fast hosting, responsive | Fine control of performance and accessibility details |
| Content | Small to medium sites; simple collections | Hundreds of structured pages, relations, multilingual at scale |
| Logic and features | Forms, simple interactions, embeds | Custom functionality, authenticated areas, complex integrations |
| Integrations | Popular services through built-in connectors | Your own systems, custom APIs, webhooks with verification |
| Ownership | Content and design while subscribed | Code you can take and run elsewhere |
| Export | Static files of the pages | Dynamic content, forms, interactions; re-import |
| Cost | Predictable subscription at small scale | Rising with sites, seats, traffic and features |
| Longevity | As long as the platform and the plan suit | Platform pricing or feature changes you did not choose |
| Team fit | A designer-led team | A team that needs version control, review and pipelines |
Deciding
- Describe the site in five years: pages, content types, languages, features, integrations. If the description fits a marketing site, the builder is a candidate.
- Ask who will change it: a designer who wants to iterate visually favours a builder; a team that needs review, version control and testing favours code.
- List the integrations: popular services only, or your own systems too?
- Decide on ownership: is a tenancy acceptable, or must the business own the code?
- Price five years: subscription, seats, traffic, add-ons, versus a coded site’s hosting and maintenance.
- Choose, and write down why, so the decision can be revisited when the site’s needs change.
Our practice
We build business websites as coded sites on owned foundations because our clients’ sites have, or will have, the content, features, integrations and ownership needs that exceed a builder, and because a coded site on a modern platform is as fast to iterate on as it is to own. When a brief is genuinely a design-led marketing site with a designer who wants a builder and a business that understands the trade, we say a builder is a reasonable choice, because it is.
What this means for you
The modern builders are good tools for design-led marketing sites of modest size where the team wants to iterate visually and accepts living on the platform. They are the wrong tool for sites with large structured content, custom features, deep integrations, strict ownership or a long horizon. Decide from the five-year description of your site, not from the demo, and write the reason down.
Frequently asked questions
Are these builders as bad as the old page builders?
No. The old page builders produced bloated markup on top of a heavy platform. The modern builders generate reasonable code, host on fast infrastructure, handle responsive design properly and give designers a real tool. Our reservations are not about output quality; they are about where the site lives, what happens when needs exceed the builder, and what the business owns.
What does a business actually own on a builder?
The content and the design as long as the subscription continues. Export exists but produces static files that cannot be re-imported or easily maintained, and dynamic content, forms and interactions do not survive it. The site is, in practice, a tenancy on the builder's platform. For some businesses that trade is fine; it should be made knowingly.
When would you recommend a builder?
A design-led marketing site of modest size, with a designer on the team who wants to iterate visually and often, no custom logic beyond forms, no large or structured content, and a business that accepts the subscription and the dependency. In that case a builder can be the right tool and we will say so. The moment the brief includes a knowledge base, an application, complex integrations or strict ownership, it is not.