TanStack Start vs Next.js: why we built a SaaS starter on TanStack Start

Next.js is the default answer to "which React framework for a SaaS?", and for good reasons: the biggest ecosystem, the most tutorials, the easiest hiring. When we started ShipKit we chose TanStack Start anyway. This post explains why, and it is just as specific about what that choice costs. If what you need sits on the other side of the trade, Next.js is the right answer for you, and we would rather you know that before you buy anything.

A quick note on status: as of September 2026, TanStack Start is a Release Candidate. Its docs call it feature-complete, with a stable API. React Server Components are available as an experimental feature. That matters, and we come back to it below.

1. It runs on Cloudflare Workers natively

ShipKit runs on Cloudflare Workers, with D1 for the database and R2 for files (why is its own post). That decision constrained the framework choice more than anything else.

TanStack Start builds with Vite, and Cloudflare's own framework guide sets it up with the Cloudflare Vite plugin. In development, vite dev runs your server code in workerd, the same runtime as production. The D1 and R2 bindings are real there too, backed by local state. The code that works on your laptop is running under the same rules it will run under in production.

Next.js reaches Workers through an adapter layer. Cloudflare's docs currently recommend vinext as the default way to run Next.js on Workers, with OpenNext as the alternative for existing apps. vinext is marked beta, and some features, such as image optimization, are only partially supported. It works, and it keeps getting better. But you are running a framework built with Node and Vercel in mind, translated for a different runtime. When something behaves differently in production than in next dev, that translation is one more place to look.

2. Type safety all the way through the router

In TanStack Start the router knows every route, its path params and its search params, and a route can validate its search params with a schema. A <Link> to a route that doesn't exist, a missing param, or a search param of the wrong type is a type error. You don't find it at runtime.

That sounds like a nice-to-have until you rename a route in a codebase with forty pages. In ShipKit, tsc then lists every link, redirect and loader that needs to change.

It matters even more when an AI agent is writing the code. An agent confidently links to a route that was renamed last week. With typed routes that mistake fails bun run typecheck before anyone sees it.

3. A data flow you can read

ShipKit has one rule for data, and TanStack Start makes it easy to follow:

• A route loader asks TanStack Query for the data (ensureQueryData).
• The query calls a server function, a typed RPC with middleware for the session and permissions.
• The server function calls Drizzle.

Every step is a function call you can follow with "go to definition". Caching lives in one place, TanStack Query, with defaults you set yourself.

Next.js's App Router is built around React Server Components. Data fetching happens inside components that render on the server, and there are several layers of caching whose defaults have changed between major versions. It is a powerful model, and many teams like it. For us it meant more implicit behavior. Our test was "can a newcomer, or an agent, tell where this data comes from and when it refreshes, just by reading the code?" The explicit version passed that test more easily.

4. Server functions with real middleware

A TanStack Start server function is declared with a validator and a handler, and it can be built on top of middleware. ShipKit uses two bases:

• authedFn checks for a session.
• adminFn also requires permission to open the admin console.

Every admin function then asserts its own specific permission. Because these are ordinary typed functions, a unit test can scan them. ShipKit has one that fails the test suite, and with it CI, if any admin server function forgets its permission check. That rule lives in CLAUDE.md too, but the test is what keeps it true.

What we gave up

These are real costs. Weigh them.

• Ecosystem and hiring. Next.js has far more tutorials, examples, Stack Overflow answers and developers who know it. With TanStack Start you'll read source code more often.
• Maturity. "Release Candidate" is not "1.0". We pin exact versions and upgrade on purpose, and the ShipKit release notes say when an upgrade needs action from you.
• React Server Components. They are experimental in TanStack Start. If your architecture depends on RSC, Next.js is the mature option today.
• Batteries. Next.js ships things like next/image optimization. On Start you pick your own tools, and on Workers some Node-only packages don't run at all.
• Some sharp edges. A route file's component is split into its own chunk, but the rest of its options (loader, validateSearch…) ship in the main bundle. Wrapping createServerFn in a factory can pull a server module into the browser bundle. We hit these, fixed them, and wrote each one into CLAUDE.md so neither you nor your agent has to hit them again.

When to choose Next.js instead

Choose Next.js if:

• you're deploying to Vercel and want the platform and framework made by the same company;
• your team already knows Next.js, or you need to hire for it;
• you want React Server Components in production today;
• you depend on libraries or examples that assume Next.js.

Choose TanStack Start if:

• you want Cloudflare Workers without an adapter in between;
• you value types that catch broken links and params;
• you like data flow you can trace;
• you'll build with an AI agent that benefits from all of the above.

Where this leaves ShipKit

ShipKit is TanStack Start on Cloudflare Workers, all the way down. You get auth, payments with Stripe and Creem, an admin console, i18n and docs, plus the rules and tests that keep an agent from breaking them. If that's the stack you want, take a look, or open the live demo first. If it isn't, our comparison of TanStack Start boilerplates covers kits built on Postgres and Vercel as well.