Choosing a TanStack Start SaaS starter in 2026: what actually matters

If you've decided to build your next SaaS on TanStack Start, the starter-kit market looks smaller than the Next.js one — and that's a feature, not a bug. Fewer options means less time comparison-shopping. But the ones that exist vary wildly in what they actually solve for you, and the answer to "which starter should I buy?" depends less on the feature checklist than on which problems you want off your plate on day one.

This is an honest, opinionated guide to the six things that actually matter when you evaluate a TanStack Start SaaS starter in 2026. We built SarvStack around these criteria — but the criteria are the point. If another kit satisfies them better for your case, buy that one.

Why TanStack Start is different from Next.js for starters

Next.js has been the default "React SaaS" framework for years, and the starter ecosystem reflects that: dozens of kits, all wrestling with the same App Router server-component + server-action mental model.

TanStack Start is different. It's a file-based, client-first framework where server logic lives in typed RPC (createServerFn) and raw HTTP routes when you need them. There's no split-brain "is this a client component or a server component" question at every file. Data loading is TanStack Query, which most React devs already know. SSR is real SSR, not a hybrid RSC compromise.

That simplicity changes what a starter needs to do. You don't need it to abstract away the framework's edges — TanStack Start doesn't have many. You need it to solve the business problems that every SaaS has regardless of framework. That's where the six criteria come in.

The six criteria that actually matter

1. Billing model — merchant-of-record or raw payments?

Every SaaS has to charge money. The question is who deals with sales tax. Raw Stripe/Paddle-Classic style integrations put you on the hook for VAT registration in every jurisdiction you sell to. That's a real compliance burden — the EU alone is 27 rates.

A merchant-of-record (MoR) provider — Polar, Lemon Squeezy, Paddle — becomes the legal seller of record and handles VAT for you. If the starter picks an MoR by default, you saved yourself weeks of tax research on day one. If it picks raw Stripe, you own that problem. Neither is wrong, but you should know which you're buying.

2. A documented security model, not just "we have login"

Most starters ship auth. Fewer ship a documented pattern for what "authorization" looks like once you've got a user.

The specific things to check: is there a working row-level security example wired end-to-end? Are user roles stored on the profile row (a known privilege-escalation footgun) or in a separate user_roles table with a SECURITY DEFINER role-check function? Is there a GRANT-then-RLS-then-policies convention documented for new tables, or will you rediscover it the first time PostgREST returns a permission error?

A starter that hand-waves "we use Supabase, RLS is on" is not the same as one with a hardened, documented multi-tenant pattern.

3. AI-agent readiness

This is the newest criterion and, in 2026, probably the highest-ROI one. You will use coding agents on this codebase. The question is whether the codebase carries enough written conventions that the agent follows them, or whether it looks like every other React project and the agent invents its own patterns.

Concrete signals: is there a CLAUDE.md / AGENTS.md / equivalent that describes the folder structure, naming, and the "how do I add a new X" recipes? Are there slash-command recipes for the agent to consult? Is the design system defined in tokens the agent can read, not scattered text-white and bg-[#hex] literals across components?

We wrote about this in detail in what makes a codebase agent-ready. It's the single biggest force multiplier you can hand your future self.

4. Test and CI reality — does it actually run?

Read the starter's .github/workflows/ci.yml file before you buy. Does CI actually run typecheck, lint, unit tests, and end-to-end tests on every push? Are the tests real, or is there a smoke.spec.ts that visits the landing page and calls it good?

An honest CI pipeline tells you two things: (a) the maintainer actually runs the checks they document, and (b) the tests will keep running as you extend the kit, catching regressions in your own code. A repo full of pristine READMEs and empty test folders is a warning sign.

5. Internationalisation, from day one or bolted on later

If you're targeting a global audience — or even just Europe — i18n is a load-bearing feature, not polish. Retrofitting it is painful: locale-aware routing, dictionaries, missing-key detection in CI, and translated meta tags all touch code you've already written.

Check for: locale-aware routes (not a runtime dictionary switch on a single URL), a CI check that fails when a dictionary key is missing in a locale, and translated <head> metadata for SEO. If those exist on day one, adding a new locale is a mechanical exercise. If they don't, it's a refactor.

6. Delivery and licensing — what do you actually get?

Some kits ship as a private GitHub template. Some as a versioned tarball. Some as a subscription that gives you rolling updates. Some license per-project, some per-developer, some lifetime.

Read the license text. The distinctions that matter in practice: can you build multiple products on it? Can you resell client work built on it? Do you get future updates, and for how long? A kit you'll be extending for years is very different from a kit you'll fork once and forget about.

When you should NOT buy a kit

Kits are not a universal answer. Skip them if:

• You're learning. The best way to understand TanStack Start, RLS, and MoR billing is to wire them up yourself once. A kit short-circuits that learning.
• Your architecture is heavily custom. If you're building a multi-region, sharded, event-sourced system, a starter's assumptions will fight you. Start from create-tsrouter-app.
• You already have a working codebase. Migrating an existing app onto a starter is almost always more work than porting the starter's patterns into your app one at a time.

The value of a kit is compressed time on well-understood problems, not magic. If those problems aren't your bottleneck, don't buy.

SarvStack, honestly

SarvStack is our answer to these six criteria: Polar as MoR, a hardened RLS + user_roles pattern, a CLAUDE.md your agent actually follows, a CI pipeline that runs typecheck + lint + i18n-completeness + unit + Playwright on every push, i18n across EN / DE / ES from day one, and a one-time license with lifetime updates.

We publish a dated, factual feature comparison against the other TanStack Start and Supabase starters we're aware of, and a full feature list with math on what's actually inside the repo. If the criteria above match your priorities, we'd love to have you. If they don't, buy the kit that fits — the criteria matter more than the kit.