# Rethinking Our Content Management Strategy
source: https://developer.mastercard.com/blog/rethinking-our-content-management-strategy/index.md

Authors: Kenny Chow. Mastercard Developers website has been powered by a full featured Content Management System (CMS) back-end and a responsive Single-page Application (SPA) front-end. Lately however, we've started seeing difficulty with scaling the application to handle higher traffic loads from around the world especially in newer markets. Horizontally scaling into each individual market would increase operating costs immensely, while vertical scaling doesn't help with reducing network latency. Furthermore, we are seeing a trend within the technical writing community in adopting the philosophy of "Documentation as Code". Our technical writers felt that this was highly suitable for API documentation for the following reasons: It enables closer collaboration with the development team Maintain similar versioning with the product releases Flexibility to customize workflows So late last year, we started exploring new ways to build our website by thinking about the aspects of technical writing, performance and scalability. Looking for a Solution We were inspired by JAMstack, a term coined by Mathias Biilmann which he defines as "JavaScript, APIs, and prerendered Markup". The idea is that we can create websites using a markup format like Markdown to generate a static page, then combine it with JavaScript and APIs to render in the browser. It simplifies content management tremendously because we don't have to build and maintain a user interface for content creation, database to store it or back-end servers to retrieve it. The simplicity meant that we can easily scale the amount of content on our website without adding burden to the back-end. Furthermore, our site is already built with JavaScript and APIs so it was naturally a good fit. With JAMstack architecture, our technical writers can get their jobs done more efficiently by focusing on the content -- not the CMS, and they can all work at the same time in a distributed fashion. Most importantly, they can write docs like code because Markdown is a plaintext format suitable for version control systems like Git. It is practically a type of source code for content. Building a Modern CMS Once we had our use cases defined, there were some initial work to do before we even had a minimum viable product (MVP) to deliver. First, we designed an architecture for this new CMS that would work for our content lifecycle and came up with the following four stages: Then comes the fun part of selecting tools to perform each task within the stages. As a result of going with this architecture, we can continually improve or swap out each individual tool without deprecating the entire platform. Here are some of the tools we chose: MermaidJS to generate diagrams (see related blog post here) Hugo as the static site generator Akamai CDN for content delivery Azure Pipelines for publishing jobs Next, we looked at our existing website and picked out what content can be re-done in the new CMS architecture. We chose API documentation first, and will be adding new content types over time. Over the next few months, we implemented the theme for Hugo static site generator, pipeline scripts and the integration between the components. At this point, we had an MVP that we could use for creating new content with. The Result Our technical writers began using the new CMS to develop content for Mastercard Developers. You can see an example page (a guide to generate and configure Mastercard API client) here. Content workflow is greatly streamlined consequently. Overall, we achieved much faster download time (as much as 50% less time) especially when loading content in newer markets where we don't have local servers. The reason for this improvement is largely due to absence of a database when accessing content (they're stored as plain files) and leveraging the capabilities of the Content Delivery Network (CDN) to optimize distribution. We also shipped a refresh of the website theme with new navigation menu, fonts, styles and layout. In addition, we introduced new features in the site like diagrams (generated using Mermaid JS), image lightbox and Swagger/OpenAPI interface. These user experience enhancements are crucial for delivering complex technical documentation in an accessible format to our users. What Next? The speed at which content can be created, published and served has convinced us that this is the right direction for our CMS. We intend to use it for most of our future content on Mastercard Developers. JAMstack and static site generator has opened many doors for us. As an MVP, we have validated the usefulness and viability of this new CMS. We will be looking at how to take advantage of the modular design to deploy new incremental functionality faster. One aspect that we hope to improve in the near future is the technical writer's user experience. To be able to use the new CMS effectively, they need to understand how the content is created in Markdown, built and pushed into a Git repository. We can simplify this by providing a web-based editor that hides all the complexity and give users a familiar WYSIWYG interface. With our architecture, we can connect it to the Build stage and everything else will continue to work. Our technical writers will be able to choose the tool of their choice (offline text editing or web-based experience) based on their own comfort and needs. During this journey, we discovered many pitfalls and best practices. Over the next few months we'll be posting some details of how we approached the different challenges and what we learnt from it.