# Next.js vs TanStack Start: why Lovable, Railway and Inngest switched > Lovable, Railway and Inngest left Next.js for TanStack Start. Their numbers, their real reasons, and how to decide whether your project should switch or stay. By Salaheddine Elfatimi, Full Stack Developer in Marrakech. Published 5 October 2026. Updated 5 October 2026. Canonical: https://salaheddine-elfatimi.com/blog/next-js-vs-tanstack-start ## Key takeaways - Lovable, Railway and Inngest moved production apps from Next.js to TanStack Start in 2026. - Lovable's dev server went from 70 s and 8 GB to 10 s and 1.5 GB; Railway's builds from 10+ minutes to under 2; Inngest's local loads from 10-12 s to 2-3 s. - Their reasons are specific: dogfooding, a client-side dashboard on the Pages Router, and a small team's mental overhead. - TanStack Start is still a release candidate; for content sites that need Google, Next.js remains a good fit. Next.js vs TanStack Start became a real debate in 2026: Lovable, Railway and Inngest all moved their production apps off Next.js, and all three report faster builds and a faster local setup. But their reasons are specific to their apps, and TanStack Start is still a release candidate. My short answer: for a website or blog that lives on Google, Next.js is still a good fit, and this site stays on it. For a dashboard that runs mostly in the browser, TanStack Start is worth a serious look. Here are their numbers, their reasons, and how to decide. ![What changed for each team, in their own numbers.](https://salaheddine-elfatimi.com/uploads/2026/10/leaving-nextjs-cover-82a05b4d.webp) ## What is TanStack Start? TanStack Start is a full-stack React framework built on TanStack Router and Vite, from the team behind TanStack Query. Routes are explicit and fully typed, and server code lives in server functions you call from your routes, instead of the `"use client"` / `"use server"` split of the Next.js App Router. [Its docs](https://tanstack.com/start/latest/docs/framework/react/overview) say it's "currently in the Release Candidate stage": feature-complete with a stable API, but not yet 1.0. That difference in how server and client code are written is the heart of the Next.js vs TanStack Start question. ## Lovable: 42 million visitors a month, moved route by route Lovable's site has more than 42 million monthly unique visitors and close to 400 routes. [In their write-up](https://lovable.dev/blog/how-we-migrated-lovable-dev-away-from-nextjs) (18 August 2026), they report: - **Dev server start:** 70 seconds and 8 GB of RAM on Next.js, 10 seconds and 1.5 GB on TanStack Start. - **Production build:** 12+ minutes before, 6 to 9 minutes after. - **Server response:** median time to first byte down 49%. The method is the most useful part. They didn't rewrite everything at once: both frameworks ran side by side behind a proxy, and routes moved group by group behind feature flags. By the end, only 3% of the code was specific to Next.js. It took six months, during which the codebase grew from 350K to over 850K lines, and it had one incident: an 11-minute out-of-memory outage. ![Lovable's own account of the migration, published 18 August 2026.](https://salaheddine-elfatimi.com/uploads/2026/10/leaving-nextjs-proof-dcd580fa.webp) ## Railway: builds from 10+ minutes to under 2 [Railway moved its whole frontend](https://blog.railway.com/p/moving-railways-frontend-off-nextjs) in April 2026: 200+ routes, two pull requests, zero downtime. Builds had crept past 10 minutes, six of them spent on Next.js alone; on Vite and TanStack Router they take under two. Their title says it well: "Next.js served us well. Then it didn't." ## Inngest: a small team tired of waiting [Inngest's team](https://www.inngest.com/blog/migrating-off-nextjs-tanstack-start) is small, and most engineers don't spend their week in the frontend. Local page loads had reached 10 to 12 seconds, and they tried Turbopack twice without much gain. After moving to TanStack Start, first loads take 2 to 3 seconds and the next routes are nearly instant. One engineer did it in a couple of weeks, with AI doing the repetitive conversions. ## Why they really left Next.js ![Three different reasons, and none of them is a content site that depends on search.](https://salaheddine-elfatimi.com/uploads/2026/10/leaving-nextjs-why-8f6d66f9.webp) - **Lovable** builds and hosts its users' apps on TanStack Start. Moving its own site onto the same stack is dogfooding: they want to feel what their users feel. It's not a verdict on Vercel, which they say "performed admirably". - **Railway**'s app is "overwhelmingly client-side": a real-time dashboard with websockets everywhere. They were still on the older Pages Router and weren't using the server-first features of Next.js at all. - **Inngest** found the mental model too heavy for a small team: `"use client"` and `"use server"` directives, layered caches and unclear server/client boundaries, on top of slow local loads. Notice what's missing: none of them is a marketing site, a blog or a shop that needs to rank on Google. That's where Next.js's server rendering earns its place. ## Next.js vs TanStack Start: should you switch? ![A quick way to decide, based on what your app actually does.](https://salaheddine-elfatimi.com/uploads/2026/10/leaving-nextjs-decide-2c9d3c76.webp) - **Stay on Next.js** if you run a website, blog or shop that depends on search, if you already use server components well, or if you need a framework that's past 1.0 today. - **Try TanStack Start** if your app is a dashboard that lives in the browser, if slow local development costs your team every day, or if the client/server directives keep tripping people up. - **Check first:** Lovable notes that Next.js 16.3 brought up to a 90% reduction in dev-server memory. If your pain is memory, upgrading may be enough. If you do switch, copy Lovable's approach: keep both frameworks running, move routes in groups, and keep shared code free of framework imports. Lovable's author calls a past big-bang migration one of their big professional regrets. ## My take on Next.js vs TanStack Start, as a Next.js developer This site runs on Next.js 16, and I'm keeping it there: it's a content site where pages rendered on the server and good SEO matter more than dev-server speed. I keep it updated, like the [September security release](https://salaheddine-elfatimi.com/blog/nextjs-security-update-september-2026), and the build times haven't been a problem. If I were building a large client-side dashboard today, I'd prototype it in TanStack Start before deciding. ## The video: Next.js vs TanStack Start in 70 seconds [Video: Why three companies left Next.js, explained in Moroccan Darija with English subtitles.](https://salaheddine-elfatimi.com/uploads/2026/10/leaving-nextjs-ar-d6e87ce3.mp4) ## Is your Next.js project getting slow? I build [websites and web apps in Next.js](https://salaheddine-elfatimi.com/services/websites), and I help when an existing project gets slow to build or hard to work on. Sometimes the answer is an upgrade, sometimes it's a migration. If you're not sure which, [get in touch](https://salaheddine-elfatimi.com/#contact) and we'll look at it together. More dev news: [TypeScript 7, the compiler rewritten in Go](https://salaheddine-elfatimi.com/blog/typescript-7-go-10x-faster). ## Frequently asked questions ### Is TanStack Start production ready? Its docs say it's in the Release Candidate stage: feature-complete with a stable API, but not yet 1.0. Lovable, Railway and Inngest run it in production anyway. ### Why did Lovable leave Next.js? Mainly dogfooding: Lovable builds and hosts its users' apps on TanStack Start, so it moved its own site onto the same stack. It also reports a dev server starting in 10 s instead of 70 s and builds of 6-9 minutes instead of 12+. ### Should I migrate from Next.js to TanStack Start? If your app is mostly client-side and slow local development hurts your team, it's worth a prototype. For websites, blogs and shops that depend on search, Next.js is still a good fit, and Next.js 16.3 already cut dev-server memory a lot. ### How do you migrate a large Next.js app? Lovable ran both frameworks side by side behind a proxy and moved routes in groups with feature flags, keeping shared code free of framework imports. Railway did it in two pull requests; Inngest in a couple of weeks.