Why we build in Webflow, and when we tell clients not to

Why Webflow is our default

Webflow serves as our default choice for business websites, though it is not a one-size-fits-all solution. Recommending a single platform for every client reflects bias rather than strategic guidance. This article outlines our rationale for defaulting to Webflow, highlights its boundaries, and identifies scenarios where alternative tools are preferable.

Many growing companies eventually face a shared hurdle: making standard site edits—like updating a service offering or sharing company news—demands technical intervention, ticketing systems, or extended timelines. The initial platform selection dictates both how often and how much they cost.

What Webflow Does Well

Integrated hosting simplifies operations. The platform includes infrastructure management, eliminating the need for independent hosting setups, routine plugin maintenance, and server updates. For organizations without dedicated IT personnel, shedding this operational overhead is a major advantage.

Clean, semantic structure by design. Webflow positions its Designer as a bridge combining visual editing with direct HTML and CSS control, enabling developers to build semantically sound, accessible sites. As a result, structural elements like document landmarks, heading hierarchies, alt text, and link labels are intentional choices rather than automated theme outputs. This precision underpins our accessibility standard.

Decoupled content and presentation. Repeating assets—such as team directories, services, and articles—are managed through Webflow CMS collections, which dynamically generate individual pages. Non-technical teams can manage and publish copy without risking layout integrity, while design refreshes can take place without re-keying existing data.

It connects to the rest of the business. Webflow can send a signed notification to another system when a form is submitted or a CMS item changes, and it connects natively to some CRM platforms. Those connections let a website become part of an operating process rather than a brochure. We cover the options in our article on the five levels of CRM integration.

What Webflow does not do

An honest recommendation requires stating the limits plainly.

It does not run server-side code on standard sites. Webflow's documentation states that custom code sections "only support HTML, CSS, and JS" and that "you can't integrate server-side languages (such as Perl, PHP, Python, or Ruby)." Webflow Cloud, which became generally available on July 21, 2025, allows full-stack applications built with frameworks such as Next.js and Astro to run alongside a Webflow site, but that is application development in its own right and should be scoped as such.

Some features have been retired. Webflow Logic, its native workflow automation tool, was sunset on June 27, 2025, and Webflow recommended third-party tools such as Zapier and Make as replacements. This could mean an additional subscription for automation tools or using an AI Agent to fill the gap.

The plan determines what is available. As of this writing, the Basic site plan does not include the CMS. Following Webflow's May 2026 plan consolidation, the Premium site plan lists 20,000 CMS items and 40 collections. Plans and prices change, so we confirm the current figures before quoting a project.

Accessibility remains the builder's responsibility. Webflow provides tools, including an audit panel that checks for common issues such as missing alt text, empty links, and out-of-sequence headings. Its documentation does not assign responsibility for the accessibility of any particular site, and an audit of common issues is not a conformance review.

When we recommend something else

The following reflect our judgment rather than a platform rule, and each should be evaluated against the specific business.

• The product is an application. If visitors must log in, see their own data, and take actions that change records, the requirement is a web application with a marketing site in front of it. We would scope the application separately, and the marketing site may or may not live in Webflow.
• Content volume or workflow exceeds the CMS. A publisher with tens of thousands of items, or an editorial process requiring complex approvals, should test those requirements against the plan limits before committing.
• A large, established store is working well. If a business already runs a mature online store with extensive extensions and a team that knows it, migration cost and risk can outweigh the benefit. We would rather say so than win the project.
• The site's real job is membership. Because native User Accounts have been retired, a membership-centered offering should begin with the membership platform and treat the public website as a secondary concern.

How we decide

We ask three questions during the first discovery call, and those answers generally determine the best platform.

1. What will change most often, and who will change it? If the answer is marketing content edited by non-developers, Webflow is a strong fit.
2. Does the site need to know who the visitor is? If it does, we plan for a separate service from the outset.
3. What must the site connect to? The answer determines whether we need native connectors, an automation platform, or custom code.

The short version

Webflow is our default because it gives a business control over its own content, structured and accessible markup, and straightforward connections to its other systems. We recommend alternatives when the project is really an application, when content volume exceeds the platform, or when migration would cost more than it returns. If you would like our team to review your requirements and recommend a platform, reach out — we'll assess the fit transparently before any commitment.