TanStack Start vs Next.js — picking the one that is not 1.0 yet

Let us get the disqualifying fact out of the way first: TanStack Start is still a release candidate. Not 1.0. If your organisation needs a framework with a stability guarantee behind it, stop here and use Next.js — that is the correct decision and nothing below overturns it.

FlareStarter Pro runs on TanStack Start on Cloudflare Workers in production anyway. This post is why, and what it costs.

The architectural difference: router-first

Next.js is a framework that contains a router. TanStack Start is a router that grew a framework around it.

That sounds like positioning, but it changes what you write. In Start, the route is the contract — it declares its params, its loader, its search-param schema, and its middleware, and TypeScript knows all of it. Navigate with a typo in a search param and the build fails. Read params.id in a component and it is typed because the route said so, not because you asserted it.

Next.js's App Router gets type safety in patches: generated types for routes, searchParams as a loose record you validate yourself, server actions typed at the boundary but not across navigation. It is meaningfully better than it was, and it is still not the same thing.

If your app is mostly forms, filters, and tables — which most B2B SaaS is — that difference shows up daily. Search-param state is where a lot of dashboard bugs live, and Start makes it a typed API instead of a string bag.

Server boundaries you can see

Start's server functions are explicit:

const getPosts = createServerFn({ method: 'GET' })
  .validator((locale: string) => locale)
  .handler(async ({ data: locale }) => {
    const { blog } = await import('collections/server')
    return selectBlogList(blog, locale)
  })

The boundary is a function call with a validator attached. You can see where the network hop is, and the validator is not optional.

React Server Components take the opposite bet: the boundary is a build-time property of the module graph, and the mental model is "this renders on the server unless it says otherwise." When it works it is elegant. When it does not, you are debugging why a component pulled a client dependency into a server bundle.

Neither approach is wrong. But explicit boundaries are markedly easier to reason about at 2am, and much easier to test — a server function is just a function.

Where each one deploys

This is the practical reason we chose Start.

Start targets Cloudflare Workers, Node, Netlify, and Railway from the same route definitions. Running it on Workers is not a compatibility layer; it is a build target.

Next.js on Workers works — through OpenNext — but you are adapting a framework built for a Node-shaped runtime onto an isolate-shaped one. It is a real project with real users, and it is still a translation layer between you and the platform.

If you have decided on Cloudflare, Start removes an entire category of "does this feature work on our runtime" questions. If you are deploying to Vercel, this advantage evaporates completely, and Next.js's tighter platform integration becomes the better trade.

What Next.js has that Start does not

Be honest about the gap, because it is wide:

Stability. 1.0 versus RC. APIs can still move.
Ecosystem. Every tutorial, every hiring pool, every third-party integration assumes Next.js. When you hit an obscure problem, someone has already written the Stack Overflow answer.
Image optimization, ISR, and middleware as batteries-included features rather than things you assemble.
React Server Components as a first-class, heavily-invested-in model.
Employability. "We use Next.js" is easier to hire for than "we use TanStack Start."

That last one is not a technical argument, and it is often the deciding one. Ignore it at your own cost.

What it actually cost us

Running an RC in production has a real price:

Upgrades need attention. RC releases occasionally change APIs. We read changelogs instead of running npm update on autopilot.
Fewer answers exist. Some problems you debug from source rather than from a blog post.
Smaller plugin surface. Things you would install on Next.js, you sometimes write.

What we got back: type safety that catches routing bugs at build time, a runtime that matches our deployment target exactly, and no adapter between our code and Cloudflare.

For a starter template — where the whole product is the code you hand someone — that trade favoured Start. For a team shipping a business feature under a deadline, it very often does not.

Choose Next.js if

You need a stable, 1.0 framework with vendor-scale backing.
You are deploying to Vercel.
You want the largest ecosystem and hiring pool in the React world.
Your team already knows it. Familiarity is real velocity.

Choose TanStack Start if

You are deploying to Cloudflare Workers and want a native target, not an adapter.
Your app is routing-heavy and end-to-end type safety pays for itself daily.
You prefer explicit server boundaries over the RSC model.
You can absorb RC churn — you read changelogs and pin versions.

The summary

Next.js is the right default and will remain so for most teams. TanStack Start is a bet: better types, explicit boundaries, and a runtime that matches Cloudflare exactly, in exchange for maturity you do not get yet.

Bets are fine when you understand what you are wagering. Do not pick Start because it is newer. Pick it because your deployment target and your routing complexity make the trade obviously worth it — and then keep an eye on the changelog.

FlareStarter Pro is a production SaaS starter on TanStack Start and Cloudflare Workers — organizations, seat billing, metered credits, API keys, and audit logging, wired end to end.

TanStack Start's release status is accurate as of 2026-08-23 and is the thing most likely to change in this post.