Building My Blog: My Approach to Tools and Frameworks
Making Decisions as a Software Engineer
In the great big year 2025, the sheer number of technologies, frameworks, and tools available to developers can feel overwhelming. With so many choices, making decisions that will have long-term impacts on your projects can be difficult. I get it. You weigh the pros and cons of every library and package, ensuring they work together as seamlessly as possible...or at least trying to.
I had many websites in the past with many different technologies used, and nothing really stuck around. My first website was a simple portfolio site for my photography built with php, jQuery, grunt and scss, it was a mess on the code side; I was young and in college and learning the ropes. Nowadays, I try to keep my codebase as simple as possible so I can focus on the feature I am building and not the technology that got me there.
In this post, I’ll share my journey in building this blog, detailing the choices I made and the reasoning behind them.
1. What am I building?
This one’s simple: I’m building a blog. I wanted a space I could own, where I could talk about things that interest me. Importantly, I didn’t want to rely on third-party services because I value independence and cost-efficiency. Freemium models are generally not my thing (looking at you, Vercel, you’re an exception), as they often mean my data is being monetized somewhere down the line.
2. What is needed to make that work?
To bring this blog to life, I needed two core components:
- A Content Management System (CMS): To manage and organize my posts.
- A Frontend Application: To deliver the content and create an engaging user experience.
3. What technologies are available to me
For the CMS I had several options that I knew about:
Contentful
Contentful is a great application, it's a headless CMS hosted in the cloud that has a freemium model with a immense rate limit on their free tier. The downsides? They limit how many content models you can have which means you are limited in how you breakdown content on your site. Also, their plugin store is mostly filled with paid plugins, which is a non-starter. As you scale your site, you'll be limited in how you structure, and how you customize your CMS experience. But they have great documentation and they support graphql, if that's your cup of tea.
Directus
Directus is a direct competitor to Contentful, it also is hosted in the cloud, but they also have a self-hosted option which is what originally caught my eye. With Directus, you can do everything you can do with Contentful, but aren't rate limited, you can have as many data models as you want, and because this project is open-sourced, their extensive extension marketplace is filled with countless free extensions to customize your experience.
Wordpress
Hahaha, that's a joke, I'd never. Neither should you.
Ghost
I honestly don't know much about this platform, I know it's open-source, and is very similar to Directus, I just didnt do extensive research into it, it's probably fine.
As for a frontend there's also a ton of options, I'm a React girly so:
Astro
I'll learn it eventually, there's literally nothing wrong with Astro, it's a blazing fast well rounded react framework that brings a lot of innovation into the space, I just don't feel like dealing with the learning curve for the start of my blog.
Nextjs
An industry standard react framework, heavily funded and supported by Vercel with an amazing freemium model for hosting. Plus it has built in analytics and speed insights, so for now, for the cost of free, I can't really see a reason to not chose this.
Remix
I have been meaning to build an application with this framework, but honestly, ever since reading the news that react-router was reintegrating remix, I have very little desire to build something with an "out of favor" tech stack.
@Tanstack/Start
I love everything this developer does, the way they think about problems and how to solve them, is so clever and I always love the developer experiences they whip up. But again, learning curve can make this package wait a while. I'll eventually do a comparison down the road on using this vs my current implementation.
Vite + React
Vite is such a great bundler, and I am very grateful that this exists. Webpack who? I don't know her. But in all seriousness, I didn't want to wrestle with server side rendering with vite and there are plenty of options other than it that have SSR/SSG built in and stable.
Decisions and Justifications
For the CMS, I chose Directus with SQLite. Its self-hosting versatility, customization options, and open-source nature made it a perfect fit. Plus, if I ever need something that doesn’t already exist, I can contribute directly to the project.
For the frontend, Next.js paired with Vercel was an obvious choice. Its ease of setup, excellent developer experience, and built-in optimization features saved me a ton of time.
Other Considerations
There were a few additional decisions to make:
- Monorepo Setup: I used Turborepo to manage the CMS and frontend applications concurrently. This setup allows me to add more projects in the future while maintaining a cohesive development workflow.
- Workflow Automation: GitHub Actions fit perfectly for automating deployments and tests within my existing Git workflow.
- Local SSL Development: To make local development cleaner and more secure, I used Caddy to set up HTTPS with custom domains like https://ty.lerscott.local. It’s much easier on the eyes than http://localhost:3000.
- API Layer: I added an Express server for handling webhooks and future integrations. Thanks to the monorepo, incorporating this took just an hour or so.
Conclusion
Building this blog was both a practical and rewarding experience. The hardest part wasn’t the implementation but deciding on the architecture. For any developer, regardless of experience level, this is a hurdle you’ll encounter in every project. The tools and frameworks you choose shape not only the project’s functionality but also its maintainability and scalability.
What I’ve learned is that there’s no universal “right answer” when choosing technologies. The best tools are the ones that fit your needs, align with your goals, and excite you to build. This blog reflects my preferences and passions, and I hope it serves as a reminder to other developers: Build things that matter to you. Experiment with tools that spark your curiosity. The joy of development isn’t just in the finished product, it’s in the journey of creating something uniquely your own.
Let me know if you’d like more details about the tools and frameworks I used, or if you’d like to share how you’ve approached similar projects. I’d love to hear your stories!