Why we built our own CMS
3 min read

Why we built our own CMS

Fulfilling every developer's lifelong dream: building our own CMS.

Earlier this year, the company I work for kicked off a new project. We've been providing marketing websites to our clients for a number of years and the platform needed to be updated. We had some ideas about where we were and where we'd like to go, but there were absolutely no constraints on how we could get there.

The Goal(s)

1. Who: We have a web production team that produces, deploys, and maintains hundreds of sites. For the most part, our clients don't want to (and shouldn't) manage their content on a day-to-day basis. Our primary audience is our own team.

2. What: The sites we produce are fairly simple and straightforward. Generally, sites are less than 15 pages and consist of text and graphics. We don't need to accommodate site-specific interactions with heavy Javascript or UX fanciness. While we have some pre-existing ideas of presentation, we wanted to shift to a highly structured, content-first approach (function over form).

3. When: Our development cycles revolve around our clients. We kicked the project off in early July with a goal of internal use within 6 months and production use within 9 months. We're launching to production when our clients will be ready and available to take advantage of the new product.

4. Why: The previous system served us well for more than 5 years. It handled the load of our client sites and allowed our production team to accomplish their goals. There were some pain points around content management that crept up as needs had grown and changed. We were also struggling with hosting and managing servers for all of the sites. We wanted to move to a more static approach and create something that could be a bit more flexible moving forward.

The Options

We looked at a number of options to leverage existing platforms. Our technology stack (and expertise) is PHP + Vue - but we were open to what would work best.

Self-managed

We looked at off-the-shelf products like Craft and Statamic as well as OSS solutions like Netlify CMS (or anything from this list). Our biggest challenge with most solutions is that they aren't built for multi-site.

While multi-site is a strong feature of Craft, the content between each site is unique enough that Craft's multi-site isn't ideal. I didn't look into limits - but assumed the author experience of managing 500 sites in one Craft installation would be rough.

The challenge with Statamic is that we didn't want to maintain individual instances. We needed to start developing and I wasn't sure how Statamic V3 would tie into Laravel and what we could do. Jack McDade was kind enough to answer some questions and verified that multi-site in Statamic was possible - but maybe not the best fit for what we were trying to do.

Finally, a lot of OSS solutions look great. However, many of the them are based on React (requiring an initial learning curve) or were meant to manage one set of content. While we could probably figure out how to manage multiples sites and learn React, we didn't have the appetite to tackle these two challenges.

Hosted

We also explored the growing landscape for hosted, headless CMS options. Since we wanted to move to highly-structured content, perhaps something like Sanity could work for us? In the end, the cost of a hosted solution was too cost-prohibitive.

For example, Sanity has pricing based on Datasets. After 10 Datasets, we'd already be in the "Custom" pricing option. Some back-of-the-napkin math: $20 x 500 = $10k/month. We could pass-through the $20/dataset price to our clients - or we could just keep that for ourselves.

Something like StoryBlok fits into our vision and experience. But again, the "Enterprise" pricing tier is more than what we were willing to pay to be locked into 1 platform.

Conclusion

For these reasons, we decided to move forward with building our own, in-house solution.

  1. The need to manage hundreds of sites (and not hundreds of CMS instances)
  2. The costs of hosted solutions (or per-site licensing)
  3. The desire to create and maintain our own content model

A custom CMS that would leverage our expertise, stack, and vision for where we are going as a company.