Webflow vs Custom Code (Next.js): When Each Wins

Webflow vs custom code comes down to three questions, and none of them is about which tool is more powerful. Webflow wins when the pages are content a non-technical person edits every week and the behavior the site needs is behavior a browser already does. A custom Next.js build wins when the logic has to run on the server at request time: signed-in dashboards, pricing computed per visitor, routes generated from a database the client already owns. Since Webflow Cloud became generally available on July 21, 2025, the honest answer on most agency projects is both, with the marketing site in Webflow and the app mounted on a path beside it.

• Editing frequency. Who edits this content after launch, and how often do they need to do it without a developer?
• Request-time logic. Does any page need code to run on the server at request time, or is it static content with a form?
• Upgrade ownership. Who is paying to keep the codebase current in two years, and have they agreed to that?

Answering those gives one of three stacks: Webflow alone, a Next.js app on Webflow Cloud inside a published 10 MB worker bundle and 20-second request ceiling, or a Next.js app on separate infrastructure with no ceilings and no shared bill.

The division of labour between this post and its cluster is worth stating, because briefs confuse them constantly. Whether to use Webflow at all, and whether its value justifies its price against other platforms, belongs to the cluster pillar, the Webflow value and cost breakdown, with the platform-against-platform cases in siblings like Webflow versus WordPress. How to build once Webflow is already on the table belongs here. Every judgement below assumes the platform question is settled and only the build approach is open.

Webflow vs custom code: what actually decides it?

The Webflow versus custom code decision is settled by editing frequency and request-time logic, not by design ambition. Webflow renders pages from a visual canvas and a hosted CMS, so a marketing manager changes a headline, publishes, and the change is live without a deploy. A Next.js codebase puts every content change behind a pull request unless someone also builds and pays for an editing interface. On the projects I lead, the first thing I ask an agency is how many content edits the client expects per month, because a client making weekly edits will quietly turn a custom build into a retainer they did not budget for. If the answer is more than a handful of edits a month and no page needs server-side logic, Webflow wins on cost of ownership before the design is even discussed.

Should you use Webflow, Webflow Cloud or separate infrastructure?

Webflow alone wins when nothing has to run on the server, Webflow Cloud wins when something does and it fits the published ceilings, and separate infrastructure wins when it does not. Most briefs that arrive framed as Webflow versus custom code are really that three-way choice, and the table below is the short answer to the whole question. Webflow alone covers the marketing site. Webflow Cloud hosts a Next.js or Astro app on a path of the same domain. Fully separate infrastructure gives unlimited runtime freedom and takes the whole operational burden with it.

Stack	Where it wins	What it rules out	Who maintains it
Webflow alone	Content a non-technical person edits weekly, with forms, CMS and hosting included	Any logic that must run privately on the server at request time	The client, in the Webflow editor
Webflow plus a Next.js app on Webflow Cloud	One domain and one bill, with server-side logic beside the marketing site	Features that breach the published Webflow Cloud ceilings, and custom domains on Starter and Basic site plans	A developer for the app, the client for the Webflow pages
Webflow plus a Next.js app on separate infrastructure	Unlimited runtime, long-running jobs, large datasets, any dependency	A single bill, a single deploy, and a stack the client can change alone	A developer, plus whoever carries hosting, DNS and on-call

Which features need code running on the server at request time?

Features that have to make a decision privately, on the server, while the request is in flight are the ones Webflow cannot host, and that single criterion is the whole reason to take on a codebase. Webflow serves published pages and runs client-side JavaScript, which leaves three common jobs homeless: a quote calculated from rates you do not want in the page source, a document generated per user, and a route that reads a live inventory table. In the builds I run for agencies, the test I apply is whether the feature would still work with JavaScript disabled and the network tab open to the client. If the honest answer is no, and the feature is central rather than cosmetic, the project needs a real server and Webflow is the wrong place to force it.

• Authenticated areas with per-user data fetched server-side.
• Pricing, scoring or eligibility logic that must stay off the client.
• Thousands of routes generated from a database rather than hand-managed items.
• Webhooks, scheduled jobs and server-to-server integrations with secrets.
• Anything a third party must call as an API endpoint on your domain.

None of those capabilities is an argument against Webflow for the marketing site, and reading them that way is the mistake that turns a two-week project into a rebuild. Each one is an argument for putting a Next.js app beside the Webflow site, on Webflow Cloud or on separate infrastructure, which is the choice the rest of this post resolves.

Custom code means two different things in Webflow conversations, and mixing them up is the most common reason an agency over-scopes a project. Adding a script to a Webflow site, in Site settings, Page settings or a Code Embed element, is covered in the Webflow custom code guide. Building the site itself as a codebase, which is what this post compares Webflow against, is a different decision with different owners and a different bill.

What are the limits of running Next.js on Webflow Cloud?

Webflow Cloud caps each deployment at a 10 MB worker bundle and 100 MB of compressed build output, and each request at a 20-second timeout, 30 seconds of CPU time and 128 MB of memory. Those published ceilings are what decide whether a custom feature belongs on Webflow Cloud or on separate infrastructure. Every figure in the table below is published on Webflow's Webflow Cloud limits page, which also states that limits vary by plan and are subject to change. When I scope a Webflow Cloud app for an agency, I read this table before writing a line of code, because the 10 MB worker bundle is the limit that most often sends a dependency-heavy Next.js app back to the drawing board. If a planned feature exceeds any row here, host that feature elsewhere rather than discovering the ceiling in production.

Webflow Cloud limit	Published value	What it rules out
Worker bundle size per deployment	10 MB maximum	Heavy dependency trees and bundled binaries
Build output per deployment	100 MB compressed	Large prerendered route sets with inline assets
CPU time per request	30 seconds maximum	Long report generation inside the request
Request timeout	20 seconds	Slow upstream APIs called synchronously
Worker memory	128 MB per instance	In-memory image or spreadsheet processing
Worker startup time	400 ms maximum cold start	Frameworks with heavy module-level work
Simultaneous outgoing requests	6	Wide parallel fan-out to many services
Subrequests per request	1,000	Per-row API calls across a large list
SQLite database size	100 MB on the Free, Basic and CMS site plans; 1 GB on Business and Enterprise	Storing the client's primary dataset
Environments per app	10	Nothing in practice for one agency team
Apps per site	5 on Starter; 15 on Core and Freelancer; 50 on Growth, Agency and Enterprise (workspace plan names)	Many small apps on a Starter workspace

Two of those rows interact in a way worth saying out loud, and the reading is mine rather than Webflow's: the 20-second request timeout is shorter than the 30-second CPU limit, so a request that spends most of its life waiting on a slow third-party API can be cut off before it has used anything like its CPU budget. Webflow publishes both numbers separately; the comparison between them is a derived observation, not a documented rule.

One reading trap in that table is worth flagging before anyone quotes a ceiling at a client, and the warning is mine rather than Webflow's. The storage rows name site plans, Free, Basic, CMS, Business and Enterprise, while the apps-per-site row names workspace plans, Starter, Core, Freelancer, Growth, Agency and Enterprise. A client on a Basic site plan inside an Agency workspace therefore sits under two different ceilings at once, so check both plans before promising a feature. The custom-domain restriction below is a site plan rule, not a workspace rule.

Storage ceilings in particular move with the site plan rather than with the code, which is the part that surprises agencies mid-build. The key-value store allowances below come from the same limits page, and they are the clearest illustration that a custom app on Webflow Cloud is plan-gated rather than unlimited.

Which Webflow plans allow a Next.js app on a custom domain?

Mounting a Webflow Cloud app on a custom domain is not available on Starter or Basic site plans, and that condition catches more projects than any runtime limit. Webflow's Webflow Cloud overview states that on those plans apps "can only be hosted on a webflow.io domain", and that removing the webflow.io badge is likewise unavailable there. The same page confirms Webflow Cloud "is included across Webflow plans, with features and usage limits varying by plan". What I see agencies get wrong is quoting a Webflow Cloud app for a client sitting on a Basic plan, then discovering at launch that the feature cannot live on the client's own domain. Check the client's current site plan before the proposal goes out, not after the build.

Does exporting Webflow code give you a custom codebase?

Webflow code export produces static HTML, CSS, JavaScript and images, and it drops every hosted feature the site depended on. Webflow's help documentation states that "Code export is only available on Workspace plans" and that "Site search and forms (including file upload and reCAPTCHA) will not work on exported sites", with CMS content, User Accounts, Ecommerce databases and code components also excluded. Password protection is explicitly lost: "Any password protected pages on your site will no longer be protected after code export." When an agency asks me to treat export as a migration path to a custom build, I price it as a rewrite of every dynamic feature, because that is what it is. Treat export as a way to take static markup with you, never as a way to turn a Webflow site into a maintainable application.

• Exported: HTML pages, custom styles, webflow.css, normalize.css, the Webflow JavaScript files and the Assets panel images.
• Not exported: CMS content, Ecommerce products and checkout, User Accounts and access groups, code components.
• Broken after export: forms and form processing, site search, password-protected pages.
• Partial: only the primary locale is exported, so localized content needs rebuilding.

Source: Webflow's guide to exporting site code. If what you actually want is a Webflow site the client controls rather than a codebase, the site and plan transfer route keeps every hosted feature working.

Is a Next.js build harder to maintain than a Webflow site?

A Next.js build is harder to maintain than a Webflow site, and the gap is engineering work rather than content work. A Webflow site creates content work; a Next.js codebase creates content work plus a standing engineering commitment that never ends while the site is live. Next.js 16.4 shipped on October 6, 2026, and that release states plainly that its new Cache Components model "will become the default in Next.js 17", which means a programming-model migration is already scheduled for every app on the current line. Next.js now ships an agent-driven upgrade path for exactly that reason, with a next upgrade command that hands a coding agent the version-specific migration guides. The rule I apply on client projects is that nobody signs off a custom front end until a named person owns its upgrades, because an unowned Next.js app is a security liability within about two release cycles. If no one will own that, build it in Webflow and spend the saved budget on content.

• Webflow ongoing work: content edits by the client, occasional template changes, plan renewals.
• Next.js ongoing work: framework upgrades, dependency patches, build pipeline fixes, hosting monitoring.
• Shared ongoing work: analytics, SEO, accessibility fixes, and whatever the client's marketing team wants next.

Cost of ownership is the question the Webflow value and cost breakdown covers in full, including current plan pricing. For the content side of the decision, how many collections a project needs and where Webflow's content ceilings sit are covered in the Webflow CMS structure guide.

Where do Webflow vs custom code decisions go wrong?

Picking the wrong stack between Webflow and a custom Next.js build fails in five recognizable ways, and each one shows up months after the invoice is paid. The list below is drawn from rescue projects, where the original decision was reasonable on the day it was made and wrong by the time the client needed to change something. When I audit an inherited build for this, the first thing I check is whether the people editing the site today are the people the stack was chosen for.

• Custom build, non-technical client. Consequence: every copy change becomes a developer ticket, and the client stops updating the site within a quarter.
• Webflow forced to do server work. Consequence: business logic ends up in client-side JavaScript where anyone can read it, and the client inherits a security problem nobody disclosed.
• Webflow Cloud app scoped past its ceilings. Consequence: the deployment fails on the 10 MB worker bundle or the 100 MB compressed build output, and the feature is re-platformed at the agency's expense.
• Code export sold as a migration. Consequence: forms, search and password-protected pages stop working on the exported site, and the rebuild is discovered after the Webflow plan is cancelled.
• Custom front end with no named owner. Consequence: the framework goes two majors out of date, a dependency advisory lands, and the upgrade quote arrives as a surprise capital expense.

None of those five failure modes is caught by a launch-day review, which is why the stack question belongs in the brief rather than in QA. The separate question of what a finished build should be held to on launch day, from Core Web Vitals to accessibility, is covered in the Webflow QA checklist. When the work is delivered through an agency rather than directly, the ownership and access questions around that arrangement are answered in the white label Webflow workflow guide.

How do you choose between Webflow and a custom build?

Choosing between Webflow and a custom Next.js build takes one pass through four facts about the project, in this order, and the first clear answer ends the discussion. Run it with the client in the room rather than in a proposal document, because three of the four answers live with the client and not in a brief. On the builds I scope for agencies, this sequence resolves the stack question in under an hour in most cases, and the cases it does not resolve are genuinely the ones that need a prototype.

1. Check the client's Webflow site plan, since Starter and Basic rule out mounting an app on their own domain.
2. Name every feature that must run server-side, then check each one against the published Webflow Cloud ceilings.
3. Count expected content edits per month and name the person making them.
4. Name the person who owns framework upgrades for the next two years, in writing.

If step 2 produces nothing, build it in Webflow. If step 2 produces features that fit inside the ceilings and step 1 clears, put a Next.js app on Webflow Cloud beside the Webflow site. If step 2 produces features that breach the ceilings and step 4 has a real name, separate infrastructure is justified.

Want a second opinion before you commit to a stack?

If you are weighing Webflow against a custom Next.js build for a specific client right now, book a 15-minute call and bring the feature list. You will leave with a stack recommendation per feature, the Webflow Cloud ceilings each one would hit, and a straight answer on whether the project needs a codebase at all. Book the 15-minute stack review.