I spend most of my days thinking about OSI layers, VLAN segmentation, and whether a particular switch can handle the route table size I'm about to throw at it. Web development is a different world — but it turned out to have more in common with networking than I expected.

Why build this?

A few reasons. I wanted somewhere to document what I'm learning — both networking concepts and the web stuff I'm picking up. I also wanted to build something real, not just follow tutorials.

And honestly: if I'm going to work in tech, I should be able to ship a website.

The stack

I went with Next.js 16 and Tailwind CSS v4. Next.js because the App Router model — where components are server-rendered by default and you opt into client-side interactivity — maps reasonably well to how I think about network architecture. You design for the default case, then add complexity only where it's needed.

Tailwind because I wanted to style things without leaving the component file. The utility-first approach is verbose at first, but it's explicit — similar to writing out explicit interface configurations rather than relying on defaults.

What tripped me up

Server vs client components. In Next.js 16, components are server-rendered unless you add 'use client' at the top. I kept reaching for useState in places that didn't need it, then having to add the directive, then wondering why the bundle was larger than expected. The mental model shift is: can this component work without a browser? If yes, leave it as a server component.

The params are a Promise. In Next.js 16, route params are no longer passed as a plain object — they're wrapped in a Promise. You have to await params before accessing the slug. Caught me off guard the first time.

Tailwind v4 has no config file. In v3 you'd have a tailwind.config.js where you'd extend the theme. In v4, you do it in your CSS file using @theme. This is actually cleaner once you get used to it.

The networking parallels

Working on this reinforced a pattern I keep seeing: good systems design — whether it's a network or a web app — is about clear boundaries and explicit flow of data.

In networking: traffic flows according to routing tables and ACLs. You know where a packet enters, where it exits, and why.

In a Next.js App Router app: data flows from server components down to client components. Props move in one direction. State lives at the edges.

Same principle, different medium.

What's next for the site

• A proper projects section with writeups on network labs and automation tools
• Better code syntax highlighting in blog posts
• Maybe a dark/light toggle (though I suspect most people visiting a network engineer's site are already on dark mode)

The source code is on GitHub if you want to dig into how it's built.