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.
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.
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.