I Removed Next.js From My Project and It Was the Right Decision

This week I made a decision that took me much longer than it should have: I removed Next.js from one of my production projects.

For a long time, I tried to make it work.

Next.js is an excellent framework and one of the most powerful tools in the modern React ecosystem. But after months of adapting my architecture around it, I realized something important:

Great tools are not always the right tools for every project.

The main challenge: WebSockets

My application relies heavily on real-time communication using Apollo Client, Apollo Server, and GraphQL Subscriptions.

The problem is that the default Next.js server does not support WebSockets by default. Because of that, I had to build a custom server to handle them.

Creating this setup required a significant amount of work. I searched extensively for examples combining Next.js with Apollo and GraphQL subscriptions in a similar architecture, but I couldn't find any that matched my configuration. In the end, I had to design and implement the solution myself.

While the custom server worked, it came with an important downside: you lose many of the benefits of the standard Next.js server, including some optimizations and tooling that make the framework so attractive in the first place.

Development performance became a problem

As the application grew, development performance started to slow down significantly.

I upgraded the project to use Turbopack, hoping to improve compilation speed. The improvement was noticeable, but it still wasn't enough. Navigating between pages in development remained slow, especially because the application had grown to include many pages.

Over time, this started to impact developer productivity.

SEO wasn't a strong reason to keep it

Another important factor was the nature of the product.

Most of the application is behind authentication and used by paying customers, meaning there are very few public pages. Because of that, the SEO advantages often associated with frameworks like Next.js were not a strong justification for maintaining the added complexity.

A decision I should have made earlier

Looking back, I probably should have made this decision sooner.

Sometimes we spend too much time trying to force a tool to fit our architecture instead of stepping back and asking a simpler question:

Is this tool still solving my problems or creating new ones?

Final thoughts

This is not a criticism of Next.js. It remains an outstanding framework and a great choice for many types of applications, particularly content heavy platforms and SEO driven products.

But engineering decisions should always be context driven.

Framework popularity should never replace architectural fit.

Sometimes the most impactful optimization you can make is simply choosing the right level of complexity for your system.

And in my case, removing Next.js turned out to be exactly that.