Railway, a major cloud platform for deploying applications, just published what many developers have been quietly grumbling about for months: Next.js builds are painfully slow. Their production builds ballooned to over 10 minutes—6 minutes spent on Next.js alone, with half stuck on the cryptic “finalizing page optimization” step. They ditched it for Vite + TanStack Router and cut build times to under 2 minutes. The Hacker News discussion exploded to 166 comments, with developers sharing similar war stories and questioning whether the “industry standard” framework is actually good for production.
This isn’t just Railway’s problem—it’s a pattern. Next.js is optimized for server-first, SEO-focused applications, but many production teams are building client-heavy SaaS dashboards that don’t need SSR. They’re paying a performance tax for features they’ll never use.
The Build Time Crisis: When 10 Minutes Becomes Hours
Railway’s frontend builds had crept past 10 minutes total, with 6 minutes consumed by Next.js—half of that stuck on “finalizing page optimization” with zero visibility into what was actually happening. For a team shipping multiple times daily, this became an unbearable bottleneck.
After migrating to Vite + TanStack Router, builds dropped to under 2 minutes—a 5x improvement. This isn’t unique to Railway: Hacker News commenters reported similar wins (“12 min → 2 min,” “2.5m → 25s”) after leaving Next.js.
Build times directly impact developer productivity. Ten minutes per deploy means hours of waiting per week. When CI/CD pipelines grind to a halt, teams ship slower, iterate less, and morale suffers. Railway’s migration proves these aren’t just “misconfiguration issues”—the framework itself becomes the bottleneck at scale.
Architecture Mismatch: Server-First vs Client-Heavy
Next.js is architected for server-side rendering and SEO optimization—perfect for marketing sites and e-commerce. But Railway’s application is predominantly client-side with real-time features and websockets. They were paying the cost of SSR/SSG features they didn’t need while getting minimal benefit.
Railway’s engineering team was explicit: “Our application is predominantly client-side with real-time features and websockets. Next.js prioritizes server-first patterns, but that’s not what we need. The App Router would have required rebuilding around server-first paradigms our product doesn’t need.”
This is the core issue: framework philosophy matters more than features. If your app is behind authentication with no SEO requirements, Next.js’s server-first overhead is pure waste. For client-heavy SaaS dashboards, Vite’s lean, client-first approach is a better fit—Vite delivers 30-50% faster builds on average with dev server startup in ~300ms versus Next.js’s 2-8 seconds. Railway’s 5x build improvement proves it.
The “Finalizing Page Optimization” Black Box
Three minutes of Railway’s builds were stuck on “finalizing page optimization” with zero visibility. No progress bar, no logs, no way to diagnose what was happening. This is a common complaint: developers wait helplessly while Next.js does…something.
When build tools are opaque, developers can’t optimize. Railway couldn’t diagnose why 3 minutes were wasted—they could only wait or migrate. This lack of transparency is a red flag for production-critical tooling.
But What About Turbopack?
Next.js 16.2 introduced Turbopack, a Rust-based bundler that delivers 87% faster startup and significantly improved build performance. Some developers report 6 min → 2 min builds just by enabling Turbopack—without leaving Next.js.
A Hacker News commenter noted: “Recently switched to turbopack. We saw build times go from 6 mins to 2 mins. The article doesn’t mention if they tried Turbopack first.” This is a fair point: Railway’s post didn’t specify whether they tested Turbopack before migrating.
Before migrating frameworks (a significant undertaking), teams should try Turbopack. It may solve 80% of build time issues without the cost of rebuilding routing, SEO tooling, and image optimization. However, Turbopack doesn’t address the architecture mismatch—if your app is client-heavy, Next.js’s server-first bias remains overhead.
When to Migrate (and When Not To)
Migration makes sense for client-heavy SaaS dashboards with no SEO requirements and high deployment frequency. It doesn’t make sense for SEO-dependent marketing sites, e-commerce, or teams already happy on Vercel.
Migrate if:
- Client-heavy SaaS dashboard (Railway’s case)
- Behind authentication (no SEO needs)
- Shipping multiple times daily (build times matter)
- Real-time/WebSocket features (client-first architecture)
Stay on Next.js if:
- SEO is critical (blogs, marketing sites, e-commerce)
- Server-side rendering provides real value
- Already on Vercel and happy
- Turbopack solves your build time issues
The “industry standard” isn’t always the right choice. Developers need clear decision criteria based on their actual requirements—not marketing hype or ecosystem lock-in. Railway’s migration provides a template: evaluate your architecture needs first, then choose the tool that fits.
Key Takeaways
- Railway cut build times from 10+ minutes to under 2 by ditching Next.js for Vite + TanStack Router
- Next.js’s server-first architecture is overhead for client-heavy SaaS dashboards that don’t need SEO
- Try Turbopack before migrating—it may solve build time issues without framework changes
- The “finalizing page optimization” black box makes debugging impossible; lack of transparency is unacceptable
- Evaluate your architecture needs first: Next.js excels for SEO-dependent sites but becomes bloat for client-first apps
