How to choose: a decision tree for your project

Choosing a CMS or generator starts with five questions: who edits, how often, what else is needed, the budget and the languages. A custom CMS comes last.

A method instead of taste

We have looked at five paths: WordPress, a site builder, an all-in-one commerce platform, a static site generator and a headless CMS. What remains is how to choose. The answer is not about taste or fashion. The choice follows from five questions about your project, and you already know how each one works:

1. Who edits the content? The owner with no technical knowledge, an editor on a team, or a developer? (Lesson 1.)
2. How often? Every day, once a week, once a month, twice a year? That decides whether you need a comfortable admin. (Lesson 1.)
3. What is needed besides pages? A contact form, a shop, user accounts? Each is either part of the platform, or plugged in as a service, or means an app of your own. (Lessons 4 and 7.)
4. What is the budget? The money at the start, a subscription every year, and the time for upkeep. (Lessons 3 and 4.)
5. How many languages? One language is simplest. Two need a field for each language, or translations of entries. (Lesson 1.)

Click the ready-made projects in the diagram and change the answers: you’ll see how the decision shifts. It’s not the truth, it’s a way to see the logic.

One more thing belongs next to the budget: where the data will live. A site builder, a form service or a cloud CMS keeps your visitors’ details on someone else’s servers. If you collect personal data, the GDPR (for visitors in Europe) and the US state privacy laws expect you to know where it’s stored and who processes it. Ask each provider for a data processing agreement and a choice of region. This is general information, not legal advice. Russia takes the strictest line, requiring the personal data of its citizens to be stored in Russia, which is one reason Russian teams so often host their own systems.

A summary of the paths

When not to build your own CMS

The most tempting option for a developer is “I’ll write my own, it’s easier for me.” It’s almost always a mistake, and here is why.

A CMS is mostly dull work. The editing form is a small part. The rest is users and roles, passwords and account recovery, drafts and versions, a media library that crops and compresses images, fields for SEO, several languages, previews, backups, protection from break-ins, dependency updates, and a log of changes. Ready-made systems have all of it and have been through thousands of projects, while you would need at least a year of work and endless upkeep.

A “home made” CMS becomes a trap. In the 2000s many studios wrote their own systems for clients. While the author is at the studio, all is well. When they leave, the system is left without an owner, nobody updates it, holes are found in it, and the client has nowhere to move to. The client becomes a hostage.

There is an order in which to look for a solution. First configure what you have. Then take something ready-made: a plugin, a service, a block. Then assemble from ready-made parts (a generator plus a headless CMS, say). And write your own only after you have measured that nothing else will do. The order works beyond CMSs: nobody writes their own authentication, payments, search or email delivery either (part 6 says the same of authentication).

There are exceptions: when the CMS is your product, when the project has a unique data model and a team to maintain it, and when you’re learning. And the cheapest “custom CMS” is Markdown files in Git: the texts sit as files, and edits are commits. You don’t have to write it, it’s already made.

Not locking yourself in

A good choice can be changed. Three habits help. Keep the content in a portable form: Markdown, JSON, an SQL export, not only in a platform’s closed editor. Don’t change page addresses without need: addresses are the memory of search engines and of other people’s links. And check the exit in advance: once a year, export the site and see what you could carry away.

Practice

You’re in 2022, but looking at everything at once. Gather what you learned in this part into a decision card: who edits and how often, what handles the main action, how the languages are stored, the budget, the chosen stack and two options set aside with different reasons. End with the condition under which you would reconsider the decision.

What was wrong with choosing by habit

Choosing “because I know it” or “because that is our agency’s platform” ruined projects, because nobody predicted how a platform would change. The three habits (reasons, options set aside, a condition for reconsidering) turn the choice from a bet into a decision that can be checked and corrected.