The headless question reaches every Laravel product team eventually: keep React inside Laravel with Inertia.js, or split into Next.js on the front and a Laravel API behind it?
We build and maintain both configurations for clients, and the honest answer is that they optimize for different things — platform and team topology, not raw capability.
Background on the Inertia side: Inertia.js with Laravel and React — SPA without a separate API.
The two architectures
Inertia.js. One Laravel application serves both HTML and data. Controllers return page components; React renders them; routing, auth and validation are Laravel's. One repository, one deployment, one place to debug.
Next.js + Laravel API. Two applications: a Next.js frontend (SSR/ISR on Vercel or Node) and a Laravel API behind it. The contract between them is an API — versioned, documented, tested on both sides.
| Aspect | Inertia.js + Laravel | Next.js + Laravel API |
|---|---|---|
| Repositories | One | Two |
| Deployments | One (PHP + assets) | Two (PHP + Node/Vercel) |
| Data flow | Server props — no client fetching layer | API calls; caching strategy on the client |
| Auth | Laravel sessions | Tokens / Sanctum + refresh handling |
| SEO | SSR when enabled | SSR/ISR built in |
| Static generation | Not a use case | First-class (marketing, docs) |
| Hosting | VPS / Forge / Ploi | Vercel/edge + PHP host |
| Team topology | One full-stack team | Frontend and backend can split |
| Extra work you own | Nothing extra | API contract, CORS, token lifecycle, cache invalidation |
Where Next.js genuinely wins
- Content-heavy, mostly static sites that live and die by ISR and CDN edges — marketing at scale, docs, content platforms.
- Organizations with separate frontend and backend teams where independent release cycles are worth the contract cost.
- Multi-client backends — when web, mobile and partners all consume the same API, the API is not overhead, it is the product.
- Vercel-standardized teams — platform fit is real value; fighting it wastes months.
Where Inertia.js genuinely wins
- Application-shaped products — dashboards, portals, CRMs, SaaS — where nearly every page is dynamic and personalized.
- Small, full-stack teams that ship faster without a contract to synchronize. The 30–50% lower maintenance cost of a single-repo setup is not marketing; it is the missing second deploy, second auth system and cache invalidation layer.
- SEO without a platform migration — SSR gives public pages crawlable HTML and good Core Web Vitals — see Inertia.js SSR with Laravel.
- When the API has one consumer — an API for a single frontend is a private contract with public-contract ceremony.
Key takeaway: Choose by topology, not by benchmarks. Two teams, multiple clients, static-heavy content → Next.js. One team, one dynamic product, one client → Inertia.js. Both are excellent; the mismatch is what hurts.
What the split actually costs
We have measured this on our own migrations: a two-repo setup adds roughly 20–40% to ongoing maintenance — API versioning, duplicated types, CORS and token plumbing, two CI pipelines, cache invalidation between layers. That cost is worth paying when the topology demands it, and pure waste when it does not. The same calculus appears in Sanctum SPA vs Inertia session auth and Inertia.js vs Livewire.
The pragmatic middle
Plenty of our clients run a hybrid on purpose: a Laravel + Inertia application for the product, and a static or Next-based marketing site at the root domain, connected by links rather than an API. Each tool does what it is best at; neither team maintains a contract neither asked for.
Not sure which topology fits your product and team?
We scope exactly this decision in Laravel development services — usually in one call.
FAQ
Is Next.js faster for SEO?
Both can be fully indexable. Next.js has SSR/ISR built in; Inertia reaches the same with SSR enabled. For an application with public pages they are equivalent in practice.
Can Inertia.js be hosted on Vercel?
No — it renders inside Laravel, so hosting is PHP-first (VPS, Forge, Ploi, Laravel Cloud). If Vercel/edge is your platform, Next.js fits better.
When does the Next.js + Laravel split make sense?
With separate frontend/backend teams, several API clients, or genuinely static-heavy content. Otherwise you maintain two deployments for one consumer.
👉 Deciding between Inertia.js and Next.js? Check our Laravel development services or hire a Laravel developer — we will recommend the topology, not the hype.
📖 Read more: Inertia.js with Laravel and React, Inertia.js vs Livewire and Sanctum SPA vs Inertia session auth.