How I Built a Tech Blog with Next.js 16 and Why Learning in Public Works

How I Built My Own Tech Blog and Why Learning in Public Changed the Way I Learn

I came to this realization after rereading the same Twitter thread for the third time, saving the same article to Notion, and still forgetting half of it within two weeks.

The problem wasn't that I wasn't learning.

The problem was that nothing stayed with me.

Over the years, I've consumed hundreds of articles, tutorials, and videos about software development. Yet the same thing kept happening: I would read something interesting, understand it in the moment, and then realize a few weeks later that most of it had disappeared from memory.

That's when I discovered a simple principle that completely changed my perspective on learning.

Learning in Public: The Idea That Changed Everything

The first time I encountered the concept of Learning in Public was through Swyx, a developer I've been following for several years.

The idea is surprisingly simple: publish what you learn.

You don't wait until you're an expert. You don't wait until you have a unique perspective. You don't wait until you're "ready."

You simply write about what you've discovered and the process that led you there.

At first, the idea felt somewhat naive.

Why would anyone read an article written by me when official documentation exists, courses have tens of thousands of students, and tutorials are created by people with far more experience?

Over time, I found the answer.

Voice matters more than authority.

Sometimes it's more useful to read an explanation from someone who has just solved a problem than to go through perfect but impersonal documentation. More importantly, the act of explaining something to others forces you to understand it at a much deeper level.

You cannot explain something well if you haven't truly understood it yourself.

Why I Decided to Build a Blog

Instead of simply starting a blog, I decided to build one from scratch.

I wanted the blog to be a technical project, not just a place to publish articles.

In a way, it was already Learning in Public in practice: building a development blog using technologies that I would later write about.

Beyond the educational aspect, the project gave me an opportunity to explore modern technologies, experiment with architecture, and document the entire process.

Choosing the Tech Stack

The first questions were practical:

• Where should the articles live?
• How should publishing work?
• How should the site perform on mobile devices?
• How will Google index the content?
• How should multiple languages be handled?

Next.js 16 and the App Router

I chose Next.js 16 as the foundation of the project.

It's not an unusual choice, but today it remains one of the most mature frameworks for production React applications.

One of the most significant changes in recent versions is that Server Components are now the default.

This means that components without interactivity run on the server and deliver fully rendered HTML to the browser.

For a blog, the advantages are obvious:

• Faster page loads
• Better SEO
• Less JavaScript shipped to the client
• Simpler application architecture

Articles are statically generated, while SEO metadata is dynamically created for each page using the framework's built-in APIs.

Tailwind CSS 4

One of the biggest surprises was Tailwind CSS 4.

The new version significantly changes the configuration experience. The traditional tailwind.config.js file is gone, and themes are defined directly in CSS through the @theme directive.

This approach turns design tokens into native CSS variables and makes theming, including dark mode, significantly cleaner.

Along the way, I learned an important lesson.

In Tailwind v4, utility classes live inside @layer utilities. Any custom CSS written outside of a layer may receive higher priority and override Tailwind utilities completely.

It's one of those details you usually discover after spending a few hours debugging.

Sanity v3 as a Headless CMS

The hardest decision was choosing a content management system.

The simplest option was storing articles as Markdown files inside the repository.

It works. It's free. It's easy to understand.

But limitations appear quickly:

• Every article requires a commit
• Mobile editing becomes inconvenient
• Image management is limited
• Collaboration is difficult

That's why I chose Sanity v3.

Its visual Studio runs directly inside the application, content can be queried with GROQ, and images are delivered through a CDN with automatic optimization and on-demand transformations.

For a modern blog, the experience is dramatically better.

Internationalization with next-intl

The blog is available in three languages:

• Romanian
• English
• Russian

This wasn't a vanity decision.

Many developers in Eastern Europe and former Soviet countries consume content in all three languages, and multilingual support allows the blog to reach a broader audience.

Using next-intl, each language gets its own URL structure and translation files, while users receive a seamless experience.

Why I Chose Feature-Sliced Design

Architecture was probably the topic I spent the most time thinking about before writing a single line of code.

I chose Feature-Sliced Design (FSD).

FSD organizes applications into layers with clear responsibilities.

Shared

Contains reusable utilities and UI components with no business logic.

Entities

Contains the core data models:

• Post
• Author
• Category

This layer also includes TypeScript types and data queries.

Features

Contains interactive functionality such as:

• Contact forms
• Language switching
• Dark mode
• User interactions

Widgets

Contains larger UI blocks composed from entities and features:

• Navbar
• Footer
• Article grids
• Complex page sections

Why Architecture Matters Even in Personal Projects

When you're working alone, there is no code review.

There's nobody to tell you that business logic belongs somewhere else or that you've created a circular dependency.

In those situations, architecture becomes a form of discipline.

Layer boundaries make mistakes obvious and help prevent code quality from deteriorating as the project grows.

If I later add:

• A newsletter
• A projects section
• Comments
• Additional content types

every new feature already has a clear place in the structure.

What's Next

Immediately after publishing this article, the next steps are:

• Deploying to Vercel
• Configuring the domain
• Verifying metadata across all languages

In the short term, I plan to add:

• Automatically generated sitemaps
• JSON-LD structured data
• Proper hreflang support
• Additional SEO improvements

These are relatively small implementations, but they can have a significant impact on discoverability.

Content Is Still the Most Important Part

No matter how well a blog is built, without content it has little value.

Architecture, frameworks, and SEO optimizations are just infrastructure.

The real challenge begins with publishing consistently.

My goal isn't to build a perfect blog.

My goal is to build a blog that grows alongside me.

Every article is proof that I've understood something well enough to explain it to someone else.

And sometimes, while writing, you discover that you didn't understand it quite as well as you thought.

Ironically, those moments are often the most valuable.

Because that's when real learning begins.