Inertia.js gives you a single-page-app feel without building a separate frontend. Laravel API + React gives you flexibility across surfaces at the cost of complexity. The choice between them is the most consequential frontend architecture decision a Laravel team makes — and it depends on what your application has to do, not on what is trendy.
The short version: Inertia for B2B SaaS, admin-heavy products, and applications where one web frontend is the whole product. Laravel API + decoupled React (or Next.js) when you have a mobile app sharing the backend, a public API for partners, multiple frontends, or a large team that benefits from clean API boundaries. Below we walk through three scenarios for each and the decision framework.
What Inertia actually does
Inertia.js is not a framework. It is a thin bridge between Laravel and React (or Vue, or Svelte) that lets you build a single-page-app experience without writing an API. The pattern: your Laravel route returns an Inertia response containing the page component name and its props. Inertia's client library swaps the page client-side and renders the new React component with the new props. No JSON endpoints to design, no API versioning, no client-side auth, no CORS — just controllers that return React pages with Eloquent data.
The result feels like a SPA: client-side routing, no full-page reloads, smooth transitions. Under the hood it is a Laravel monolith. Auth is Laravel's session-based auth. Forms post to Laravel controllers. Validation errors flow back through Inertia's shared props. It is dramatically less code than the API + SPA pattern, and the team operates one codebase instead of two.
Three scenarios where Inertia is the right call
Scenario 1 — B2B SaaS with one web frontend
Most B2B SaaS products are CRUD-shaped, admin-heavy, and live entirely in a web browser. The customer logs in, manages their account, configures settings, views reports, exports data. There is no mobile app, no partner API, no second frontend. For this shape of product, Inertia is the cleanest architecture available in 2026. One repo, one deploy, full SPA experience, Laravel's full power available everywhere. Statamic, Pinkary, Beam, Forge, and Laravel's own apps all run on Inertia.
Scenario 2 — Admin-heavy applications
Internal tools, ops dashboards, agent-facing applications, custom admin panels. These applications need rich UX (forms with validation, dynamic tables, modals, drag-and-drop) but are mostly Laravel underneath. Inertia delivers the UX without the cost of a separate API. The team builds in Laravel controllers + React pages and ships features in days rather than weeks.
Scenario 3 — Small teams that need to move fast
For a team of 3 to 6 engineers, the API + SPA pattern doubles the codebase, the deploy pipelines, the auth complexity, and the cognitive load. Inertia keeps everything in one place. We have seen small teams ship 30 to 50% faster on Inertia than on a decoupled equivalent — not because the framework is faster, but because the team is not paying the API-design tax on every feature.
Three scenarios where Laravel API + React wins
Scenario 1 — Multi-platform product
If you have (or will have) a mobile app, a partner API, a public API for integrations, or any second consumer of your data, the API + SPA pattern is the right call from day one. The web frontend, the mobile app, and the partner integrations all consume the same Laravel API. The API becomes the single source of truth for what the product can do; the frontends are interchangeable consumers.
Building Inertia first and adding an API later is a real engineering project — effectively rebuilding every controller's logic as JSON endpoints. Starting with the API + SPA pattern saves that rework.
Scenario 2 — Large teams with backend / frontend specialisation
For teams above 10 engineers where backend and frontend specialists work in parallel, the API + SPA pattern enables real concurrency. Backend engineers build and version the API. Frontend engineers build the SPA against the API contract. The two sides move at their own pace, with the API contract as the integration point. Inertia merges these roles, which is great for small teams and constraining for large ones.
Scenario 3 — SPA UX that genuinely benefits from full React control
Real-time collaboration tools, complex visual editors, drag-and-drop builders, video tools, interactive dashboards with deep client-side state. These applications use React not for “feels like a SPA” reasons but because the UX genuinely needs React's state model and component composition. Inertia's shared-props model gets in the way; a fully decoupled SPA with TanStack Query for server state and Zustand for client state is cleaner.
The honest trade-off table
Build time. Inertia wins decisively — one codebase, no API design work. Estimate 30 to 50% less build time for the same product on Inertia.
Ongoing maintenance. Inertia wins — one codebase, one deploy, one team. API + SPA needs more engineering attention permanently.
Flexibility. API + SPA wins decisively — the API is reusable across any frontend; Inertia is web-only.
Mobile. API + SPA wins if you have a mobile app. Inertia does not work for native mobile.
Performance. Roughly equivalent. Inertia ships less initial JavaScript (no separate API client, no client-side auth, no React Router). API + SPA can ship a slightly smaller server response. Both can be fast or slow depending on engineering work.
Team complexity. Inertia wins for small teams. API + SPA wins for large teams with specialisation.
Type safety end-to-end. API + SPA with TypeScript and tRPC or generated types wins. Inertia has type-safe props but the type chain is less integrated.
The honest decision framework
Three questions usually resolve the choice:
Question 1: Will you have a mobile app or a second frontend in 18 months? Yes → API + SPA from day one. No → Inertia is simpler and faster.
Question 2: Is your team primarily Laravel / PHP engineers, or do you have dedicated frontend engineers? Laravel-native team → Inertia. Specialised frontend team → API + SPA.
Question 3: Is the application primarily CRUD + admin, or is the frontend genuinely interactive? CRUD / admin → Inertia. Heavy interactive UX (editors, real-time, collaboration) → API + decoupled SPA.
What we ship at Dream Steps
Roughly 50% of our Laravel builds in 2026 are Inertia (with React or Vue). Roughly 35% are Laravel API + React (mostly Vite, sometimes Next.js for marketing-plus-app combinations). The remaining 15% are pure Laravel + Blade (for content-heavy applications that do not need SPA UX) or hybrid setups (Inertia for the admin, decoupled SPA for the customer-facing product).
When clients come to us with the decision unmade, we recommend Inertia by default unless one of the three “API + SPA” scenarios applies. The default keeps the team small, fast, and shipping. The exception cases are worth the complexity when they genuinely apply, and a real engineering cost when they do not.
Common questions
Can Inertia handle real-time updates?
Yes, in two ways. Laravel Echo + Reverb (or Pusher) handles real-time broadcasting to Inertia pages just like any React app. Inertia's shared props can also be polled with Inertia's router.reload() at intervals for less time-sensitive updates. For heavy real-time (live collaboration, multiplayer), the decoupled API + React pattern is usually cleaner because the SPA owns the WebSocket connection and state management more directly.
Does Inertia work with TypeScript?
Yes, well. The Inertia React adapter has TypeScript support; you type your page props and your forms. Laravel side can generate types via tools like Spatie's laravel-typescript-transformer or tightenco/typedeskpie. End-to-end type safety is not as integrated as tRPC + TypeScript on a pure Node.js stack but is solid in production. We use TypeScript on every Inertia build.
Can I migrate from Inertia to Laravel API + React (or vice versa) later?
Yes, but it is a real migration, not a simple refactor. Inertia → API + SPA means designing and building an API that mirrors what Inertia controllers currently do, then rebuilding the frontend to call it. Plan for 60-80% of the time of a fresh API + SPA build. Reverse direction is easier — you collapse the API into Inertia routes — but still significant work. The lesson: pick the right architecture from day one and avoid the migration.
What about Livewire instead of Inertia?
Livewire is Laravel's server-driven UI framework — you write Blade components with PHP backing, and Livewire handles the JavaScript automatically. Excellent for admin panels and forms-heavy applications where you do not want to write any frontend code. Limited when you need real React component libraries (Radix, React Aria, complex data grids) or want full client-side control over UX. We use Livewire for admin and back-office work where the team is fully PHP-native; Inertia for SaaS applications where we want React's component ecosystem; API + SPA for everything else.
Should I use Next.js or Vite for the React side of API + SPA?
Vite for the SPA itself — faster build times, simpler config, no SSR overhead for a logged-in product. Next.js if the same React app also serves marketing pages that need SEO. We commonly ship both: Next.js (App Router with Server Components) for the marketing surface that benefits from SSR + SEO, Vite + React Router for the in-app SPA that the customer uses after login. Two builds, one design system, one API. Cleaner separation than forcing Next.js to do both jobs.
Deciding between Inertia and decoupled API + React?
Tell us about the product, the team, and whether you will have a mobile app or partner API in 18 months. We will tell you on the first call which architecture fits.