Why we stopped recommending page builders for anything past an MVP

For the first version of almost anything, a page builder is the right call. It's fast, a non-technical founder can update it, and the cost of being wrong is low. The trouble starts a year or two later, once the site has real traffic, a marketing team with specific requests, and a page-speed problem nobody can quite pin down. That's the point where the tool that got you moving starts quietly taxing everything you do, and the tax rarely shows up as a single obvious bill. It shows up as a dozen small frictions that each feel manageable on their own.

We've rebuilt more than thirty sites off Webflow, WordPress page builders, and drag-and-drop SaaS platforms over the past few years, almost always for the same underlying reason. The company outgrew the tool months before anyone noticed, and by the time someone did notice, the workaround list was long enough that the rebuild felt like a bigger project than it actually needed to be.

Most builders ship a generic runtime to every page, whether that page uses ten percent of it or ninety. A simple landing page can end up loading several hundred kilobytes of framework code before a single word of your actual content renders. Nobody signed off on that cost directly. It just accumulates, one plugin and one section block at a time, until Core Web Vitals reports start flagging a site that was fine eighteen months ago.

We audited a client's WordPress site last year and found fourteen active plugins, each adding its own script bundle, each loaded on every single page regardless of whether that page used the feature. The booking calendar plugin loaded on the About page. The review widget loaded on the checkout confirmation page. None of that was intentional; it was just the default behavior of a system where adding a feature is a single click and removing dead weight requires someone to actually go looking for it.

The specific layout a marketing team wants for a campaign page rarely matches the twelve templates a builder ships with. At that point you're either compromising the design or paying a developer to fight the platform's constraints, which usually costs more than building it properly would have in a framework built for exactly that kind of customization.

We've watched a two-hour custom section request turn into an eight-hour ordeal because the builder's grid system fought every attempt to place three asymmetric cards side by side. In a real codebase, that's a CSS grid definition and a component, done in well under an hour. In a builder built around a fixed set of layout primitives, it's a series of nested wrapper divs and negative margins that work until the next update to the platform's core styles quietly breaks them.

Every plugin is a dependency you didn't write and don't fully control. Each one needs its own updates, each update carries a small chance of breaking something else on the site, and each one is a potential security vector if the plugin author stops maintaining it. We've seen sites running plugins that hadn't been updated in over two years, sitting on a platform that had moved three major versions past what the plugin was built for.

None of this is a hypothetical risk. WordPress plugin vulnerabilities are a routine source of site compromises, and the more plugins a site runs, the larger that attack surface gets. A custom codebase has dependencies too, but far fewer of them, and a team that actually reads changelogs before upgrading rather than clicking "update all" on a dashboard once a quarter.

Clients usually assume a migration off a page builder means starting from zero. It doesn't, if the content and information architecture are sound, which they usually are. A typical fifteen to twenty page marketing site migrating from a builder to a framework like Next.js runs somewhere between four and eight weeks for us, depending mostly on how many custom interactive elements need to be rebuilt rather than the page count itself.

The number that actually matters isn't the migration cost in isolation, it's that cost compared to another year of paying the builder tax: the developer hours spent fighting the platform, the conversion rate lost to slow page loads, and the opportunity cost of a marketing team that can't ship the campaign page it actually wants. Run that comparison honestly and the migration usually pays for itself within a year, sometimes faster.

It's tempting to blame the builder itself for SEO problems, and sometimes that's fair, some platforms genuinely limit control over meta tags, structured data, and URL structure. More often, though, the SEO damage comes from the page weight and Core Web Vitals issues discussed above, not from the platform being inherently unfriendly to search engines.

A well-configured page builder site with disciplined plugin management can perform fine on technical SEO. The problem is that discipline requires ongoing attention most teams don't have bandwidth for once the site is live and the next campaign is due. A custom build doesn't require less discipline exactly, but it removes an entire category of third-party scripts and dependencies that would otherwise need auditing.

This isn't a blanket argument against builders. A content-heavy site with a small team, a limited budget, and no plans for complex custom functionality can run happily on a well-chosen builder indefinitely. The decision isn't about company size or revenue, it's about how much the site's needs diverge from what the platform was built to do well.

We still recommend Webflow or a similar builder for a genuine first version, and for some businesses, a good builder setup with a disciplined plugin diet is a permanent, sensible home rather than a temporary one. The mistake isn't choosing a builder. It's never revisiting that choice as the business and its requirements change underneath it.

The switch point isn't a fixed date, it's a specific signal: the first time someone on the team says "we can't do that in the builder" about a request that should be simple. Before that point, a builder is genuinely the more capital-efficient choice. After it, every month spent working around the platform is a month of accumulating cost that eventually shows up as a full rebuild anyway, just a more expensive and more urgent one.

We tell clients this even when it means less work for us in year one: build the MVP fast, on whatever gets it live fastest, and plan the migration to a real codebase before the workaround list gets long enough that the migration itself becomes the scary part. Keeping a running list of every workaround, even informally in a shared doc, makes that trigger point obvious well before it becomes an emergency.

When a prospective client asks us to quote a custom build for something that's clearly still MVP-stage, we regularly tell them to use a builder instead and come back to us in a year, even though that means losing the project today. It costs us short-term revenue and it's the reason a meaningful share of our client base comes back to us specifically when they're ready for the harder build, because that first conversation was honest instead of self-serving.