In 2020 me and my wife wanted to start a blog together. My wife is not very technical but I myself do know a thing or two so it was pretty clear that I would be responsible for the technical stuff for our blog.
I had been building WordPress websites around 2015 and 2016 as a freelancer so I had some experience about the content management system space.
I knew that WordPress websites can very quickly become bloated with unnecessary code when you start adding plugins and themes on top of the core WordPress engine.
I also knew that as I had been steadily improving my software development skills from my freelancing years that I could very easily build some kind of solution for our blogging needs.
Starting out by building for myself
It didn’t take too long before I made the decision to start building us a custom solution for our blog. I did some research a couple of nights and investigated how the CMS space had evolved in the few years I had not been active. It turned out that everything was pretty much the same as before.
It had been a while since I had had a side project anyways so building a very simple CMS seemed like a nice thing to pursue at the time.
Choosing the tech stack
As a software developer it is almost required for me to keep following the industry and where everything is headed. In our work place there had been a lot of hype around different cloud service providers of which I had been mostly interested in Google Cloud.
Since I already had some knowledge of Google Cloud Platform and the services around their infrastructure, it was an easy decision to integrate this side project with Google as the primary provider.
This was also a good hands-on experience to build something using Google services on my spare-time which would benefit me on my full-time job.
I decided to go all-in on Google by using Angular on front-end, Node.js on backend, Firebase for authentication, Google Cloud Storage for object storing, Firestore for NoSQL database. This would basically cover everything I would need for a simple CMS.
Setting the standards for the project
The number one reason I wanted to build a CMS myself was to be able to make sure there was very little to no code-bloat, meaning that every single line of code has it’s purpose.
By having no code-bloat, the system would most likely be as efficient as possible if built properly.
I wanted to build something that would technically generate blog posts in perfect condition for search engines.
Getting a perfect score from Google PageSpeed Insights was one of the main goals when I started building my own content management system.
Also, accessibility was very important. I wanted to build a system that would generate very minimalistic end-user experience, thus great UX.
Using TypeScript everywhere
TypeScript was something I had been using for a few years by now on my full-time projects so I had some skills in that area and had learned the benefits of using it.
Creating strongly typed code would mean to do a little bit of extra work for every functionality but in the long run it would make the codebase a lot more maintainable in my opinion.
This was important because I knew that I would be having longer breaks when I would not be working or even thinking about the project, so when I would come back, having everything strongly typed would make the process of jumping back in a lot more easier.
So far, this has been the case as I have implemented everything from the frontend side to backend side using TypeScript.
Setting the scope for the project
The scope of the project wasn’t set in stone from the get-go and it isn’t very clear even to this day (as of writing).
The basic use case was to create a simple admin panel for updating blog content as well as a simple end-user interface for blog readers to interact with.
The extended scope was to build integrations and more advanced functionalities to the system for monetisation purposes and community management.
Luckily I have been able to avoid those thoughts quite well so far and have managed to keep the scope of the project within the basic use case, which is to just write content.
Sharing online and going open source
It took about 6 months to build a very minimal (MVP) product for me and my wife to start using it and publishing articles on it.
Even if we use our self-made system, it still means we are vendor-locking ourselves to it. This is the same with pretty much all systems and is not something I was looking to try and solve.
We started using my own content management system with my wife for writing our mutual blog together after 6 months of building a MVP.
One year of blogging later
So we continued using the system for blogging in a very small niche for a year or so. I kept implementing some minor fixes here and there and adding small features as we would need them but mostly we just wanted to publish content and see how our readers would interact with the system and how it would perform in the search engines.
As we kept getting good feedback for our blog and our posts started to rank quite nice on Google Search, it seemed that the system was actually working like it should.
I was thinking about the future of the system a little bit and finally decided to open source it after getting some feedback from fellow developers, who were really interested in it.
This was also something I had been wanting to do for as long as I have been a developer, but never really had the time our courage to publish anything.
I made some minor tweaks for about a week to the system before dividing the core system from our own blog to a separate project, which would be the open sourced version.
I had built the system from the beginning in such way that it would be easy to duplicate the whole thing multiple times and build new blogs with it, which made the process of open sourcing quite simple.
There was really nothing else to it except to manually add two config files to connect the backend and the frontend to Google Firebase services.
Releasing an open source project was completely new for me but luckily I found this really great Open Source Guide from the internet that includes great tips and advice on what to consider when releasing an open source project.
Continue building in public
It only took a night or two before I got a little bit restless before going to sleep. I had made the decision to open source the system quite quickly and hadn’t really gone through the entire codebase to know if there would be too many issues etc.
I quickly realised that I had cut some corners when I had been building the backend of the system when it came to authentication. Basically I had forgotten to verify the user using Firebase JWT before accessing the Firestore database.
Luckily I didn’t have too big of a following and hadn’t tried to mage too big of a deal about the release for open sourcing but there were already a few forks and quite a couple of stars for the project.
Building and releasing my first open source project has been a great learning experience. There are lot of unknowns and I am still not 100% sure where this project might end up in the future.
Basically, anyone could have edited the data inside the database with some simple hacks and some API requests. Luckily I got that solved pretty quickly.
Putting my own neck on the line by actually using the open sourced system does put some extra pressure for sure.
There are still quite a few items on the backlog for the upcoming future and now there is a very new dimension to this side-project of mine as everyone can use it for building their own blog and can see every single line of code there is for the system.
It is definitely not perfect in it’s current form but I do believe it has a good ground to build from going forward.
While building my own content management system and learning to write a blog I have learned a lot about publishing content and SEO. I love coming up with ideas to write about and getting my thoughts out to internet with my self-made system.
Thank you for reading this article and feel free to checkout the project code from Github.
UPDATE: code not available anymore - decided to pull the project back into my own use as the fact of open sourcing didn’t fit my life after all. Too much concerns and worry over having code in public. Such a great learning experience though!