A CMS Case Study: How Our Implementation Allowed Us to Scale for Students

The tech industry is saturated with acronyms that are thrown around colloquially on a day-to-day basis. One acronym that I’ve found to be less commonplace in an engineering org happens to be one of my favorites: CMS.

CMS stands for Content Management System, which, at its most basic level, is software that helps you manage your content, whether it’s text, images or more. It’s one of my favorite acronyms because it allowed me and my engineering counterpart to automate ourselves out of the problem we used to work on every single day. We were able to do so because a CMS allows non-developers to make changes to web or mobile applications in an easy, streamlined fashion — no code deploys necessary. We’ll talk more about our CMS case study soon and the immediate return we saw in productivity and scalability.

When we talk about Content Management Systems, it’s important to note that there are two different types that solve very different business cases:

A visual representation of a Traditional CMS, tightly binding the frontend to the backend, vs. a Headless CMS, delivering content to several frontend applications via API. Image owned by Contentful.

1. Traditional CMS: Your WordPress / Squarespaces of the world. In a traditional CMS, everything comes in one package. Your frontend is tightly bound to your backend. Customization is more difficult, but scaling a website quickly without technical resources is much easier if you’re willing to play in existing templates and sacrifice custom functionalities. A traditional CMS is perfect for a project where developer resources may be harder to find, and organizations can benefit from SEO and security plugins that help them get a website off the ground quickly.
2. Headless CMS: An API-based CMS that delivers your content to be consumed as needed by your frontend. A headless CMS is perfect for a project that aims to streamline content management in an existing application without sacrificing customization or flexibility. Since it’s completely detached from your frontend experience and delivered via API, plugging an existing application into a headless CMS can be an extremely fast solution to optimize productivity.

Why We Invested in a CMS: A Case Study

At Guild Education, we have a mission to unlock opportunity for America’s workforce through education. With 88 million working adults in need of higher education or upskilling in order to compete in the future of work, being able to scale our business to meet the needs of these students is a top priority.

When I joined the Guild Engineering team a year ago, we were managing a collection of landing pages, each used by one of our employer partners to teach employees about their education benefit.

An image of the landing page hosted for Taco Bell employees.

These pages weren’t doing anything fancy from a technical standpoint (consider them basic HTML marketing pages), but our process for managing them was highly manual. Every time a partner requested an update to these pages, the request had to be fielded by our marketing team, funneled to our product manager who gathered requirements and scoped the task, estimated by engineers, assigned to a sprint, coded, tested, approved, and finally deployed. All for a text change. Working its way through this process could take anywhere from a few days to a week, which wasn’t something we considered an acceptable turnaround.

A diagram of the process to make a text change, from partner request to completion. Don’t worry about what the bubbles say, just know that each bubble is a step in this arduous process.

There was definitely a time in our business this process made sense, but as a company focused on scaling to support as many students going back to school as possible, it was clear that we needed to streamline this flow and free up development resources from making such minimal changes.

Enter the CMS. We wanted our solution to plug directly into an existing Ruby on Rails application, which had a hand-rolled coupling between our backend and our frontend. Knowing that we could easily break these apart and utilize our existing frontend functionality, we quickly prioritized a headless CMS that would work with our existing infrastructure. Some of our top priorities were:

1. Compatibility

• It had to support a variety of frameworks. Our landing pages were in Rails, but our business supports many different types of applications. We wanted to be able to adopt this across multiple teams once we had a proven concept.
• It had to coexist with our analytics and A/B testing implementations

2. Flexibility, flexibility, flexibility.

• We needed the ability to model our content on demand and be able to adjust easily as business requirements changed
• The CMS had to support a variety of layouts and templates as needed by our partners
• We wanted to release the implementation in a tiered process to create incremental change immediately, instead of having to front-load all of the feature work

3. Scalability

• We wanted this decision to support our business through a phase of rapid growth. We didn’t want to have to go back to the drawing board in 6–12 months if the CMS we chose could only support us to a certain point
• We had to be able to re-use our content in multiple places. If the same module is present for every partner, we wanted to be able to create that content once, and edit it once when it changed.
• We had to be able to launch a new partner in 1 day or less

4. Usability

• Our solution needed to be usable by non-developer teammates without an extensive amount of training.

After thoroughly vetting a large variety of CMS providers, which included spinning up applications in the different interfaces, running through countless demos, and wading through a wide variety of sales pitches, we landed on Contentful. We loved the strong developer documentation, the ease of re-using content across pages and platforms, and the ability to create robust roles and permissions so we could hand off content updates to a non-developer team.

Our initial implementation took 2 weeks to get up and running. After integrating Contentful in our codebase, we increased our new partner launch velocity from ~2 weeks to ~2 hours. Additionally, small content changes could be made in less than 5 minutes, as opposed to the 1–2 week process bottleneck that those changes experienced previously.

A diagram of the process to make a text change with our new CMS, from beginning to end. Far fewer bubbles than the version above!

In the months since that initial launch, we continued to expand upon our feature set. We created all of the fail-safes needed to off-board this product from the engineering team (read: we figured out how to break it a million times and fixed it a million more). We implemented multiple automation features so that all of the necessary pieces could be in place in our ecosystem without tapping into engineering resources at all. A partner could officially launch without a single engineering ticket or a single code deploy.

A peek into the Contentful UI.

You may be asking, what do we do with all of our free time now? We’re onto the next project to work toward the goal of unlocking opportunity for America’s workforce through education!

So what can this mean for you if you’re considering a CMS for your company or team? If you’re sold after what you’ve read, fantastic! I’d love to hear about what a CMS will do for your workflows down the road. If you’re not quite sure yet, here are a few questions to ask yourself:

1. Are you deploying code to make simple content changes (text, images, video, etc.) at least once every other sprint or more?
2. If you answered yes to #1, would you like to enable non-engineering teammates to make those content changes to allow engineering resources to focus on other problems?
3. Are you sharing content in multiple places that would all need to be adjusted if that content were to change?
4. Do your content updates require an approval workflow?
5. Do you want to easily support multilingual translations?

If you said yes to 2 or more of these items (or even if you think you’ll say yes to 2 or more of these items within the next few years), a CMS could be an excellent way to optimize your workflows and free up development resources for new and exciting projects. If you’re at all like me, you’ll look back a year from now with a sense of accomplishment for all of the things you were able to tackle once you streamlined your content management.