The New Way to Build Apps Faster (and Smarter) in 2025

Build Faster, Smarter, and Simpler – Why Next.js Might Be the Framework of the AI Era

If you’re building an app right now, you’ve probably seen Next.js everywhere.

It’s fast.

It’s flexible.

And if you’ve noticed the rise of AI tools, a lot of them are built with it.

Tools like v0.dev are letting developers generate Next.js projects with components from shadcn/ui — styled with Tailwind CSS — in minutes.

This combo isn’t just fast. It’s efficient modern development.

But if you’re like me, you might be wondering: “What’s so special about Next.js? Why not stick with React or Rails?”

I’ve spent years working with Ruby on Rails, and I still use it for some of my apps.
But for most new projects — especially ones involving AI or fast deployment — I’m leaning toward Next.js.

Here’s why this shift is happening, how it compares to Rails, and why Next.js might be the framework of the AI era.

If you’ve built with React before, Next.js might feel like React’s "big brother" — but smarter.

Here’s the difference:

• React: It’s a front-end library. You still have to figure out routing, API calls, and how to deploy your app.

• Next.js: It’s a full-stack framework. Routing, server-side rendering (SSR), API routes, and optimizations like static site generation (SSG) are built in.

With React, you’re constantly piecing together tools.

With Next.js, it’s all included.

Want to deploy? Click a button with Vercel.

Want a fast, SEO-friendly site? Next.js handles it automatically with server-side rendering.

Need back-end API logic? You can write it in the same project — no need for a separate server.

It’s faster.

It’s simpler.

And in an era where everyone wants to ship AI tools quickly, simplicity wins.

If you’ve seen apps like v0.dev, you’ve seen the magic of combining Next.js + Tailwind + shadcn/ui.

Here’s how it works:

• v0.dev generates production-ready code.

• It gives you Next.js components styled with shadcn/ui (a customizable component library) and Tailwind CSS.

• You can take that code, drop it into your Next.js app, and it just works.

No configuring.

No boilerplate.

Instant and beautiful components.

This is a huge deal for AI tools, where speed to market is everything.

With shadcn/ui and Tailwind, you can spin up sleek, responsive UIs in minutes — not weeks.

With Next.js, you deploy instantly with Vercel (or Netlify – which is my go to)

If you’re building AI prototypes, this speed matters.

Big names are already doing it:

• Vercel is using it (they created Next.js, after all).

• Hulu, TikTok, Twitch — they’ve all adopted Next.js for speed, performance, and scalability.

• AI tools like v0.dev are built on this system, generating production-ready apps faster than ever.

I’ve been so efficient at building apps with this combination that this "Next.js + Tailwind + shadcn" combo in my opinion will becoming the stack for modern AI apps.

I’ve been a ruby on rails developers for 12 years.

I know what some of you might be asking.

What About Ruby on Rails?

I’ve spent a lot of time in Ruby on Rails, and to be honest, I still love it.

There’s something special about how Rails handles “convention over configuration.”

You don’t have to set up a bunch of files just to get going.

You type rails new myapp, and boom — you have a full app ready to go.

Rails is still a win if you’re building an MVP. But I’ve been 10x more efficient with Next.js.

All my latest apps are running on Next.js today, and if I ever "level them up" with more users, I’d still consider Rails.

But Rails has its pain points, and I’ve felt every one of them.

1️⃣ Gem Conflicts & Dependency Hell

With Rails, you rely on gems for everything.

And if a gem breaks, it’s your problem.

It’s not unusual to spend hours debugging versions of gems that aren’t playing nicely together.

Next.js has fewer moving parts — and because the JavaScript community is so big, you’re less likely to hit “dependency hell.”

People are on it much quicker than in the rails community.

2️⃣ Webpack Fatigue

Rails used to manage front-end assets with Webpacker.

If you’ve ever dealt with Webpacker errors, you know how painful it is.

Rails has a tendency of making drastic change to the framework which can seriously impact the development when you need to upgrade.

Also you have to deal with the learning curve of getting used to the new thing:

Sprocket, Hotwire… every six month there’s something new.

It’s good but also when those changes are too drastic I find my development slowing down because I have to focus on things I wouldn’t have to otherwise.

If you have a development team, this is how they might feel.

3️⃣ Simpler Back-End Logic

If I need to write an API for an app, I have to set up controllers and routes in Rails.

In Next.js, I just create an “/api” folder and write the logic directly in the project.

4️⃣ Supabase & Simplicity

These days, I use Supabase for my back-end.

It’s like a plug-and-play database with built-in authentication and APIs.

If I’m using Supabase, I don’t need the "full power" of Rails.

In short Next.js feels cleaner, lighter, and simpler.

Now if you’re wondering which framework you should choose.

I still believe in Rails, especially for MVPs and startup-style apps.

If you want something fast, Rails can still deliver.

But if you want something that’s:

• Fast to deploy (like a one-click Vercel deployment)

• SEO-friendly (server-side rendering baked in)

• Easy to manage AI integrations (TensorFlow.js, OpenAI APIs, etc.)
  Then Next.js might be the better pick.

If I were starting fresh today, I’d ask myself:

• “Can I launch with a BaaS (Backend As A Service?” → Next.js (if not – Rails)

• “Am I building a tool that will play with Open AI Api or other AI api?” → I’d lean Next.js every time.

• “Am I using Supabase as my database?” → Go with Next.js. It’s lighter and faster to integrate.

Here why I believe Next.js Might Be the Framework of the AI Era.

AI tools are growing fast.

And fast-growing tools need to ship quickly.

Look at what’s happening:

• v0.dev is helping people generate Next.js + Tailwind components instantly.

• shadcn/ui gives you beautiful, pre-styled components for free.

• Vercel lets you ship those apps with one click.

If you’re a solopreneur going lean with less dependency is hte way to go.

And the combo of Next.js + Tailwind + shadcn/ui + Supabase is the most efficient stack I’ve seen.

It’s that much faster to build production-ready apps, faster than ever.

I built GitGlance MVP in two days, and a week later I built all the core features.

Why It Matters

• You’ll Ship Faster: Faster components, instant deployments, and fewer headaches mean you ship your app faster.

• You’ll Avoid Gem Conflict Hell: No more waiting for gem updates or broken dependencies.

• You’ll Be Future-Ready: AI-driven apps are going to need Next.js.

I still love Rails, but I’m leaning into Next.js for most of my AI-driven projects.

If I’m using Supabase, shadcn/ui, or Tailwind, I want the fastest path to shipping.

Next.js gets me there.

If you’re debating Rails vs Next.js, think about what you’re building:

• Need to ship an MVP fast? Rails is still a strong choice. But Next.js is much simpler.

• Want a fast AI-driven app? v0, Next.js, shadcn/ui, Tailwind, and Vercel are an unstoppable combo.

• Using Supabase for your database? Skip Rails. Use Next.js — it’s cleaner and faster.

If you’re stuck, ask yourself:

• Do I want one-click deployments?

• Do I want faster AI integrations?

• Do I want to avoid gem conflicts?

If so, Next.js is calling your name.

Rails isn’t dead.

Actually it’s one of the most on-demand framework in the workforce according to Hired.

I still use it, and I still believe in it.

P.S. If you or your team is stuck dealing with unrelated issues (to your main goal: building your app) when working with rails conflicts right now, I feel your pain.
Next.js doesn’t have that problem. Just sayin’.

What I’ve Been Up To

It’s always Saturday morning somewhere in the world — and that’s my official excuse for this late newsletter. Time zones are undefeated, and so am I (eventually).

• Tackling Usage-Based Pricing with Open Source:
  While working on subscription features for GitGlance, I spent a lot of time integrating usage based pricing. So I’m exploring how to build a simple, open-source solution to make it easier for others. If you’ve struggled with usage-based pricing, I’m working on a fix.

• Building "Filter by Popularity" for GitGlance (And Fighting Performance Issues): This week, I launched a big new feature: Filter by Popularity for GitGlance. Sounds simple, but it wasn’t. GitHub endpoint for issues and repositories are completely separate endpoints. It doesn’t let you group issues by popularity out of the box, and tracking multiple repositories made it even harder.
  I ended up rewriting the entire system using GraphQL, which meant dealing with pagination, performance, and caching headaches. But it’s live now, and this is really going to add a lot of value to users. I’m spending most of my time refining GitGlance based on feedback, so users can get value faster.

• Deep Dive into Word Vectorization and OpenAI’s Embeddable API
  I recently discovered OpenAI’s Embeddable API and got fascinated with word vectorization. Basically, it’s a way to turn words into numbers that algorithms can "understand." It’s opening up all kinds of new ideas for features and tools I might build in the future – including updating current features. Right now, I’m still exploring, but I can already see a ton of potential use cases.

GitGlance has taken up most of my week, but these side explorations are where I find new ideas for the next big thing.

Learn it to make it!

Cheers!