Most projects we work on involve Content Management System (CMS) development or integrating with a client’s CMS. Here are our thoughts on choosing and using CMSs.
Do I need a CMS?
CMSs are a necessity for projects whose content will be updated frequently, by a large team, or by nontechnical users. Sites, apps, and installations whose content will be mostly static or will only be updated by technical users should add a CMS only with good reason.
Types of CMSs
Once we establish that a project needs a CMS, we take time to find a CMS that fits that project’s specific needs. We’ve worked with a wide range of CMSs over the years and that experience helps us find the best fit for a given situation.
Two main categories of CMSs that answer different business needs are coupled vs. decoupled CMSs.
Coupled
One of our favorites: Wagtail
Coupled CMSs bundle content editing together with a templating engine to provide an end-to-end solution for a project. Some of these CMSs can be decoupled and used only for the editing experience, but they are most effective when used completely.
Coupled CMSs are a great choice for sites that would rather rely on the server than the client to do work, or that don’t have a specific frontend system (e.g., React) as a requirement.
Many enterprise CMSs, such as Adobe Experience Manager, are coupled. Through working with large-scale clients, we have a lot of experience with enterprise CMSs that we might not organically choose as the focal point of a new project. While enterprise CMSs continue to answer some clients’ needs, others have been working to migrate to smaller, often decoupled CMSs, often backed by microservices.
Decoupled (Headless)
One of our favorites: Contentful
Decoupled CMSs provide only an editing platform and an API; developers bring their own frontend. They are often run as a service and can be queried by the live site or compiled to static markup.
A decoupled CMS is the best choice for static sites. Decoupled is also a good option when the frontend system is TBD or if we are integrating with multiple frontends.
Should I make my own CMS?
Generally, no. We’ve done this before; we can do it and it is fun to solve these problems, but it requires a huge time investment that is usually better served focusing on other aspects of the project.