Why I Chose Next.js + Sanity for My Blog Stack

When I set out to build this blog, I wanted something that balanced developer experience with content management. I tried a few options, but none felt right until I landed on Next.js and Sanity.

Why Next.js?

Next.js felt like the obvious choice. Server Components gave me fast page loads, file-based routing meant I didn’t have to configure anything manually, and TypeScript support was built in.

The developer experience was a big win. Hot reloading worked instantly, and I could write React components I already knew. Everything just clicked.

Why Sanity?

I wanted a CMS that treated content as structured data instead of forcing it into a layout. Sanity gave me that flexibility.

Portable Text stores content as JSON instead of HTML or Markdown. That meant I could render the same post on my site—or anywhere else in the future—without extra work.

The Studio is fully customizable. I could build the editing experience exactly how I wanted it.

GROQ, Sanity’s query language, is surprisingly intuitive. Fetching a post looks like this:

*[_type == "post" && slug.current == $slug][0] {
  title,
  publishedAt,
  categories,
  body
}

It’s concise, readable, and didn’t feel like learning a whole new language from scratch.

Setting it up

Getting the project running took less than 30 minutes. Sanity’s CLI handled the configuration, and Next.js gave me a solid foundation.

I could write content in Sanity Studio and see exactly how it would render. No surprises when I published. Deployment was simple too: Sanity hosts the Studio, and Vercel hosts the Next.js app.

The Downsides

No stack is perfect. Portable Text has a learning curve, and GROQ is another query language to understand.

Customizing the Studio beyond the default requires writing some code. I could manage content easily in Sanity Studio, but adjusting layouts or tweaking the schema still meant diving into code. For my personal blog, this was fine, but it’s something to keep in mind if you expect a completely plug-and-play setup.

How I made it work for my blog

Instead of trying to make the CMS dynamic for every request, I treated most content as static. I fetch posts during build time and generate pages ahead of deployment. That way, the blog loads instantly for every visitor, and there’s no runtime dependency slowing things down.

From there, each page just reads the data fetched at build time. Updates happen whenever I add a new post, and I use a webhook from Sanity to automatically trigger a rebuild on Vercel. That means I don’t have to manually redeploy every time I publish a new post—my site updates itself while staying completely static for visitors.

For a blog that doesn’t change constantly, this setup removes unnecessary runtime calls and keeps everything fast, reliable, and predictable.

Next.js and Sanity gave me the perfect balance of developer experience and content management. I get to write clean React components, manage content efficiently, and deploy a blog that’s fast and reliable—all without unnecessary complexity.

For anyone building a blog that doesn’t change constantly, this stack is simple, maintainable, and surprisingly enjoyable to work with.