Three client apps this year shipped on TanStack Start instead of Next.js. A fourth started there and moved back after eleven days. That fourth one is the useful data point, because the thing that sent us back had nothing to do with performance, bundle size, or any of the benchmarks people argue about.
TanStack Start reached its 1.x line in February 2025 and sits at 1.168 as of this writing, pulling around 18 million weekly npm downloads against Next.js's 53 million. That's roughly one to three — no longer a curiosity, not yet a default. Which means the interesting question isn't "is it ready" but "what kind of app is it actually better at," and that answer is narrower and sharper than the comparison posts suggest.
The inversion nobody warns you about
Next.js starts on the server and lets you opt into the client. Every component is a Server Component until you write "use client", and the framework's whole design pressure pushes work toward the request boundary. TanStack Start starts on the client and lets you opt into the server. You write a React app, and where you need the server you reach for a server function.
This sounds like a preference. It isn't. It decides which mistakes are cheap and which are expensive. In Next.js, accidentally shipping a secret to the client is a real hazard and the framework spends enormous effort preventing it. In TanStack Start, the hazard is the opposite — accidentally doing on the client what should have been a single server round-trip, and only noticing on a slow connection in QA.
The router is where this shows up first. In Start, a route isn't a file that exports a default component. It's an object that declares its own search-param schema, its loader, and its error boundary, and the type of all three flows outward into every component that touches that route.
Compare that to how most Next.js codebases handle the same thing: read searchParams, coerce a string to a number, hope nobody links to ?page=abc. We have fixed that exact bug in production for three different clients. In Start it isn't a bug you can write — the schema is the route, and a bad link falls back to page 1 because the schema said so.
Type safety stops being a feature and becomes the constraint
Every framework claims type safety. What Start actually does is make the boundary typed in both directions, so a server function's argument type and return type are the same objects your components consume — no generated client, no manual DTO, no drift.
The payoff is boring and enormous: rename a column, and TypeScript walks you through every component that read it. On the invoicing app we renamed a status enum value in week six. Twenty-two type errors, all real, all fixed in forty minutes. The equivalent change on an older Next.js project the same quarter took most of a day, because half the consumers were reading loosely-typed JSON from route handlers.
- Links are typed — a wrong route path or a missing search param is a compile error, not a 404 someone finds in staging.
- Loaders are cached and dedupedby the same query layer you already use, so the “fetch waterfall on navigation” problem mostly stops being yours to solve.
- Search params are real state — filters, pagination and sort survive refresh and back-button by default, which quietly deletes a category of bug reports from dashboard work.
Where we stopped and went back to Next.js
The fourth project was a content site with a commerce section — roughly 400 mostly-static pages, heavy on SEO, light on interactivity. We started it in Start because the team had just finished the invoicing app and was fluent. Eleven days in we moved it to Next.js and lost about three days of work doing so.
Nothing broke. The problem was that we kept rebuilding things Next.js ships: incremental regeneration for the catalogue, an image pipeline that someone else maintains, per-route metadata that the crawler ecosystem already understands. Start's client-first model gave us nothing on pages that have almost no client, and we were paying for that model in setup we had to own.
TanStack Start's ecosystem is smaller, and on a content-heavy site that gap is where your budget goes. Next.js's advantage in 2026 is not the framework — it's that ten years of Vercel-adjacent tooling assumes it. If your app's hard part is rendering pages fast for crawlers, that assumption is worth more than any type-safety win.
The four-day migration, honestly accounted
The one migration that did go well was a Next.js Pages Router admin panel — internal, authenticated, zero SEO surface, about 60 screens. Four working days, two developers. Here's where the time actually went, because it wasn't where we estimated.
Same 60 screens, two different shapes
Half a day on the router, which surprised us — file-based routing maps over almost directly. Two and a half days on data fetching, which did not: every getServerSideProps became a server function plus a loader, and each one forced a decision we had previously avoided about what that screen actually needs. The last day was auth middleware and the build pipeline. The honest read is that most of the cost wasn't migration, it was paying down ambiguity the old code let us keep.
Our rule for picking
We stopped arguing about this by writing down one question: what is the hard part of this app? Not the biggest part — the part that will generate the most bugs in month four.
- Hard part is application state — dashboards, admin panels, multi-step tools, anything with filters and tables and deep links. TanStack Start, without hesitation.
- Hard part is pages and crawlers — marketing sites, catalogues, docs, publishing. Next.js. The ecosystem does the work for you.
- Hard part is hiring — a client team of eight who will maintain it after us, none of whom have seen Start. Next.js, and we say so out loud in the proposal rather than quietly picking the fun option.
If you only change one thing
Don't migrate anything. Take the next internal tool you build — the one with a table, three filters and a detail drawer — and build it in TanStack Start. That shape is where the framework's argument is strongest and where being wrong costs you nothing. You'll know inside a week whether the type-safety-as-constraint model fits how your team works, and that's a far better basis for the decision than any comparison table, including this one.
