# TanStack Start vs Next.js in 2026: Which React Framework for Production SaaS

> TanStack Start vs Next.js for production SaaS in 2026: routing type safety, data fetching, server functions vs Server Actions, RSC, and deployment, compared with code from two kits we ship.

*Published: 2026-07-02*
*Canonical: https://makerkit.dev/blog/tutorials/tanstack-start-vs-nextjs*

---

TanStack Start vs Next.js comes down to two things: how much you rely on React Server Components, and how much you want the compiler to check your routes. Next.js 16 is built around RSC and the App Router and deploys most smoothly to Vercel. TanStack Start is built on Vite, Nitro and TanStack Router, types every route end to end, uses TanStack Query as its data layer, and deploys to any Node host.

**Quick answer**: Choose Next.js if you want the most mature RSC implementation, the largest ecosystem and hiring pool, and the Vercel workflow. Choose TanStack Start if you want Vite's dev server, compiler-checked routes and server functions, TanStack Query as your data layer, and a Nitro build you can deploy anywhere. Both can run a production SaaS; TanStack Start is younger and its APIs change more often.

*Based on both MakerKit kits as of October 2026. Exact versions are listed at the end of this post.*

MakerKit maintains the same production SaaS starter on both frameworks, so this comparison comes from building and updating one product twice. The [TanStack Start Drizzle kit](/docs/tanstack-drizzle/installation/overview) is a port of the [Next.js Drizzle kit](/docs/nextjs-drizzle/installation/overview): same features, same Better Auth setup, same Drizzle schema. The code below comes from those two repos.

## TanStack Start vs Next.js at a Glance

| Dimension | TanStack Start | Next.js 16 |
|-----------|----------------|------------|
| Build tooling | Vite (Rolldown) | Turbopack / Webpack |
| Server runtime | Nitro (deploy-anywhere) | Next.js server / Vercel |
| Router | TanStack Router (file-based, `createFileRoute`) | App Router (folder conventions) |
| Route type safety | End-to-end (params, search, loaders) | Partial (typedRoutes opt-in) |
| Data fetching | Route loaders + TanStack Query | RSC + `fetch` + Server Actions |
| Server logic | Server functions (`createServerFn`) | Server Actions + Route Handlers |
| React Server Components | Experimental (since April 2026); not used in our kit | Default model, mature |
| Rendering | SSR + client hydration, SPA-capable | RSC streaming, PPR, SSR, SSG |
| Deploy targets | Node, Vercel, Cloudflare, any Node host (Nitro presets) | Vercel-first; self-host supported |
| Lock-in | Low (Vite/Nitro, portable) | Moderate (App Router conventions) |
| Ecosystem / hiring | Smaller, growing | Largest in React |
| Maturity | Younger (v1, frequent releases) | Mature, widely deployed |
| Best for | Type-safe app-shell SaaS, teams leaving the App Router | RSC-heavy apps, content sites, Vercel shops |

### Quick Decision Matrix

| Factor | Choose TanStack Start | Choose Next.js |
|--------|----------------------|----------------|
| Routing type safety | Want it end-to-end, enforced by the compiler | typedRoutes is enough |
| Data layer | Already all-in on TanStack Query | Prefer RSC + `fetch` |
| Dev/build speed | Vite HMR matters to you | Turbopack is fine |
| Deployment | Want to deploy anywhere, avoid lock-in | Deploying to Vercel anyway |
| RSC | Don't need the RSC model | Want mature RSC / PPR |
| Team background | SPA / Vite / TanStack shops | Large team, easy hiring |
| Framework maturity | Comfortable on a v1 that changes often | Want the established default |

After porting a full multi-tenant SaaS kit from Next.js to TanStack Start, our conclusion is that either framework is a sound choice. Pick Next.js if you value the RSC model and ecosystem depth; pick TanStack Start if you value end-to-end type safety, Vite, and deploy portability. The sections below compare each dimension with code from both kits.

## What Is TanStack Start?

**TanStack Start is a full-stack React framework built on Vite and TanStack Router.** It uses file-based routing with fully typed routes, server functions for backend logic, and Nitro to produce a portable server bundle you can deploy to Node, Vercel, Cloudflare, or any Node host. It renders on the server and hydrates on the client, and can run as an SPA. Our [what is TanStack Start](/blog/tutorials/what-is-tanstack-start) guide covers the core concepts in more depth.

The mental model differs from Next.js. There is no App Router, and in the default setup there is no RSC boundary and no `use client` / `use server` split in the rendering model. You define routes as typed objects, load data in loaders (or with TanStack Query), and call the server through server functions. Our kit combines TanStack Start, TanStack Router, TanStack Query, Drizzle, Better Auth, Tailwind CSS 4, Base UI, React 19 and TypeScript in a Turborepo monorepo.

## What Is Next.js?

**Next.js is the most widely used React framework, built around React Server Components and the App Router.** Version 16 uses Turbopack by default and ships RSC streaming, Partial Prerendering, Server Actions, and Route Handlers, with tight Vercel integration. Most React developers already know it, and it has the most documentation, third-party integrations, Stack Overflow answers, and job candidates. Our [Next.js 16 overview](/blog/tutorials/nextjs-16) covers the current release.

The two frameworks differ on where your code runs by default. Next.js moves work to the server through RSC. TanStack Start keeps an explicit client/server line and uses typed loaders and server functions for server work.

## Routing: Both File-Based, Only One Fully Typed

**Both frameworks map files to routes, but only TanStack Start types params, search params and loader data end to end.**

**Next.js** uses folder conventions: a `page.tsx` inside a directory becomes a route, `layout.tsx` nests, and dynamic segments are `[param]` folders. Route types are opt-in through `typedRoutes`, and even then `params` and `searchParams` arrive as loosely typed values you validate yourself.

**TanStack Start** defines each route as a typed object via `createFileRoute`. The compiler infers and checks params, search params, loader data, and context. Here is an authenticated route from the TanStack kit:

```tsx
// apps/web/src/routes/_authenticated/dashboard/index.tsx
import { createFileRoute } from '@tanstack/react-router';

import { AppBreadcrumbs } from '@kit/ui/app-breadcrumbs';
import { PageBody, PageHeader } from '@kit/ui/page';

import { DashboardDemo } from '#/components/dashboard-demo.tsx';
import {
  fetchAccountContext,
  fetchActiveOrganization,
} from '#/lib/auth/account.functions.ts';
import { getTranslator } from '#/lib/i18n/translator.ts';

export const Route = createFileRoute('/_authenticated/dashboard/')({
  loader: async () => {
    const context = await fetchAccountContext();

    if (context.isOrganization) {
      const organization = await fetchActiveOrganization();

      return { organizationName: organization?.name ?? null };
    }

    return { organizationName: null };
  },
  head: ({ loaderData }) => {
    const t = getTranslator();

    return {
      meta: [
        { title: loaderData?.organizationName ?? t('common.routes.dashboard') },
      ],
    };
  },
  component: DashboardPage,
});
```

The `loaderData` in `head` is typed from the loader's return value. `_authenticated` is a pathless layout route (the underscore prefix) that puts every child behind an auth check, defined once in `_authenticated/route.tsx`. In the MakerKit Next.js kit, `apps/web/proxy.ts` (the Next.js 16 name for middleware) redirects signed-out users by matching a list of path prefixes (the app home path and `/settings`). We moved the check out of `(internal)/layout.tsx` because a layout that reads the session cannot be prerendered with Cache Components enabled. The `(internal)` route group now only organizes files: putting a page in it does not protect it. A new top-level authenticated path has to be added to the prefix list in `proxy.ts`, and pages should still check the session and authorization where they load data. So in Next.js, whether a route is protected depends only on that prefix list; in TanStack Start, it depends on which parent route the file is nested under.

This is the largest day-to-day difference. In TanStack Start, if you rename a route or change a search-param schema, TypeScript reports every `Link` and `navigate` call that no longer matches. In Next.js you find out at runtime, or you enable `typedRoutes` and still validate `searchParams` by hand.

Next.js is stronger on layouts and nested rendering. RSC layouts that stream independently work well for content-heavy pages, and the App Router keeps loading and error UI next to the route. TanStack Router offers `pendingComponent` and `errorComponent` per route for the same purpose, but Next.js's RSC streaming is more mature.

## Data Fetching: RSC + fetch vs Loaders + TanStack Query

**Next.js needs less code when RSC fits your page; TanStack Start gives you one data layer (TanStack Query) without a server/client component boundary.** This is where the two frameworks feel most different.

**Next.js** fetches data in async Server Components. You `await` queries directly in the component and RSC streams the result. The framework handles caching, revalidation, and deduplication (`fetch` cache, `revalidatePath`, `revalidateTag`). When it fits, the code is short. It is also the part of Next.js developers most often find hard to reason about: what runs on the server, what is cached, and when it revalidates.

**TanStack Start** fetches in route loaders and, for interactive data, TanStack Query. Loaders run before the route renders, and their return type flows into the component. TanStack Query handles client-side caching, background refetching, mutations, and optimistic updates. If you already add `@tanstack/react-query` to every Next.js app you build (many teams do), TanStack Start makes it the built-in data layer instead of an extra dependency.

The kit adds TanStack Query to the router context at the root:

```tsx
// apps/web/src/routes/__root.tsx (excerpt)
import type { QueryClient } from '@tanstack/react-query';
import { createRootRouteWithContext } from '@tanstack/react-router';

interface RouterContext {
  queryClient: QueryClient;
}

export const Route = createRootRouteWithContext<RouterContext>()({
  // beforeLoad, head, shellComponent, errorComponent, notFoundComponent...
});
```

Because the `queryClient` lives in router context, every loader can prefetch into the same cache the client hydrates. You get server-rendered data and a populated TanStack Query cache on first load. What you give up is RSC's ability to render a subtree with no client JavaScript. For an interactive app behind a login (most SaaS dashboards), that saving is small. For content-heavy public pages, shipping less JavaScript matters more, and Next.js has the advantage.

## Server Logic: Server Functions vs Server Actions

**Server functions carry more precise types from middleware to handler; Server Actions are more established and work with RSC revalidation.** Both let the client call the server without writing an API route.

**Next.js** uses Server Actions (`'use server'`) and Route Handlers. In the Next.js kit, mutations go through a `next-safe-action` style middleware client:

```typescript
// next-drizzle kit: accept-invitation-server-actions.ts
'use server';

import { revalidatePath } from 'next/cache';
import { redirect } from 'next/navigation';

import { authenticatedActionClient } from '@kit/action-middleware';
import { createInvitationsService } from '@kit/organization-core/services';

export const acceptInvitationAction = authenticatedActionClient
  .inputSchema(acceptInvitationSchema)
  .action(async ({ parsedInput: data, ctx }) => {
    await service.acceptInvitation({
      userId: ctx.user.id,
      userEmail: ctx.user.email,
      invitationId: data.invitationId,
    });

    revalidatePath(appConfig.appHomePath, 'layout');
    redirect(appConfig.appHomePath);
  });
```

Server Actions are POST requests and pass through middleware like any other request.

**TanStack Start** uses server functions created with `createServerFn`. The builder chain is `.middleware()`, `.validator()`, and `.handler()`, and the handler's `context` is typed from the middleware that ran before it. Here is a billing action from the TanStack kit:

```typescript
// packages/billing/ui/src/functions/billing.functions.ts (excerpt)
import { createServerFn } from '@tanstack/react-start';
import { redirect } from '@tanstack/react-router';

import { authFunctionMiddleware } from '@kit/function-middleware/functions';

export const cancelSubscriptionFunction = createServerFn({ method: 'POST' })
  .middleware(authFunctionMiddleware)
  .validator(CancelSubscriptionSchema)
  .handler(async ({ data, context }) => {
    const result = await billingService.cancelSubscription({
      userId: context.user.id,
      ...data,
    });

    if (result.data) {
      throw redirect({ href: result.data as string });
    }

    return { success: result.success };
  });
```

The kit's `@kit/function-middleware` package exports pre-composed middleware tuples for each authorization level:

```typescript
// packages/function-middleware/src/functions.ts (excerpt)
export const authFunctionMiddleware = [errorMiddleware, authMiddleware] as const;
export const adminFunctionMiddleware = [errorMiddleware, adminMiddleware] as const;
export const organizationFunctionMiddleware = [
  errorMiddleware,
  organizationMiddleware,
] as const;
```

### Production gotcha: call `createServerFn` literally

You must call `createServerFn(...)` directly at the definition site. If you wrap it in a factory function that returns the builder, TanStack Start's compiler cannot detect the server function, so it does not strip the handler (and the database and auth modules it imports) from the client bundle. The result is server code shipped to the browser. The RSC model in Next.js does not have this failure mode. The kit avoids it by exporting middleware tuples, as above, instead of factories, and documents the rule inline.

Server functions also pair directly with TanStack Query's `useMutation`. Server Actions, in turn, work with RSC revalidation (`revalidatePath`, `revalidateTag`), which TanStack Start has no exact equivalent for.

## Build and Deploy: Vite + Nitro vs Turbopack + Vercel

**TanStack Start builds with Vite and serves through Nitro, so one build runs on Node, Vercel, Cloudflare and other hosts.** Vite's dev server provides fast HMR, and Nitro produces a self-contained server bundle at `apps/web/.output` that you start with `node .output/server/index.mjs`. [Nitro's deployment presets](https://nitro.build/deploy) target other platforms without code changes. The kit's production docs cover [Docker](/docs/tanstack-drizzle/going-to-production/docker) and [Railway](/docs/tanstack-drizzle/going-to-production/railway), and the same bundle runs on AWS, Fly.io, or any Node host. Deploy portability is the main lock-in argument against Next.js.

The kit runs Vite 8 with the Rolldown bundler and Nitro on the server:

```typescript
// apps/web/vite.config.ts (excerpt)
import { defineConfig } from 'vite';
import { tanstackStart } from '@tanstack/react-start/plugin/vite';
import { nitro } from 'nitro/vite';
import viteReact from '@vitejs/plugin-react';
import tailwindcss from '@tailwindcss/vite';

const config = defineConfig({
  envPrefix: ['VITE_'],
  plugins: [
    serverLeakGuard(),
    devtools(),
    nitro(),
    tailwindcss(),
    tanstackStart({ importProtection: { behavior: 'error' } }),
    viteReact(),
  ],
});
```

**Next.js builds with Turbopack (the default in version 16) and deploys most smoothly to Vercel.** Self-hosting is supported and documented, but several features (middleware behavior at the edge, image optimization, ISR, analytics) need the least configuration on Vercel. That helps if you already use Vercel and constrains you if you don't.

The TanStack kit's Vite config also contains workarounds for SSR bundling problems: tslib's UMD interop, a `use-sync-external-store` shim for Base UI, and keeping `pino-pretty` external. The kit ships with all of them resolved, but they show that the Vite + Nitro + Rolldown toolchain is younger than Next.js's build pipeline, and you will hit this kind of issue more often. Next.js's build has been used by more teams for more years.

## Does TanStack Start Support React Server Components?

**Only experimentally. If RSC is central to your architecture, choose Next.js.**

**Next.js has the mature RSC implementation.** Server Components, streaming, Suspense boundaries, and Partial Prerendering are what the App Router is designed around. If you want server-only subtrees, less client JavaScript, and progressive HTML streaming, Next.js supports all of them in stable releases.

**TanStack Start is not RSC-first.** By default it renders on the server, hydrates on the client, and can run as an SPA. In April 2026 the TanStack team [announced experimental RSC support](https://tanstack.com/blog/react-server-components) that treats server components as data: server-rendered fragments the client can fetch, cache, and compose, rather than a server-first component tree. It is marked experimental, and our kit does not use it. The kit uses SSR plus TanStack Query hydration.

So if your reason for choosing a framework is RSC, choose Next.js. If you wanted RSC for typed data, fast loads, and good DX, TanStack Start gets you those through loaders and TanStack Query, and for an authenticated app the RSC advantage is smaller than it is for public content pages.

## Auth, Billing, and Multi-Tenancy: The Same in Both Kits

**The framework choice does not affect your auth, billing, or tenancy code.** The MakerKit Next.js Drizzle and TanStack Start Drizzle kits both use **Better Auth** for authentication, organizations, and subscriptions, the same **Drizzle** schema, the same billing packages, and the same RBAC model.

Better Auth works in both because it does not depend on a framework: it needs a Postgres connection string and a request context, not the Next.js runtime. Its organization plugin provides organizations, members, invitations, and roles. We compare auth providers in [Better Auth vs Clerk vs NextAuth vs Supabase Auth](/blog/tutorials/better-auth-vs-clerk), the ORM choice in [Drizzle vs Prisma](/blog/tutorials/drizzle-vs-prisma) and, for TanStack Start specifically, in [Drizzle or Prisma for a TanStack Start SaaS](/blog/tutorials/tanstack-start-drizzle-vs-prisma). The production auth setup (session handling, `beforeLoad` guards, and server-function authorization) is in [Better Auth on TanStack Start](/blog/tutorials/better-auth-tanstack-start). If you use Supabase instead, see [Supabase Auth on TanStack Start](/blog/tutorials/tanstack-start-supabase-auth).

In the port, the `@kit/better-auth`, `@kit/billing`, `@kit/database`, and `@kit/rbac` packages moved across with few changes. We rewrote the routing, the loaders, and the server-action layer: the Next.js kit's `@kit/action-middleware` (Server Actions built with `authenticatedActionClient`) became `@kit/function-middleware` (middleware tuples passed to `createServerFn`) in the TanStack kit. The Supabase variants follow the same split: Supabase Auth and Postgres RLS are shared, and only the routing and server-call layer differs.

## Developer Experience

### TanStack Start DX strengths

- End-to-end type-safe routing: rename a route and TypeScript reports every broken link.
- Fast Vite HMR.
- TanStack Router and Query DevTools are wired in at the root.
- Server functions pass the middleware context type into the handler.
- No RSC boundary to track; the client/server line is explicit.

### Next.js DX strengths

- The most documentation, tutorials, and Stack Overflow answers.
- RSC + Server Actions need little code when they fit.
- Turbopack dev builds are fast and get faster with each release.
- Vercel preview deployments.

### TanStack Start pain points

- Younger toolchain with more build edge cases (see the Vite config workarounds above).
- The rule that `createServerFn` must be called literally is easy to break, and breaking it leaks server code to the client.
- Smaller ecosystem: fewer prebuilt integrations and fewer existing answers to search.

### Next.js pain points

- Developers often misjudge what runs where and when data revalidates.
- Route type safety is partial; you validate `searchParams` yourself.
- Self-hosting works, but targeting multiple platforms takes more work than switching a Nitro preset.

## Ecosystem and Hiring

**Next.js has the larger ecosystem, community, and hiring pool by a wide margin.** "React developer who knows Next.js" is a common profile; "React developer who knows TanStack Start" is not yet. TanStack Router and TanStack Query are widely used, so many engineers already know the underlying libraries, which shortens onboarding, but the framework itself is newer.

If hiring speed and prebuilt integrations are top priorities, choose Next.js regardless of the technical differences above.

## Is TanStack Start Production Ready?

**Yes. We run a full multi-tenant SaaS kit on it, but Next.js remains the more conservative choice.**

TanStack Start is on its [v1 line](https://tanstack.com/blog/announcing-tanstack-start-v1), and our kit runs on 1.168+ with auth, billing, RBAC, admin, i18n, e2e tests, and a Nitro production build. It releases frequently: features arrive quickly, and APIs change more often than Next.js's. For a new SaaS where you control the stack, it is a reasonable production choice today. For a large team that needs maximum stability and a large hiring pool, Next.js is the safer pick.

## What We Chose and Why

MakerKit ships both kits because the right choice depends on the team, and we keep their features in sync so the framework is the only variable. When customers ask which kit to start with, we ask two questions. Are you already on Vercel and comfortable with the App Router? Take the Next.js kit. Do you want type-safe routing, Vite, TanStack Query as your data layer, and the option to deploy anywhere? Take the TanStack Start kit.

We built the **Next.js kit first** because most of our customers already use Next.js, it has the largest ecosystem, and RSC works well for the marketing and content pages around a SaaS app.

We built the **TanStack Start kit** because customers asked for it: teams that use TanStack Query everywhere, want route type safety the App Router does not provide, and do not want to depend on Vercel or the RSC model. For an authenticated dashboard the RSC advantage is small, and end-to-end type safety, Vite, and Nitro's deploy portability make daily work easier.

What surprised us in the port was how little changed. Better Auth, Drizzle, the billing and RBAC packages, and the service layer moved across with few edits. The routing, loaders, and server-action layer changed. Your application logic stays the same; the framework decides how routes, data loading, and server calls are written.

## TanStack Start or Next.js: Who Should Pick Which

### Pick Next.js if

- RSC, streaming, or Partial Prerendering are central to your architecture.
- You deploy to Vercel and want its full platform features.
- You need to hire quickly from a large talent pool.
- You have content-heavy public pages where shipping less client JavaScript matters.
- You want the most established, conservative choice.

### Pick TanStack Start if

- You want the compiler to check routes, params, and search params.
- TanStack Query is already your data layer.
- You want to deploy anywhere (Node, Cloudflare, Vercel) via Nitro, with low lock-in.
- Vite's dev and build speed matters to your team.
- Your app is mostly an interactive dashboard behind a login.
- You want to leave the App Router without leaving React.

If you are unsure, default to Next.js: it has more documentation, more candidates to hire, and a stable RSC implementation. Choose TanStack Start when its specific advantages (type-safe routing, TanStack Query as the data layer, Vite, Nitro deploy portability, no RSC requirement) match what your team needs. Base the decision on how your app fetches data, where it deploys, and what your team already knows.

To compare the two on identical features, the [MakerKit TanStack Start SaaS starter kit](/tanstack-start) and the MakerKit Next.js kits ([Supabase](/supabase), [Drizzle](/drizzle), [Prisma](/prisma)) ship the same SaaS: auth, billing, multi-tenancy, and RBAC, and both frameworks come in Supabase, Drizzle, and Prisma variants. The Drizzle and Prisma variants differ only in `packages/database`, so the Drizzle code in this post applies to either ORM. The [TanStack Start kit announcement](/blog/changelog/introducing-tanstack-start-kit) lists everything included.

{% faq
   title="Frequently Asked Questions"
   items=[
     {"question": "Is TanStack Start production ready in 2026?", "answer": "Yes. TanStack Start is on its v1 line and is actively developed. We run a full multi-tenant SaaS kit on it: Better Auth, Drizzle, billing, RBAC, admin, i18n, e2e tests, and a Nitro server build. Its APIs change more often than Next.js's, so for a large team that needs maximum stability and an easy hiring pool, Next.js is the more conservative choice. For a new SaaS where you control the stack, TanStack Start is a reasonable pick."},
     {"question": "Does TanStack Start support React Server Components?", "answer": "Only experimentally. TanStack announced experimental RSC support in April 2026, treating server components as data the client fetches and caches. By default TanStack Start renders on the server and hydrates on the client, and our kit uses SSR plus TanStack Query hydration rather than RSC. If RSC is a hard requirement, choose Next.js."},
     {"question": "Does TanStack Start replace Next.js?", "answer": "It is an alternative, not a drop-in replacement. TanStack Start fits teams that want type-safe routing, TanStack Query as their data layer, Vite, and deploy-anywhere output via Nitro. Next.js fits RSC-heavy apps, content sites, Vercel-based teams, and anyone who needs the larger ecosystem and hiring pool."},
     {"question": "Is TanStack Start stable?", "answer": "Stable enough to run a production SaaS, which is why we ship a kit on it. It releases more often than Next.js, and its Vite + Nitro + Rolldown toolchain is younger: our kit's Vite config includes a few documented SSR bundling workarounds. None block production use, but the toolchain has had less real-world use than Next.js's build pipeline."},
     {"question": "What is the biggest difference between TanStack Start and Next.js?", "answer": "Routing type safety and the rendering model. TanStack Start types params, search params, and loader data end to end, so the compiler catches broken links; Next.js route typing is partial and opt-in. Next.js is RSC-first with Server Actions, while TanStack Start uses SSR with typed loaders, TanStack Query, and server functions. Auth, billing, and the ORM can be identical, as our two kits show."},
     {"question": "Can you deploy TanStack Start anywhere, or only on Vercel?", "answer": "Anywhere that runs Node. TanStack Start builds through Nitro to a self-contained server bundle you run with node .output/server/index.mjs, and Nitro presets target Node hosts, Vercel, and Cloudflare. Next.js also self-hosts, but its full feature set needs the least configuration on Vercel."},
     {"question": "What are TanStack Start server functions?", "answer": "Server functions (createServerFn) run backend code that the client can call without a hand-written API route, similar to Next.js Server Actions. They use a builder chain with .middleware(), .validator(), and .handler(), and the handler's context is typed from the middleware. Call createServerFn literally at the definition site, or the compiler cannot strip the handler from the client bundle."},
     {"question": "Should I migrate my Next.js app to TanStack Start?", "answer": "Only with a specific reason: you want end-to-end routing type safety, you use TanStack Query everywhere, you want to move off Vercel or the RSC model, or Vite speed matters. In our port, the auth, billing, ORM, and RBAC packages moved across with few changes; the routing, loaders, and server-action layer were rewritten. If your Next.js app works and you don't need those changes, there is no reason to switch."},
     {"question": "Does MakerKit have both a Next.js and a TanStack Start kit?", "answer": "Yes. MakerKit ships a Next.js kit and a TanStack Start kit with the same SaaS features: authentication, billing, organizations and multi-tenancy, RBAC, admin, and i18n. Both come in Supabase, Drizzle, and Prisma variants. Pick the Next.js kit if you want RSC, the App Router, and the Vercel workflow; pick the TanStack Start kit if you want type-safe routing, TanStack Query as the data layer, Vite, and a Nitro build you can deploy to any Node host."}
   ]
/%}

*Based on the MakerKit Next.js Drizzle kit (Next.js 16.4, React 19.3) and the TanStack Start Drizzle kit (TanStack Start 1.168, TanStack Router 1.170, TanStack Query 5.104, Better Auth 1.7, Drizzle 0.45, Vite 8, Nitro 3 beta) as of October 2026.*