Introduction:

I finally did the thing every developer eventually does: I built my own blog.

But I didn't just "install" a blog. I built an engine. Most people today pick a platform that works like a pre-furnished apartment - you move in, but you can’t move the walls. I wanted a workshop where I own the foundation, the wiring, and the blueprint.

This blog is built from scratch - Svelte 5 on the frontend, Rust on the backend. This post kicks off a devlog series documenting how I’m designing, building, and inevitably refactoring a platform I own end-to-end.

Why Build a Blog in 2025?

There are already many excellent ways to publish online. So why make another?

For me, this blog is a playground without constraints. Off-the-shelf tools often limit experimentation: if you want a custom layout, a unique interaction, or an unusual post format, you end up fighting the platform instead of building the feature.

By owning the stack, I can treat a blog post as a living application. For example, I can integrate this interactive flower natively 😄:

This is not embed. I built a custom Markdown engine. It allows me to attach any custom directives to hydrate Svelte 5 components directly from my post content.

This project is also about ownership. I wanted a long-term platform where I understand the “why” behind every design choice, rather than just shipping features and moving on.

3. The SaaS-Level Architecture

This isn't just a static site. It's a custom-built, multi-level content pipeline designed for both the writer and the reader.

I built a dedicated dashboard to handle the "boring" parts of blogging. When I save a post, the Rust server processes the content and media as a series of connected links and aliases. It treats the data as "raw material" and a dictionary of assets rather than just hardcoded paths.

That raw material is then fed to the SvelteKit server, which parses the logic and hydrates it into functional Svelte components before feeding the final result to the client. This decoupling gives me a professional-grade workflow where the content is "pure" and the delivery is incredibly flexible.

By ‘SaaS-level’, I mean the architecture and workflow - not a commercial SaaS product.

What this series is about

This devlog isn’t a step-by-step tutorial. Instead, it’s a behind-the-scenes look at the engineering problems I’m solving. Future topics will include:

• VPS & Environment Setup: Provisioning the server, hardening access, and preparing the baseline environment to host the application stack.
• System Design: Structuring a multi-language stack.
• Content Engine: Deep dives into the SSR parser and media-mapping logic.
• The Dashboard: A look at the custom-built CMS and state management.
• Infrastructure: Anything else that comes up, e.g., performance, deployment, testing, or unexpected bugs.
• ...

The goal is to share the "how" and the "why" behind every design choice. I'm finally building in a space where the only constraint is my own imagination.

More soon.