Next.js vs TanStack Start vs Webflow for B2B SaaS Marketing Sites

TL;DR

If you're a B2B SaaS company picking a stack for your marketing site in 2026, the answer almost always falls into one of these three:

Webflow if your marketing team owns the site, you're under ~30 pages, and you don't need server-side logic
Next.js if you have engineers, you're integrating with a product, and you want the deepest ecosystem
TanStack Start if you have engineers, you're TypeScript-heavy, and you want something Next.js-shaped without the App Router's complexity

This post gets specific about which problems each one actually solves and where each one breaks down. We've shipped sites on all three over the last two years; the recommendations are scar-tissue, not theoretical.

What you're actually buying

A SaaS marketing site has to do a few things well:

Render fast on mobile — first contentful paint under 1s, LCP under 2.5s
Be editable by non-engineers — your content team should ship a pricing page tweak without a deploy
Integrate with the product — login state, dashboard previews, programmatic per-customer pages
Run programmatic SEO at scale — integration pages, comparison pages, location pages, role-based pages
Convert — A/B testing, personalization, dynamic CTAs based on UTM source

These five requirements are the entire decision tree.

Webflow: the right answer most of the time

Webflow gets dunked on by engineers. They're wrong, mostly.

For a typical seed-stage to Series A B2B SaaS marketing site — 20-ish pages, marketing team of one or two, no product-deep integrations — Webflow is the correct choice. You'll ship in two weeks, your marketing lead can edit the hero copy without filing a ticket, and the page speed is fine if you don't get cute with animations.

Where Webflow wins:

Time-to-launch: ~4 weeks for a polished site vs ~10 weeks for a custom build
Editorial control: marketing team has full authoring autonomy
Hosting and CDN: included, fast enough, no DevOps tax
Designer-friendly: visual editor matches how designers think about layout
Cost: ~$30/mo hosting + ~$20/mo per editor. You'll spend more on coffee.

Where Webflow falls over:

CMS scaling. The CMS is hard-capped at 10,000 items per Collection on the Business plan, 20,000 on Enterprise. If you want programmatic SEO for "Acme + [tool]" integration pages and you have 500 integrations × 20 use cases = 10,000 pages, you're already at the limit, with zero headroom. We have clients who hit this and had to migrate.
Bound to one frontend. No SSR with custom logic. No edge functions. No "render this differently if the user is logged into our product." If you need to gate content behind a session cookie, you're proxying through a Worker or rebuilding.
Componentization is shallow. Webflow Components are great for small-scale reuse but break down once your design system has dozens of variants. The same button in seven contexts becomes seven components instead of one with props.
Localization is painful. Webflow Localization works for ~5 locales. Beyond that the editor experience deteriorates and the URL routing options are limited.
Performance ceiling. A perfectly optimized Webflow site is fine. A typical agency-built Webflow site loads 800KB of unused CSS and 12 JS animations. If the marketing team hires a "Webflow developer" off Upwork to add animations, you'll watch CWV degrade in real time.

Verdict: Stay on Webflow until something on this list actually blocks you. Migrating preemptively is the most expensive form of premature optimization a SaaS marketing team commits.

Next.js: the default for engineering-led teams

Next.js is the safe choice if you have engineers and you've outgrown Webflow. The ecosystem is the deepest of any React framework — every CMS has an integration, every analytics tool has a docs page, every problem has a Stack Overflow answer from 2024.

Where Next.js wins:

Programmatic SEO scales. Static generation with generateStaticParams lets you build 10,000 pages from a CMS at deploy time. We've shipped sites with 30,000+ programmatic pages this way.
Product integration. Same auth, same component library, same monorepo as your dashboard. The marketing site can show a personalized hero ("Welcome back, Sarah") because it shares state with the app.
Edge-rendered personalization. Vercel's edge functions or middleware lets you A/B test, geo-route, or render different headlines per UTM source without client-side flicker.
CMS flexibility. Sanity, Payload, Contentful, Storyblok, even Notion — any CMS works. Your content team uses what they prefer.
Vercel integration. Preview deploys on every PR is the killer feature for marketing teams. Your designer can review a real URL before it ships.

Where Next.js falls over:

App Router is heavier than it needs to be. Server Components are powerful but the mental model is genuinely complex — the rules around Client Boundaries, Server Actions, and revalidation trip up senior engineers regularly. Onboarding a new engineer to a Next.js App Router codebase in 2026 takes longer than it should.
Caching has too many knobs. unstable_cache, cacheLife, cacheTag, revalidatePath, dynamic = 'force-static', fetch cache options, segment configs — every Next.js project we audit has at least one cache bug because the surface area is enormous.
Vendor lock-ish. Next.js runs on every host, but it runs best on Vercel. The features you actually want — ISR, edge middleware, Image Optimization at scale — are first-class on Vercel and second-class everywhere else.
Marketing-team friction. Next.js + a CMS is fine, but a content lead who wants to add a custom landing page section needs an engineer to build the React component first. The Webflow tradeoff returns: fast iteration costs engineering time.

Verdict: Default choice for engineering-led teams shipping a marketing site as part of a product org. Use the App Router if your engineers are strong with React Server Components; otherwise, Pages Router is still supported and simpler.

TanStack Start: the new contender

TanStack Start hit 1.0 in late 2025. It's the framework version of TanStack Router, which has been the best client-side React router for a few years.

It exists because some engineering teams looked at Next.js's App Router and decided they wanted the SSR + file-based routing benefits without the Server Components mental model. Start gives you:

Type-safe routing. Route params, search params, loaders, and actions are all inferred end-to-end. If you misspell a param name, TypeScript yells. This is genuinely a productivity win once you've felt it.
Loaders on every route. Like Remix's loaders or Next.js's getServerSideProps. Each route declares what data it needs, the framework fetches it on the server, and you get it as a prop. Simple model, no Server Components required.
SSR + streaming. Same Suspense streaming as the App Router. Same TTFB benefits.
No App Router gymnastics. No 'use client' directives, no Server Actions, no cache directives. Components are just components.

Where Start wins:

Cleaner mental model. If your team felt the App Router was over-engineered, Start feels like Next.js's good ideas without the cost.
Type safety end-to-end. Best-in-class for TypeScript-heavy teams.
Deploy anywhere. Cloudflare Workers, Vercel, Netlify, your own Node server — Start has adapters for all of them and treats them as first-class. Vercel doesn't get preferential treatment.
Smaller surface area. Less to learn, less to mess up.

Where Start falls over:

Ecosystem is small. Some CMSes don't have a Start example yet. Some auth providers don't have a Start integration. You'll write more glue code than you would on Next.js.
No equivalent of Vercel preview deploys out of the box. Cloudflare Pages does it, Netlify does it, but the workflow is rougher than Vercel's.
Younger framework. Fewer Stack Overflow answers, no 5-year-old projects to learn from. If you hit an obscure bug, you're reading the source.
Server Components are not happening. If you wanted RSCs and just disliked the App Router, Start isn't going to give them to you. Decide where you stand on that.

Verdict: Excellent choice for a TypeScript-strong engineering team that wants modern SSR without the App Router. We've shipped multiple production sites on Start in the last six months including the one you're reading. We'd happily pick it again.

The decision tree

Note: This is the framework you can reasonably decide on in an hour. The hard part isn't the framework — it's the IA, the copy, and the offer.

Q: Is your marketing team going to edit the site without engineers?

Yes, and you're under 30 pages → Webflow
Yes, but you're over 30 pages or need programmatic SEO → Next.js or Start with a CMS
No, engineers ship every change → Next.js or Start, no heavy CMS needed

Q: Is the marketing site sharing components, auth, or design system with the product?

Yes → Next.js (ecosystem advantage)
Mostly no → Start is fine and probably nicer to work in

Q: Do you need 10,000+ programmatic pages?

Yes → Next.js with static generation. Webflow's CMS will hit limits, Start can do it but the ecosystem is thinner.
No → Webflow if non-engineers own it, Next.js or Start if engineers do

Q: How TypeScript-strict is your team?

Strict, you'd rather catch errors at build time than runtime → Start
Pragmatic, you mix any when needed → either works

Q: Are you on Vercel?

Yes, deeply → Next.js is the smoother fit
No, or you're on Cloudflare → Start treats Workers as a first-class target

Migration paths

If you're considering moving:

Webflow → Next.js. This is the most common migration we run. ~6–10 weeks. The hard part is preserving the redirect map (every Webflow URL needs to 301 to its new home, or your backlinks die). The rest — re-implementing layouts in React, CMS migration, analytics replumbing — is mechanical.

Webflow → Start. Same shape as the Next.js migration, ~5–8 weeks. Start's smaller ecosystem means more glue code on integrations like Sanity or Payload, but the routing is cleaner.

Next.js (Pages Router) → Next.js (App Router). A real project. Don't do this unless you're getting concrete value from RSCs. Most of what people think they want from RSCs (faster TTFB, smaller bundles) you can get from the Pages Router with proper code splitting.

Next.js → Start. Worth considering if your team is fighting the App Router and the move would cut a meaningful amount of complexity. We've done two of these. Both teams reported the codebase felt 30–40% simpler post-migration. Both said they'd do it again.

Start → Next.js. Mostly hypothetical. The reason would be hiring — the Next.js talent pool is much larger.

What this looks like for a typical SaaS

For a Series A B2B SaaS company shipping its second-generation marketing site, our default recommendation in 2026:

TanStack Start as the framework
Sanity or Payload as the CMS (Sanity if marketing wants the polished editor, Payload if you want the CMS in your repo)
Cloudflare Pages or Workers for hosting
Programmatic integration pages generated from the CMS at build time
Server-side analytics through a Cloudflare Worker (we wrote that up here)

For a Seed-stage SaaS or a marketing-team-led project: stay on Webflow until something concretely blocks you, then migrate.

For an engineering-deep team that's already on Vercel: Next.js, Pages Router unless you have a specific reason to want the App Router.

If you're trying to pick between these and want a second opinion specific to your team — what your engineering bandwidth looks like, what your marketing team needs from the CMS, what programmatic SEO scale you actually need — send us a note. We'll do the audit and tell you which one fits, including the reasons we'd recommend against ourselves if Webflow is the better answer.