Lovable introduces TanStack Start output with SSR, server functions, and type safety
Lovable moved newly generated apps onto TanStack Start, adding route-level SSR, SSG, CSR, server functions, and stricter type-safe boundaries to its generated stack. The migration matters because framework primitives become guardrails for both generated-code quality and deploy-anywhere app behavior.

TL;DR
- Lovable says new projects now ship on TanStack Start with server-side rendering enabled by default, replacing its older Vite plus React Router, static-hosted SPA output Lovable's announcement and Lovable's migration writeup.
- The new output adds route-level SSR, SSG, and CSR choices, which tan_stack's launch thread summarized as per-route rendering inside one full-stack React stack, and which TanStack Start's selective SSR docs describe as configurable on a per-route basis.
- Lovable's old stack pushed backend logic into separate edge functions on different URLs, while the new stack uses colocated server functions that TanStack Start's docs describe as same-origin, type-safe RPC endpoints tan_stack's follow-up post.
- Lovable framed the migration as an AI-quality decision as much as a web-stack one, saying typed routing, server and client boundaries, and end-to-end types give generated code tighter guardrails Lovable's announcement and tan_stack's follow-up post.
You can read Lovable's full migration post, the server functions docs, and TanStack's hosting guide. One scale number also slipped out in the social posts: ElectricSQL's repost of Fabian Hedin said Lovable users are now creating more than 1 million TanStack Start apps per week.
TanStack Start became Lovable's default output
Lovable says the switch has applied to new projects since May 13, with SSR turned on by default and no opt-in step for users Lovable's migration writeup. In the same rollout, tan_stack's launch thread highlighted the practical shape of the new output: SSR, SSG, and CSR can all live in the same app on a per-route basis.
That is a real stack change, not a packaging tweak. Lovable's blog says its previous output was a client-rendered React SPA built with Vite, while the new setup is a full-stack React app on TanStack Start.
Server functions replaced the split frontend-backend pattern
Lovable's blog says the old architecture handled anything backend-like, including email sends, paid API calls, and service-role database access, through separate edge functions deployed independently from the app code that called them Lovable's migration writeup. The new stack moves that logic into server functions colocated with components, matching what TanStack Start's server functions guide describes as server-only logic callable from loaders, components, hooks, or other server functions.
The docs add two details that matter for how Lovable framed this: server functions keep type safety across the network boundary, and they are same-origin RPC endpoints rather than public cross-origin APIs. That lines up with tan_stack's follow-up post, which cast framework primitives as direct guardrails for AI-generated code.
Route-level rendering changed the SEO story
Lovable directly tied the migration to discoverability, saying server-rendered apps are easier for Google, ChatGPT, and Perplexity to read than the older CSR-only output Lovable's announcement. Its blog says prerendering now kicks in automatically at deploy time for routes that do not need per-request data, such as blog and marketing pages, while TanStack Start's selective SSR docs describe the underlying per-route SSR controls.
TanStack's own hosting guide also backs Lovable's "deploy anywhere" claim. It lists support for multiple runtimes and hosting targets, while Lovable's post says its generated apps run on Cloudflare Workers.
Type safety became part of the product surface
The most interesting claim in the rollout is not about SSR. It is Lovable's argument that typed routing, explicit server and client boundaries, and end-to-end types change the quality of apps that an AI system can generate Lovable's announcement.
That argument is easier to take seriously with Lovable's scale number in view. ElectricSQL's repost of Fabian Hedin said users are creating more than 1 million TanStack Start applications per week, which makes framework constraints look a lot like product constraints.
Existing projects only got prerendering
Lovable did not describe this as a breaking platform migration for older apps. Its blog says existing projects keep working as before, but now get prerendering for better crawler readability rather than the full new default stack Lovable's migration writeup.
That is a narrower claim than "everything moved to TanStack Start," and it matters because the announcement is really about the default output for newly generated apps, not a wholesale retrofit of Lovable's back catalog.