What happened

TanStack closed a long candidate cycle: Start is no longer “almost ready,” but a stable full-stack React product.

That lineage matters for expectations. Start did not appear as another greenfield “Next clone.” Routing, typing habits, and patterns already lived in Router; Start layered server work, build, and app scenarios on top.

On npm the “1.0” line still shows as 1.169. In the r/reactjs thread Tanner explained the number reflects package history, not a hundred-plus major meaning bumps. For teams it signals API maturity; for package.json you simply install what the registry actually serves.

React Status also highlights the RSC honesty. Linsley frames server components as a checkbox the project once needed for legitimacy. TanStack’s own site has already dropped that room: Start’s architecture does not have to orbit RSC as the only serious model.

The Next.js 16.4 comparison on one shared app produces numbers that travel well into an architecture review: 2.9×–8.6× more dynamic requests, roughly 1.7× faster builds with typecheck. That is not a universal verdict on Next — it is one bench on one codebase — but it is hard to ignore when picking a stack.

Ryan Carniato called Start a React metaframework with an architecture he can get behind. The same issue notes site migrations (including off Astro) and official “from Next” / “from RC” guides.

Why it matters

Choosing a full React stack is no longer only about DX and starters. It is also about which defaults are baked in.

RSC is a strong platform bet in Next. Start answers differently: you can be a serious React framework without making server components the center of gravity. For teams that find RSC costly for debugging, bundle boundaries, or data modeling, that removes a false dilemma — Next or an “unserious” stack.

Throughput and build numbers matter where the bottleneck is render-server load and CI time, not marketing. If the same app on Start serves far more dynamic traffic and typechecks faster in the build, “why another framework?” gets a measurable reply — even if your multipliers differ.

Migration guides lower the cost of trying: move an existing Next app or finish an RC → 1.0 path from a checklist instead of rewriting on vibes.

Picture a workshop that started as an excellent workbench (Router) and grew into a full shop (Start). They hung a “we have the same room as the neighbors” plaque for reputation, then found they did not need to live in that room — their own site already runs without it. The Next bench shows how many covers per hour the shop plates on the same menu.

In practice

Stable 1.0 does not skip validation on your code. It only makes the experiment cheaper and clearer about API expectations.

1. Read the Start 1.0 release notes and breaking changes relative to your RC or Router layer.
2. Coming from Next — start with the official migration guide, not a folder layout copy of what you already know.
3. Already on RC — follow the RC → 1.0 guide and pin the lockfile (remember the npm line may look like 1.169).
4. Re-run your critical path (dynamic load + build with typecheck) on a comparable bench: their 2.9×–8.6× is a signal, not a guarantee.
5. Decide explicitly whether this project needs RSC; do not drag them in as a checkbox if Start covers the job without them.
6. Treat TanStack Router routing and server/client boundaries as the core, not a side add-on.
7. In CI, time typecheck plus production build before and after: for many teams the win shows up there first.

Takeaway

TanStack Start 1.0 is a stable full stack around Router, with a candid RSC stance and hard numbers versus Next.js 16.4 on dynamic load and builds.

If you are picking a React metaframework in 2026, run your own bench and open the official migration guides. Do not argue only about the RSC checkbox.