28 FEB 2026 · 3 min read

The Laravel + Inertia sweet spot

Why this stack keeps showing up in everything I build, and where it stops being the answer.

Most products I work on are not SaaS at consumer scale. They are internal tools, line-of-business apps: the workhorses that keep a company running but rarely make it into a case study. Maintenance dashboards. Job card systems. CRMs built around a workflow that no off-the-shelf tool quite fits. For that shape of problem, Laravel + Inertia is the most productive stack I have found.

The appeal of Laravel is well-documented enough that I will not relitigate it. It is opinionated in exactly the right places (routing, auth, queues, mail, notifications) and flexible where flexibility matters. You can move fast without accumulating the kind of debt that makes moving fast unsustainable.

The trick is Inertia.

Inertia erases the API layer for apps that do not need one. You write a controller, return a page component with some props, and your frontend is a React or Vue component that receives those props. State lives where it belongs. There is no auth token dance, no duplicated validation logic, no API spec to maintain for an endpoint only your own frontend will ever call.

The mental model stays simple: a request comes in, a controller handles it, a component renders the result. Every developer who has worked with a server-rendered framework immediately understands it. Onboarding a new engineer is measured in hours, not days.

Where it stops working.

The seams show in a few situations. Real offline support (a field app that works without connectivity) needs something different. Deeply interactive flows that don't map cleanly to pages fight the page-based mental model. And if you are building a public API regardless, the calculus changes: a thin API plus a proper SPA costs about the same in complexity.

Knowing when to leave a stack is as important as knowing when to use it. Reading the shape of the problem before you start is cheap. Refactoring out of a stack mid-project is expensive.

For the right problem, it's hard to beat.

But for the 80% of problems that look like forms, lists, dashboards, and workflows (the unglamorous, load-bearing software that most engineering teams actually spend most of their time on), this is the stack I reach for, every time.

Tri2b · the studio