Archive
Choosing Next.js
Jun 22, 20252 min readEngineering

Choosing Next.js

Why I bet on the Next.js stack for IntentLabs. balancing speed, features, and solo-performance.

When I started IntentLabs, I had a big choice to make: what framework should I use? I’ve worked with everything from simple HTML to complex Java systems. But for a indie studio, the criteria are different.

I didn't need the "most powerful" stack. I needed the stack that gave me the most leverage.

I chose Next.js. Here is why.

The "All-in-One" Framework

Most frameworks handle one thing—either the frontend or the backend. Next.js handles both. As a solo dev, this is huge. I don't have to manage two different codebases or worry about how to connect my API to my UI. It just works.

  • Server Components: I can fetch my blog posts directly on the server. This makes the site fast for you and easy for me to write.
  • Image Optimization: I don't have to worry about resizing images or making them load fast. Next.js does it automatically.
  • Routing: Adding a new page is as simple as adding a new file.

Balancing the "Bleeding Edge"

Next.js is always moving fast. Sometimes, that means things break (hello, hydration errors). But it also means I have access to the latest web technologies without having to build them myself.

I’m using Next.js 15 and the App Router. It has a learning curve, but the "Practical Leverage" it provides is worth it. I can build features in hours that used to take me days.

Humble Architecture

My setup isn't fancy. I’m not using a complex microservices architecture. I have one Next.js app, deployed on Vercel. It’s simple, it’s fast, and it lets me focus on the content and the design instead of the server configuration.

In the next few notes, I’ll dive deeper into how I’m actually using React components to build the IntentLabs aesthetic.