Laravel vs NestJS (2026): Which to Choose? Lessons From Real Projects

For quite a while at We Do Dev Work, they knew me as "the Laravel girl".

The short answer: choose Laravel for a conventional business application (accounts, payments, admin screens, queues) that a PHP team has to deliver fast: it makes most decisions for you. Choose NestJS when the backend has clearly separate domains, the team already writes TypeScript, or front end and back end should share one language. Both are opinionated: Laravel decides your stack, NestJS decides your structure.

It was the first backend framework I became really comfortable with, and after using it on projects such as PUT-IT-ON, where I worked on payments, scheduling, queues and other backend functionality, I understood why. Laravel makes me productive. A lot of the decisions you need to make when building a web application have already been made, the different parts of the framework work well together, and once you know the Laravel way of doing things, you can move remarkably quickly.

More recently, I've been working with NestJS, including on EngineeringScore, where we're building a backend that scans websites across security, performance, SEO, accessibility and reliability before combining those results into a transparent score. It's a very different type of project, and NestJS has made me think differently about how I structure backend applications.

The simple conclusion would be that I moved from PHP to TypeScript and discovered that I prefer one over the other, but that's not really what happened. I still like Laravel, and there are plenty of projects where I would choose it tomorrow.

What I found more interesting is that Laravel and NestJS actually belong to the same family in an important way: they are both opinionated frameworks. They don't simply give you a collection of tools and leave you to figure out how everything should fit together. Both have strong ideas about how a backend application should be built.

They just have opinions about different things.

Laravel makes many of the application decisions for me, which is a big part of why it makes me so productive. NestJS leaves more of those technology choices open, but is much more explicit about modules, dependencies and architectural boundaries, which is probably why it makes me think more about architecture.

After working with both, I've realised that this difference is much more useful when choosing between them than simply comparing PHP with TypeScript or making another list of framework features.

Where things stand in October 2026

Since I started writing about this, both frameworks have moved on, so here are the current facts, checked on the official sites.

• Laravel 13 was released on 17 March 2026. It needs PHP 8.3 or newer, gets bug fixes until Q3 2027 and security fixes until 17 March 2028 (Laravel release notes). Laravel 12 still gets security fixes until 24 February 2027, but its bug-fix window ended on 13 August 2026. Laravel 11 is already out of security support.

• PHP: 8.5 (November 2025) is in active support until 31 December 2027. PHP 8.2 reaches end of security support on 31 December 2026 (php.net), so any Laravel app still on 8.2 needs a PHP upgrade soon anyway.

• NestJS 12 was first released on 27 August 2026, and the latest release at the time of writing is 12.1.3 (12 October 2026) (NestJS releases). It requires Node.js 20.19+ or 22.12+, and its core packages now ship as ESM (v12.0.0 notes).

• Node.js: v24 and v22 are the LTS lines and v26 is the current release; the older odd and even lines are end of life (Node.js releases). For production, stay on an LTS line.

One practical difference: Laravel's support policy is simple and predictable (a new major every year in about Q1, 18 months of bug fixes, 2 years of security fixes). NestJS has no fixed support window like that, so with NestJS you are relying on the latest major and on the Node.js LTS schedule. Neither is a problem, but plan an upgrade every year or two either way. If you are weighing the language side too, see Python vs Node.js and, for the other big enterprise pairing, .NET vs Java in 2026.

Being opinionated is a feature, not a limitation

Developers sometimes use "opinionated" as if it were criticism. A framework tells you how to organise something, while a less opinionated technology gives you the freedom to decide for yourself.

That freedom sounds attractive, but every decision has a cost.

If a framework doesn't tell you how to handle something, somebody on the team needs to decide. You need to choose a library, agree on a pattern, document it, make sure everyone follows it and, hopefully, make a decision that you won't regret two years later.

An opinionated framework takes some of those decisions away from you.

This is particularly useful when you're working in a team. When I open a Laravel project created by another Laravel developer, I already have a reasonable idea of what I'm going to find. Routes, controllers, models, migrations, jobs and commands have familiar places. The implementation can obviously still be good or bad, but we at least start with a shared understanding of how the application is organised.

NestJS provides something similar. If I open an unfamiliar NestJS application, I expect to see modules, controllers and providers. I expect dependencies to be injected rather than created randomly throughout the application. Again, none of this guarantees good code, but the framework provides a common language for the developers working on it.

This is why I think Laravel and NestJS are more comparable than they might initially appear. One is a PHP framework and the other sits firmly in the TypeScript and Node.js ecosystem, but both try to give development teams conventions rather than leaving them with a blank canvas.

The difference becomes interesting when you look at which decisions each framework wants to make for you.

Laravel makes a lot of decisions for you

Laravel has a very complete idea of what a web application needs.

Routing, database migrations, validation, authentication, queues, caching, events, scheduled tasks and command-line tooling all have established Laravel approaches. Eloquent gives you an ORM that feels like a natural extension of the rest of the framework, while tools such as Artisan make many repetitive development tasks straightforward.

You can replace parts of that ecosystem if you have a good reason to, but most of the time you don't need to.

That has a huge impact on productivity.

When I'm implementing a feature, I can spend more time thinking about the feature itself and less time deciding which package should solve each technical problem. There is usually a Laravel way of doing it, there is usually good documentation for it, and there is a very large community that has probably encountered a similar problem before.

PUT-IT-ON was a good example for me. The platform required a combination of functionality including payments, scheduling, queues and the normal database-heavy logic you expect from a business platform. There are plenty of architectural decisions involved in building something like that, but there are also many problems that aren't unique to the product.

I don't want to invent a new way of processing background jobs every time a project needs a queue. I don't want to design a migration system because the database schema changed. Those aren't the problems that make PUT-IT-ON unique, so having a framework that already provides strong solutions means more development time can go towards the problems that actually matter to the product.

That's what I mean when I say Laravel makes me productive.

It isn't simply that PHP is quicker to write, or that Laravel has convenient syntax. It's that the framework removes a surprising number of decisions from my day.

Productivity doesn't mean Laravel is only for simple applications

There is an obvious trap here.

When people describe Laravel as easy to use and fast for development, the next conclusion is often that it's perfect for small applications but that you need something "more architectural" once a system becomes large.

I don't think that's fair.

Laravel doesn't prevent you from creating good boundaries, separating business logic or designing a large application properly. You can introduce services, actions, domains, repositories or other patterns where they make sense. Laravel gives you plenty of room to design a sophisticated application.

The risk is actually a consequence of how productive Laravel can be.

Because it's so easy to add another controller method, extend an Eloquent model or put a little more logic into an existing class, you can keep moving quickly for quite a long time without being forced to reconsider the structure. If the development team isn't disciplined, a very productive first year can create a much less productive third year.

That's not Laravel's fault. You can create terrible architecture in any framework, including NestJS.

It does mean that developers need to recognise when the convenience that helped them move quickly at the beginning needs to be complemented by stronger architectural decisions as the application grows.

NestJS has a different opinion

NestJS felt familiar to me in some ways because it's also opinionated, but the emphasis is different.

NestJS has strong ideas about structure.

Modules define boundaries within the application. Controllers deal with incoming requests. Providers contain functionality that can be injected where it's needed. Dependency injection is part of the framework rather than something you introduce later because the codebase has become difficult to test or maintain.

That means architecture becomes visible very early in the project.

Even when you're building a relatively straightforward feature, you're encouraged to think about which module owns it, which provider should implement the logic and which dependencies that provider should have.

Sometimes that's excellent.

Sometimes it's also more work.

If I'm building a very straightforward CRUD application, there are situations where the additional structure doesn't immediately give me much value. Creating another module, provider and DTO isn't automatically good architecture simply because everything has been separated into more files.

Architecture should solve complexity, not create it.

Where NestJS started making much more sense to me was when I worked on a backend where the complexity was already real.

EngineeringScore is a very different backend

EngineeringScore scans websites and evaluates them across several areas, including security, performance, SEO, accessibility and reliability. Those results eventually need to come together to produce a score using a transparent and deterministic methodology.

From a product perspective, that's one feature: scan my website and tell me how good its engineering is.

From a backend perspective, it's a collection of quite different responsibilities.

A performance scan doesn't need to know how accessibility is measured. Security checks have different requirements from SEO checks. The component responsible for calculating a final score shouldn't need to understand every implementation detail of the scanners producing the underlying results.

There are also external services, APIs and background processes involved, which means the backend naturally has several boundaries.

In that environment, the structure NestJS encourages starts becoming very useful.

Instead of asking how we can put all of this functionality into one application, we can think about the different domains inside that application and define how they communicate. Dependency injection makes those relationships explicit, while modules give us a natural place to draw boundaries.

That's what I mean when I say NestJS makes me think more about architecture.

It's not that NestJS magically creates better architecture. A badly designed NestJS application can still have dozens of modules with unclear responsibilities and dependencies going everywhere.

The difference is that the framework keeps putting architectural questions in front of me.

With Laravel, I often feel that the framework is asking, "What do you want to build?"

With NestJS, I more often find myself asking, "Where should this belong?"

Both are useful questions.

NestJS gives you structure, but you still have choices to make

There is another important difference.

Laravel's opinions extend quite far into the technology stack. Eloquent is the obvious database choice. Laravel has its own queue system, migration system, authentication solutions and a broad ecosystem of first-party or closely integrated tools.

NestJS gives you a strong application structure but leaves more of the surrounding choices open.

You might use Prisma or TypeORM. You need to decide how persistence should work. There are different approaches to queues and background processing. Even the underlying HTTP platform isn't completely fixed.

For some teams, that flexibility is exactly what they want. For others, it's just a longer list of decisions.

Neither is automatically better.

If the technical requirements of the application are unusual, having those choices can be valuable because you're not fighting against assumptions made by the framework. If you're building something relatively conventional, having to make those decisions can simply mean spending time solving problems Laravel already solved for you.

This is probably the biggest reason I no longer think of the comparison as PHP versus TypeScript.

It's really a question of where you want the framework to make decisions and where you want your engineering team to make them.

TypeScript is still a major reason

Of course, the language isn't irrelevant.

At We Do Dev Work we use TypeScript extensively, particularly on the frontend, so NestJS has an obvious organisational advantage. Developers already familiar with TypeScript don't need to switch languages when moving between frontend and backend work, and we can use similar tooling and development practices across both.

For a full-stack TypeScript team, that's genuinely useful.

But I wouldn't choose NestJS purely because "one language everywhere" sounds cleaner on an architecture diagram.

A team of experienced Laravel developers isn't suddenly going to become more productive because management decided TypeScript is more modern. Existing expertise matters, and so does the ecosystem surrounding an existing application.

The technology choice has to include the people who are going to use it.

That's particularly important for an agency, because we're not choosing our favourite framework once and then using it forever. Different clients have different existing systems, different internal teams, different requirements and different plans for who will maintain the software after launch.

Sometimes Laravel is the obvious choice. Sometimes NestJS is. Sometimes neither is.

So when would I choose Laravel?

After working with both frameworks, I would lean towards Laravel when the application benefits more from its integrated ecosystem than from having every architectural choice exposed.

Typical examples would include:

• A business application with significant CRUD and database functionality.

• A platform that needs authentication, queues, scheduled jobs, notifications and similar common backend functionality.

• A project where getting a solid first production version online quickly is particularly important.

• An application being built or maintained by a team with strong PHP and Laravel experience.

• A project where Laravel's existing conventions already solve most of the technical problems surrounding the actual business logic.

This is why Laravel worked so naturally for something like PUT-IT-ON. There was plenty of custom business logic to build, but there were also many conventional web application problems where I didn't need the freedom to invent my own solution.

I needed them to work.

Laravel let me focus on that.

And when would I choose NestJS?

I'd lean towards NestJS when the structure of the backend itself is a significant part of the engineering challenge.

For example:

• An application with several clearly separated domains.

• A backend coordinating multiple external APIs or services.

• Systems with several workers or processes performing different responsibilities.

• A TypeScript-heavy development team where frontend and backend knowledge frequently overlaps.

• Applications where explicit dependency boundaries will become increasingly important as the product grows.

• Projects where we deliberately want more control over persistence, infrastructure or other parts of the backend stack.

EngineeringScore fits much more naturally into that category. The scanning domains, scoring logic and supporting services give us real boundaries to model, so the architectural structure isn't there because NestJS told us to create it. It's there because the product actually has that complexity.

That's an important distinction.

Laravel vs NestJS at a glance

Which one should you choose?

My rules of thumb, in the order I apply them:

1. Start with the team. If the people who will maintain it are strong in PHP, choose Laravel. If they live in TypeScript every day, choose NestJS. A framework your team knows beats a framework that looks better on paper.

2. Is the backend mostly conventional? Logins, payments, emails, queues, admin screens and reports: choose Laravel and spend your time on the business logic.

3. Does the product have real separate domains? Several scanners, workers or external APIs that must not know about each other: choose NestJS.

4. Do you need to launch quickly? Laravel usually gets you to a solid first release sooner.

5. Do you share code with a TypeScript frontend? NestJS makes shared types and tooling easy.

6. Still undecided? Pick the one the team knows, and write down the module or domain boundaries either way. Good boundaries matter more than the framework.

If you want a second opinion on a real project, have a look at our projects or talk to us about a dedicated team. And if you already have a Laravel or NestJS app and are unsure how healthy it is, you can run it through EngineeringScore, the free website audit we built with NestJS.

What I ask before choosing now

A few years ago, I probably would have chosen Laravel simply because I knew it best. That's not necessarily a terrible reason, by the way. Being productive with a technology you understand is often more valuable than choosing the theoretically perfect framework you've never used in production.

Today I'd make the decision more deliberately.

Before choosing between Laravel and NestJS, these are the questions I'd want to answer:

• What kind of application are we actually building?

• How much of the backend is conventional web application functionality?

• Where is the real complexity in the product?

• Does that complexity naturally divide into separate domains?

• How many external systems and APIs will the backend coordinate?

• How quickly do we need to reach a useful production version?

• Which technology does the existing team know best?

• Will developers regularly work across both frontend and backend?

• Do we benefit from choosing our own infrastructure components, or are we just creating decisions we don't need?

• Who will maintain this application after two or three years of development?

That final question is one I've started appreciating more as I work on larger projects.

A framework choice isn't only about how pleasant the first sprint feels. You're choosing the conventions that future developers will encounter when they open the project after hundreds of features, integrations, fixes and changes have accumulated.

The best framework is therefore not necessarily the one that lets you write the first endpoint fastest, nor is it automatically the one that gives you the most architectural tools.

It's the one whose opinions fit the application you're actually building.

Am I still the Laravel girl?

Probably.

I still enjoy working with Laravel, and there are many projects where its productivity and integrated ecosystem would make it my first choice. Working with NestJS hasn't convinced me that Laravel was the wrong framework; it has simply given me another way of thinking about backend development.

My original feeling about the two frameworks hasn't really changed either: Laravel makes me productive, while NestJS makes me think more about architecture.

What has changed is that I understand better why.

Laravel is opinionated about a large part of the application stack and removes many decisions that I simply don't need to make on every project. NestJS is opinionated about structure and makes modules, responsibilities and dependencies much more explicit, while leaving more of the surrounding technology in our hands.

That's why I think they belong in the same conversation despite coming from completely different ecosystems. Both frameworks are trying to help developers deal with the complexity of building and maintaining backend applications; they simply choose to remove different kinds of complexity.

And after working with both, that's the question I'd now ask before choosing between them: which decisions do I want the framework to make for me, and which ones are important enough that I want to make them myself?

Sources

• https://laravel.com/docs/13.x/releases
• https://www.php.net/supported-versions.php
• https://nodejs.org/en/about/previous-releases
• https://github.com/nestjs/nest/releases
• https://github.com/nestjs/nest/releases/tag/v12.0.0