Next.js was the default choice for our stack. Here's why we picked Laravel instead once the client's hosting reality entered the conversation.
The question nobody asks before choosing a framework
Most stack decisions get made in a vacuum. We open a terminal, run npx create-next-app, and start building before anyone has asked the one question that actually matters for a project's long-term survival: where is this thing actually going to live once it's done?
The client's constraint was simple and non-negotiable: shared hosting with cPanel, no dedicated server, no DevOps budget, and one person on their side who would eventually take over basic maintenance. That one fact ruled out more "modern" stacks faster than any technical benchmark could.
The default choice, and why it didn't fit
Next.js is a genuinely good framework. Server components, edge rendering, a mature ecosystem, and a hiring pool that keeps growing. On paper, it should have been the obvious pick.
In practice, Next.js expects a persistent Node.js runtime, or a platform built around one (Vercel, a Node-capable VPS, a container orchestrator). Most shared cPanel hosting environments either don't support Node at all, or offer it through "Setup Node.js App" tooling that is inconsistent across hosting providers, resource-capped, and often unfamiliar to the hosting support staff who'll actually be troubleshooting it at 11pm when something breaks.
That last part matters more than it sounds. A framework choice isn't just a technical decision, it's a decision about who can support the system after you leave the project. If the client's future maintainer can SSH in, run composer install, and restart PHP-FPM, that's a very different maintenance reality than one requiring a Node process manager, environment-specific build steps, and a deploy pipeline nobody on their side understands.
What we actually optimized for
We ranked the decision against four criteria, in this order:
- Hosting compatibility. Does it run on what the client is already paying for, without an infrastructure upgrade they didn't budget for?
- Maintainability by a non-specialist. Can someone with basic PHP familiarity keep this alive without calling us every time something breaks?
- Ecosystem maturity for this exact constraint. How many other teams have solved "deploy this on shared hosting" for this framework, and how well-documented is it?
- Development speed for the actual scope. Not "which framework is more impressive," but which one gets this specific set of features shipped fastest.
Laravel won on all four. It has over a decade of shared-hosting deployment patterns already documented by the community. It runs on plain PHP-FPM, which every cPanel host supports natively. Background jobs that would normally need a long-running worker process can be scheduled through cPanel's cron jobs instead. And because the client needed a CMS-backed content layer more than a highly interactive frontend, Laravel's Blade templating (or Livewire, where interactivity was genuinely needed) covered the requirement without introducing a separate frontend build pipeline at all.
The honest trade-off
This isn't a "Next.js is bad" article. We gave up things by not using it: no built-in edge rendering, a smaller pool of frontend-specialist hires familiar with the exact setup, and a less trendy answer when someone asks "what's your stack." If the project had needed a highly interactive, app-like frontend, or if the client had actual DevOps capacity and budget for modern infrastructure, this decision would have gone the other way.
That's the actual point. The right framework isn't the one with the most momentum on tech Twitter, it's the one that matches the constraints of the specific system you're building, for the specific people who'll run it after you're gone.
To be fair to Next.js: if the client already runs on modern infrastructure (a VPS with Node support, or a platform like Vercel), if the project genuinely needs a rich, app-like interface, or if the team maintaining it long-term is a frontend-first engineering team, Next.js is very often the better call. The lesson isn't "always pick Laravel." It's "ask about the hosting reality before you pick anything."
This is the kind of decision we walk through with every client before writing a single line of code: what does this system need to do, and who needs to be able to keep it running once we're done. If that sounds like a conversation you need to have about your own project, get in touch.