Why I chose Next.js + Laravel over full-stack JavaScript

Every SaaS starter kit on the market picks a side. Either you go full JavaScript (Next.js with Prisma or Supabase) or you stay in PHP land with Laravel and Livewire.

I went with both. Here’s why.

The problem with full-stack JavaScript

The JavaScript ecosystem moves fast. That’s great for innovation, but terrible for stability. ORMs change APIs between major versions. Auth libraries get deprecated. The “best practice” from six months ago is now an anti-pattern.

When you’re building a SaaS, you need boring infrastructure. Auth, billing, email: these things should just work. They shouldn’t break because a library you depend on pushed a breaking change.

Laravel has been solving these problems for over a decade. Sanctum handles auth. Cashier handles Stripe. Queues handle background jobs. These are battle-tested packages maintained by a well-funded team.

The problem with full-stack PHP

On the other side, Laravel’s frontend story is… fine. Livewire is impressive, and Inertia bridges the gap well. But if you want the React ecosystem (component libraries, state management, server components), you’re fighting the framework.

Next.js gives you:

• Server Components for fast initial loads
• Server Actions for type-safe mutations
• React 19 with the entire component ecosystem
• Vercel deployment that just works

Trying to replicate this in Blade or Livewire means giving up a massive ecosystem.

The best of both

Stacktura uses Next.js for the frontend and Laravel as a headless API. Each does what it’s best at:

• Next.js handles routing, rendering, UI components, and client-side state
• Laravel handles auth, billing, database, queues, and business logic
• Docker ties everything together in development

The frontend calls the API through Server Actions. One auth system (Sanctum). One response format. One error pattern. The separation is clean: you can work on the frontend without touching PHP, and vice versa.

Where are the tradeoffs?

I won’t pretend this is free.

Two languages. You need to be comfortable with both TypeScript and PHP. If you’ve only ever written JavaScript, there’s a learning curve. But PHP 8.4 with strict types feels surprisingly modern.

Two deployments. The frontend and backend deploy separately. In practice this is a feature (you can scale them independently), but it’s more infrastructure to manage.

API latency. Every frontend action makes an HTTP call to the backend. Server Actions help (they run server-side), but it’s inherently slower than a monolith where everything is in-process.

For most SaaS applications, these tradeoffs are worth it. You get Laravel’s stability for the things that matter (auth, money, data) and React’s ecosystem for the things users see.

The module system

One thing that frustrated me about other starter kits: you pay for features you don’t need, and removing them breaks everything.

Stacktura has a module system. Run npx stacktura init, pick what you want (auth, billing, admin), and the CLI removes everything else. Files, routes, migrations, even Composer packages. The app still works.

This isn’t a feature flag system. It’s actual code removal. Your production codebase only contains what you chose.

Who is this for?

If you’re a developer who knows React and wants Laravel’s backend without Livewire, this is built for you. If you’ve been copy-pasting the same auth flow and Stripe integration across projects, this saves you weeks.

If you’re all-in on JavaScript and happy with Prisma or Supabase, you probably don’t need this. Use what works for you.

Stacktura is opinionated. It picks a stack, enforces patterns, and gives you a clean starting point. That’s the point.