TanStack Start Is Still a Release Candidate. One Team Migrated a Live SaaS to It Anyway.

Adopting a framework before it reaches 1.0 is a bet: that the team behind it will finish what it promised, and that your own codebase won’t need whatever ships in the gap between Release Candidate and stable. Most comparisons between a pre-1.0 framework and an established one stay hypothetical, a todo app built twice and benchmarked. What that skips is the part that actually matters: what happens when someone runs that bet on a paying product.

One documented case shows exactly that. Melvyn Malherbe, who builds the online learning platform Codeline, migrated its production app, checkout flow, admin panel, user accounts and all, from Next.js to TanStack Start, and walked through the migration in detail. The pull request added around 100,000 lines and removed about 129,000. The framework he landed on is still labeled Release Candidate, not 1.0, on its own homepage — he shipped a live business onto software its own maintainers call not-quite-finished.

That single migration is not a verdict on which framework is better. It is one specific, documented account of what a real migration cost and returned, plus the parts a marketing page would leave out, used here to illustrate a broader question: what “still RC” should mean for anyone deciding whether to follow him.

What TanStack Start actually is

TanStack Start is a full-stack React framework built on top of TanStack Router, the routing library that has been stable in production since 2024. Where Next.js is server-first, meaning the server decides how a page renders by default, TanStack Start is client-first with server pieces added on: full-document server-side rendering, streaming, server functions, and server routes, all built on top of the same typed route tree Router already gives you. Type checking runs on routes, URL parameters, and search parameters at compile time, not just in an editor plugin.

TanStack Start’s official site, which currently badges the framework “RC” and reports 18,055,219 weekly downloads and 14,805 GitHub stars.

The framework shipped its Release Candidate on September 23, 2025, with the TanStack team stating they planned “to cut 1.0 shortly after collecting RC feedback.” As of this writing, that cut has not happened: the official docs still carry the RC badge and recommend locking dependency versions rather than floating on a broad range. One real gap worth knowing before you commit to it: React Server Components, the feature Next.js has built much of its recent identity around, is not supported yet. The TanStack team lists it as in active development, planned as a non-breaking addition once it lands.

None of this makes TanStack Start a toy. Fourteen companies, including Cloudflare, Netlify, Prisma, Convex, and Clerk, are listed as official ecosystem partners building integrations for it. That is a serious list for pre-1.0 software, and it is part of why a working platform like Codeline could migrate onto it at all.

The migration that actually happened

Codeline is not a demo repo. It is Malherbe’s commercial product: course checkout, an admin dashboard, user account management, several hundred pages of live content. The migration itself, tracked as pull request #315, ran largely through an AI coding agent (Codex) using a custom skill he built for the job, migrate-nextjs-to-tanstack, and cost him several hundred dollars in model tokens by his own account. A migration of that size handled mostly by an agent, on a paying product, is itself the more unusual part of this story — the framework choice is almost secondary to the fact that an AI did most of the heavy lifting on a real business’s codebase.

He gives three reasons for the switch, and the strongest two come with numbers he measured himself rather than numbers he was told.

Build time roughly halved. Across dozens of deployments, his Next.js builds ran 3 minutes 17 seconds at the fast end and 3 minutes 47 seconds at the slow end, averaging around 3 minutes 30. On TanStack Start, the same range ran 1 minute 9 seconds to 1 minute 35 seconds, averaging about 1 minute 20. That is a consistent 2-minute-plus swing on every deploy — the kind of gap that matters most exactly when you don’t want it to: a production incident where someone is waiting on a fix to ship.

Navigation felt different under a slow connection, not just a fast one. Malherbe demoed both apps side by side with network throttling simulating 3G. Next.js showed the familiar cascade: a placeholder, then a loader, then a re-render once data arrived. TanStack Start, using TanStack Router’s prefetching with skeletons scoped to what’s actually loading, displayed the relevant skeleton immediately with no extra loading states stacking on top of each other. This is a subjective, single-demo comparison, not an independent benchmark, but it is a demo run on his own product rather than a curated example.

The argument that mattered most to him wasn’t speed

Malherbe was explicit that his main reason for switching wasn’t the build times or the navigation feel. It was that TanStack Start is easier for an AI coding agent to work in correctly, because its API is declarative and centralizes each route’s concerns in one place:

export const Route = createFileRoute('/path')({
  beforeLoad: checkAuth,             // middleware
  validateSearch: searchSchema,      // type-safe search params
  loaderDeps: ({ search }) => search,
  loader: async ({ deps }) => fetchData(deps),
  pendingComponent: SkeletonUI,      // loading UI
  component: PageComponent,          // render
  head: () => ({ meta: [...] }),     // SEO
})

Compare that to the vocabulary a Next.js project has accumulated: use server, use client, server actions that were renamed partway through their own rollout, a page-directory-versus-app-directory split, middleware and proxy behaviors that overlap enough to confuse which name applies, and use cache layered on more recently still. None of these individually is a bad design decision — most trace back to Next.js solving real problems as React’s own model evolved around it. But an agent generating code has to know which era of terminology a given codebase is using, and Malherbe’s claim is that his agent got that wrong constantly on the old stack and rarely does on the new one.

That claim is his own impression from one migration, not a measured benchmark, and it should be read that way. It is also not a trivial claim to dismiss: the AI-friendliness of a framework’s API surface is a real, mostly unmeasured variable that didn’t used to matter much when humans wrote all the route code by hand.

What the migration cost him

The one-shot version of this story would stop at the numbers above. It shouldn’t. The AI-driven migration produced real bugs that needed manual correction afterward: a misplaced notification button and broken avatar images are two he mentioned specifically. An agent moving 100,000 lines of a live product is not a clean, silent process — it is a process that needs a human checking the result before it ships, the same way any large refactor does regardless of who wrote it.

The other honest cost is the one built into the framework’s version number. TanStack Start’s ecosystem, plugins, third-party guides, and Stack Overflow answers are all considerably thinner than Next.js’s, because Next.js has had years of mainstream use to accumulate them. Adopting a pre-1.0 framework is a bet that its remaining API changes before 1.0 will be small, and that its ecosystem will keep growing fast enough to catch up. Codeline is Malherbe’s own product, so he is the one absorbing that risk directly. A team shipping a client’s product, or a platform with a compliance sign-off process, is taking on a different kind of exposure by making the same call.

Next.js’s official homepage, the framework Codeline migrated away from.

Where this actually points

Where this actually points.

This is one migration, documented by the person who did it, not an industry consensus or a controlled benchmark. Treat the build-time numbers and the AI-friendliness claim as real data from a real system, not as a general law about either framework. What it does establish is that TanStack Start is now mature enough, and has enough ecosystem backing, for at least one live commercial product to run on it without falling over. Whether that is a green light for your own project depends on how much you need React Server Components today, how much production certainty your project requires before its dependencies hit 1.0, and how much of your route code is actually going to be written by an agent rather than a person.

FAQ

Is TanStack Start production-ready? It depends on your risk tolerance, not a simple yes or no. It is labeled Release Candidate on its own site, not 1.0, and the TanStack team recommends locking dependency versions rather than tracking a broad range. At least one real commercial product, Codeline, runs on it in production, which shows it is usable at that scale, not that its remaining pre-1.0 changes carry zero risk.

Does TanStack Start support React Server Components? Not yet. The TanStack team lists RSC support as in active development, planned to land as a non-breaking addition once ready. If your project depends on RSC today, that is currently a reason to stay on Next.js.

Is TanStack Start actually faster to build than Next.js? In one documented migration, yes, consistently: roughly 3 minutes 30 seconds average on Next.js versus roughly 1 minute 20 seconds on TanStack Start, across dozens of deployments of the same application. That is one team’s real numbers, not an independent, controlled benchmark across many projects, so treat it as a strong signal rather than a guaranteed result for every codebase.

Why would AI coding agents work better with TanStack Start? The claim, from the same migration, is that TanStack Start centralizes each route’s logic, middleware, loading state, and data fetching in one declaratively named object, while Next.js has accumulated multiple overlapping or renamed concepts (server actions, use server, use client, middleware versus proxy) as React’s model changed under it. An agent has to correctly infer which era of Next.js terminology a codebase uses; TanStack Start’s API gives it less room to guess wrong. This is a reported impression from one migration, not a measured, reproducible benchmark.

Should I migrate an existing Next.js app to TanStack Start? Only if you’re prepared to accept pre-1.0 risk and you have a specific reason: an AI-heavy development workflow, a need for faster build times on a large app, or a greenfield project where the smaller ecosystem is less of a cost. If your project needs React Server Components now, or needs full production certainty before its core framework hits 1.0, Next.js remains the safer default.