Headless CMSs are excellent choices for building various types of websites, including homepages, e-commerce sites, and blogs.

Using a headless CMS offers many advantages to developers. Here are three primary reasons, in my opinion:

1. Easily build a custom frontend without worrying about the backend via APIs.

2. Deploy sites on any cloud platform and on any domain, including a company’s sub-domain like /blog.

3. Create custom-built components whenever needed.

In this article, let’s explore the current blogging solutions ecosystem, examine present headless CMSs along with their advantages and disadvantages, and finally understand Headless Hashnode and why we built it.

SaaS for blogs and their issues

From 2015 to 2020, Medium was a popular choice for many teams and companies. It provided an easy interface for companies to onboard and publish without the worry of building a blog from scratch. Medium also offered custom domain mapping, so companies readily mapped blog.company.com or similar sub-domains to Medium.

It addressed some core problems:

• Blogging on custom domain easily.

• A decent editor for composing articles.

• A collaboration workflow among team members.

• Decent traction from Medium’s reader network, although not every company benefited from this.

It became very common for websites to link the “blog” menu item on their navbar to Medium.

These days, however, I rarely come across any product companies officially running their blogs on Medium. Companies with large development teams tend to opt for an open-source blogging solution or develop their blogs in-house. Moving away from Medium was a no-brainer for dev tools companies, or companies that sell to dev ecosystem.

So, what went wrong?

1. Every product blog started looking the same. There were very limited customization options on Medium, except for changing the logo, the primary color of the blog, and a drag-and-drop UI builder which allowed companies to move sections around.

2. The design and UX of the main websites for many companies didn’t match the design and UX of the blogs. It felt as though users were landing in a different universe. It was challenging for brands to maintain this user flow.

3. Medium’s controversial design decisions, which prevented readers from returning to the main website, posed a significant problem. Businesses found it difficult to convert blog readers into potential leads. Even today, Medium doesn’t display the blog’s primary logo on the top bar; it encourages readers to sign up on Medium rather than on the product hosting the blog.

   

4. Companies soon required custom features and components as they grew, and Medium suddenly resembled a walled garden.

5. Last but not least, the infamous paywall. Medium transitioned to a paywall-based system, offering readers five free articles to read each month. Later, it provided publications the option to opt out of the system, but free publications began seeing a large, dismissible sign-up popup on Medium.

The situation with developer blogs was even more problematic, which ultimately motivated my co-founder and me to build Hashnode. That’s a story for a different article. :D

However, here are a few limitations that developer blogs faced on Medium:

1. The Medium editor lacked support for inserting code blocks. To insert code, authors had to create a GitHub Gist and embed it into the article, which was a hassle.

   

2. Developers love writing in Markdown, a universally loved writing syntax for devs. Medium’s editor lacked native Markdown support.

3. Medium has made it quite difficult to export and sync content with third-party platforms like GitHub. Developers wanted to sync articles on their blog from GitHub repositories, allowing companies to repurpose content in various ways. However, unfortunately, Medium did not support that.

There are other SaaS platforms for running blogs and newsletters today, similar to Medium, such as Substack, Beehiiv, and WordPress.com, among others. However, these platforms are mainly popular among independent bloggers, and are rarely used by businesses and teams for their products. Some of the limitations mentioned above are also true for these platforms.

Most teams settle for a headless CMS!

Companies are more focused on building their core products and solving real problems. None of them have the time and resources to reinvent the wheel and build a blog engine from scratch.

Just like any product, a blog engine has two sides: a frontend client and a backend. While the frontend is easy to build using frontend technologies like Next.js and TailwindCSS, or by cloning any open-source blog frontend, the backend requires 90% of the time. Building a backend for a blog from scratch is like creating a whole new product. You need to build APIs to