When I first decided to write about engineering management, my initial instinct was the obvious one:
publish on Medium or LinkedIn and move on.

They’re easy. They’re familiar. They remove friction.

But something about that approach didn’t feel quite right for me.

As an engineering manager with a software engineering background, I didn’t just want a place to write. I wanted ownership, control, and—if I’m being honest—a way to stay technically sharp without stepping on my team’s toes.

This blog post is the story of why I built my own platform, how it evolved over time, and where it fits in the broader themes I write about here: engineering leadership, system design, and the changing role of engineering managers.

It also complements another article where I explore whether engineering managers should write production code. This one focuses on a related question:

What do you do when you miss coding—but your role has changed?

---

The Original Goal: Write, Reflect, and Build a Personal Brand

At the start, the goal was simple:

• Write thoughtful content about engineering management
• Build a long-term personal brand
• Have a single place that represents my thinking, background, and experience

The site wasn’t just about blog posts. It also included a profile section, my resume, and context for people who might want to collaborate or work with me in the future.

From a technical perspective, I expected this to be very simple:

• A small React app
• Static blog pages
• Deployed to basic static hosting
• No backend, no database, no moving parts

That would have been more than enough.

But then two things happened.

---

Why I Didn’t Stop at a Static Site

First, I realized I wanted more control than third-party platforms allow.
Second, I realized I genuinely missed building software.

As engineering managers, our impact increases—but our hands-on time often decreases. I didn’t want to measure relevance by lines of code, but I also didn’t want to slowly lose touch with how systems are actually built.

This project felt like a healthy middle ground:

• Not production code for my team
• Not critical path work
• But still real architecture, real tradeoffs, real systems

So instead of stopping at “just a static blog,” I leaned into building something more intentional.

---

Choosing Netlify: Simple, Free, and Practical

One early constraint I set was cost.
I wanted this project to be:

• As close to free as possible
• Easy to operate
• Low-maintenance

That led me to Netlify:

• Free static hosting
• Simple deployments
• Built-in features that avoided early backend complexity

At this point, everything was still static. Blog posts were rendered as pages, and life was good.

Until I added one small thing.

---

The First Crack in “Static”: Contact Forms

The moment I added a Contact Me / Help section, the site stopped being truly static.

Rather than building a backend immediately, I used Netlify Forms, which allowed:

• A frontend-only form
• Automatic submission handling
• No server code

This became a recurring theme in the project:

Use managed solutions until they stop making sense.

---

The Newsletter Problem (and Why Static Wasn’t Enough)

Eventually, I wanted to start a newsletter.

That introduced real requirements:

• Email capture
• Storage
• Validation
• Abuse prevention
• Email delivery

At that point, pretending this was still a static site wasn’t realistic.

Since I was already on Netlify, I introduced serverless functions, initially written in Go, to handle email subscriptions and basic logic.

Once logic entered the picture, data followed.

---

Introducing a Database (Without Paying for One)

I needed a relational database that:

• Had a generous free tier
• Was production-grade
• Didn’t lock me into proprietary abstractions

That led me to Supabase.

Supabase became the foundation for:

• Newsletter subscribers
• Confirmation state
• Blog metadata
• Future extensibility

It gave me PostgreSQL, APIs, and flexibility without operational overhead.

---

Sending Emails (and Preventing Spam)

To send emails, I integrated Resend, which offers a solid free tier and clean APIs.

But capturing emails alone isn’t enough.
Without verification, spam quickly becomes your problem.

So I added email confirmation:

• Generate a confirmation token
• Send a verification email
• Activate subscriptions only after confirmation

It was a small feature, but an important one. Bad data compounds fast.

---

Branding Matters: Buying a Custom Domain

Once the system was functional, I didn’t want a .netlify.app URL attached to it.

I:

• Purchased a domain via Namecheap
• Configured DNS to point to Netlify
• Removed platform branding

That small step made the project feel real. This stopped being an experiment and started feeling like a product.

---

Markdown as the Source of Truth

From day one, I chose Markdown as the format for blog posts.

Why?

• Portable
• Versionable
• Tool-agnostic
• Easy to reason about

Blog content lives in Markdown files, while code dynamically turns those files into pages. Initially, this rendering happened at runtime.

Which worked… until SEO entered the picture.

---

SEO, Social Sharing, and the Framework Migration

Dynamic rendering caused two problems:

1. Weak SEO
2. Broken previews on LinkedIn and Twitter

Many crawlers don’t execute JavaScript reliably. They expect pre-rendered HTML.

Create React App started working against me.

So I made a hard decision:

• Migrate everything to Next.js

This unlocked:

• Static Site Generation (SSG)
• Better SEO
• Proper Open Graph previews
• Full-stack development in one framework

The cost was real:

• Porting the frontend
• Rewriting serverless functions in Node.js/TypeScript
• Rethinking data flow

Had I known this earlier, I would’ve started with Next.js.
But migrations are lessons, not mistakes.

---

Reducing Operational Overhead: An Admin Panel

As the platform grew, manual workflows started to hurt.

So I added an admin panel:

• Visible only when I log in as an admin
• Create draft ideas
• Control publish timing
• Manage blog state without redeploying

This single feature drastically reduced operational burden and made writing feel lighter again.

---

Members, Authentication, and the Future Platform

Before even introducing monetization, I added social authentication:

• Users can create accounts
• Logged-in members can save posts
• Certain filters and content are member-only

This sets the stage for what comes next.

Over time, I plan to introduce curated learning paths, including:

• End-to-end system design
• Building highly effective engineering teams
• Transitioning into engineering management

These will live behind membership and evolve as the platform grows.

---

Designing for the Long Term: Authors, Tools, and Monetization

Even though I’m the only writer today, the platform is designed for more:

• Multiple authors can contribute in the future
• A dedicated Tools section already exists
• Others could eventually build and publish tools here

Monetization is intentionally deferred.
If—and only if—there’s real value and interest, I’ll introduce it later.

The goal isn’t revenue first.
It’s usefulness first.

---

Why Coding Still Matters to Me (Even as a Manager)

One personal motivation behind all of this is simple:

As managers, it’s easy to push for tighter deadlines.
It’s harder to do that responsibly if you’ve lost touch with the effort required to ship.

By actively building—even outside my team’s production code—I:

• Stay grounded in real development work
• Better understand estimations and tradeoffs
• Build more empathy for engineers shipping features

This isn’t about control.
It’s about context.

---

An Important Clarification: This Is Not Mandatory

None of this is a requirement for engineering managers.

There are many effective management styles.

For example:

• Someone from a product background might gain an edge by deeply understanding the platform, features, and user impact.
• Someone from program management might excel by creating reliable roadmaps and realistic delivery timelines.

Coding is just one way to stay close to the work—especially for those coming from a software engineering background.

Engineering management is about leverage, not uniformity.

---

Where This Fits in the Bigger Picture

This platform—and this post—connect directly to two broader themes on this blog:

1. Whether engineering managers should write production code
2. What to do when you miss coding but want to lead well

This project is my answer to the second question.

And it’s only the beginning.

---

Final Thoughts

This blog isn’t just a place to publish ideas.
It’s a system that supports how I think, learn, and grow as an engineering leader.

If you’re an engineering manager who:

• Misses building
• Wants to stay technical without harming team leverage
• Or is figuring out your own leadership edge

You’re not alone.

---

I’d Love Your Perspective

• How do you stay connected to the work?
• What’s your edge as an engineering manager?
• Have you built side projects to stay sharp?

Let me know. This blog is as much about conversation as it is about content.