TanStack Start
We build products on TanStack Start, where routing, loaders and server functions are typed end to end and the whole application deploys as a single edge artifact.
| In production | Since 2025 |
|---|---|
| Projects | 3 |
| Evidence | 4 products, incl. this site |
- File-based routing with typed params
- Loaders and server functions
- SSR with streaming, and static prerendering
- Deployment as one Cloudflare Worker
- Markdown-driven content pipelines
- Migration from Next.js
You want the types to reach the server
Route params, loader data and server functions are typed end to end, so a renamed field breaks the build rather than production.
Mostly static, partly dynamic
Prerender the pages that can be, keep the rest server-rendered, and ship both from the same deploy.
Edge deployment matters
It targets Workers directly, so the app and the API arrive as one artifact rather than a frontend plus a separate backend.
Content lives in the repo
Markdown loaded at build time gives content pages with no CMS to run and no runtime fetch.
You need the largest ecosystem
Next.js has more integrations, more hiring supply and more answers already written. That is a real argument and sometimes the deciding one.
The team has no appetite for a younger framework
It moves faster than Next and the surrounding material is thinner. Worth choosing deliberately, not by accident.
A heavy existing Next codebase
Migration is usually worth it only alongside work you were going to do anyway.
Where we use it
Socialog, MandarinAI and Bikkel all run on TanStack Start, each shipping as a single Cloudflare Worker that serves the application and its API together. This site runs on it as well, prerendered at build time and served from a single Worker.
Bikkel is the clearest illustration of what it buys you: two product surfaces, a phone-first training app and a desktop planning hub, over one shared core, with auth, billing and an MCP server, all in one deploy.
What it is good at
Two things, mostly. The types genuinely reach the server, so route params and loader data are checked rather than asserted. And the deploy is one artifact, which removes the whole category of problems that comes from a frontend and a backend drifting apart in versions and environments.
The prerender-plus-SSR combination is the other practical win: content pages become static HTML at build time while the dynamic routes stay server-rendered, without maintaining two systems to do it.
Being straight about the trade
It is younger than Next.js and the ecosystem around it is thinner. If your team needs the largest possible pool of integrations and hiring supply, that is a legitimate reason to choose Next, and we will build you a good Next application instead. We pick Start when type safety across the boundary and a single edge deploy are worth more than ecosystem size.
Tell us the one thing it has to do.
If it's sharp enough to prove in a week, we'll say so and give you a date. If it isn't, we'll tell you that too, along with what we'd build first instead.