I’ve finally launched my own blog system and this is the very first post published using it. 🎉

Before this, I was using Hashnode to write and publish articles. It’s a great platform and I’m keeping my previous articles hosted there, but I wanted more control over how things work especially around content management, layout, and eventually SEO.

So I built my own CRUD system and connected it directly to my site.

Why build my own system?

Honestly, part of it is just me being a developer who likes to tinker. But also:

• I wanted full control over the content structure and layout

• I needed flexibility to try things out (like experimenting with MDX, metadata, and dynamic rendering)

• I wanted a better workflow that doesn’t require updating post numbers manually or relying on third-party rebuilds

What's different now?

This new setup lets me create, read, update, and delete posts from a custom dashboard I built. It’s still basic no fancy editor yet but it works.

The moments of doubt (and stupidity)

There were those moments. You know, the ones where you're staring at the screen asking yourself:
"Wait… am I even a real developer?"

Pages weren’t updating, changes weren’t showing, and for a solid 10 minutes I was about to rewrite entire chunks of code.
Then I remembered:

“Ah, right. Might’ve been a cache issue... or it’s still propagating.”

A classic.

500 Internal Server Errors & Unexpected Gratitude

Nothing humbles you faster than a big red 500 Internal Server Error, especially in production, where everything seemed perfectly fine in local.

It was working on my machine™️. But once deployed, the server threw 500s left and right.

After a long debugging session, it boiled down to a handful of small but critical oversights:

• A missing or misnamed environment variable (process.env.SOMETHING was undefined)

• TypeScript errors that didn’t surface locally due to relaxed settings

• Functions relying on browser-only APIs running in server context

• Differences in Node vs browser execution (hello, window is not defined)

Each one was a reminder that just because something renders fine locally doesn’t mean it’ll survive a production build.

But these headaches gave me a deeper appreciation for backend and DevOps teammates who handle this complexity every day. It’s easy to miss the invisible work they do - until you’re neck-deep in logs and wondering why your async function broke your app.

Doing what DevOps usually does

Setting up the environment configs was another level of fun (read: pain). I’m used to having someone else handle this side of things, so manually setting up .env, deployment environments, and S3 permissions was a crash course in patience.

But as someone who wants to grow into fullstack development, it felt like a rite of passage.

But as someone who wants to grow into fullstack development, it felt like a rite of passage.

On top of that, understanding why Cloudflare was blocking eval() added another layer of debugging. I had to switch to using REST APIs instead still not sure if that part belongs more to the backend or frontend, but it worked.

Old posts are still being fetched from Hashnode, and new ones like this are fully handled by my custom system. Both systems live side-by-side for now.

If you're reading this, congrats, you just witnessed a new publishing pipeline go live (with minimal chaos).

More breakdowns and probably more bugs coming soon.