How to choose a CMS: an admin people will actually use

Developers choose it, you use it

A content management system is almost always chosen by whoever will install it rather than whoever will work in it every day. Most of the later complaints come from that.

The developer chooses on familiarity and build speed, which is reasonable from their side. But they will not be the one adding a hundred products, publishing an article on a Friday evening, or changing a price across every page at once.

The result is a site that is technically sound and that its owner is afraid to touch. Six months later they stop touching it entirely, and the site goes stale.

Below: how to choose so both sides are satisfied, and what to check before the decision is made.

What a content system is and what it is not

A content management system is what lets you change the contents of a site without a developer. Text, images, products, prices, pages.

It is not the design: the same system can look like anything, and a beautiful site does not mean a usable admin. That is exactly what gets confused during a demonstration.

Nor is it the site's feature set. A filtered catalogue, payments, an account area — those are built on top, and they can be built on top of anything.

In practice the question is this: what exactly must you be able to change yourself, without emailing the agency? The answer to that determines the choice.

And one more thing: a content system does not have to be one system for the whole site. Often it makes sense for the catalogue to be pulled from an accounting system while the text is edited in a separate admin.

Three approaches

They differ not in capability but in who is responsible for updates and how far you can move from standard behaviour.

A ready-made open-source system. Installed, extended with plugins, familiar to a large pool of developers. Cheap at the start with plenty of specialists available, but updates and security are on your side.

A cloud service. All maintenance is the vendor's, it updates itself, it rarely breaks. In exchange you live inside its rules and pay monthly.

A custom admin over your own code. Exactly the fields you need, nothing spare, full control. More expensive to build and it needs somebody to maintain it.

Our own site is built the third way, and the main reason is not flexibility but editorial rules: a piece does not enter search until it satisfies around twenty-five conditions on length, sourcing and structure. That kind of gate cannot be bolted into a ready-made system.

The main criterion: who will make the changes

Answer honestly, because everything else follows from it.

If the person editing content has no technical background, the admin has to be simple to the point of dullness, and flexibility is worth sacrificing for that.

If you have a developer or an agency on retainer, you can take a more powerful tool, because complexity does not get in their way.

If almost nothing will ever change and updates happen once a year, the question hardly matters and is not worth arguing about.

And separately: if several people with different roles will be entering content, that is its own requirement and has to be stated up front. Permissions retrofitted afterwards fit badly.

Five tasks to test an admin against

Do not watch a demonstration — ask for access and do five things by hand.

Create a new page or product from scratch, with a photograph and a description. Time it.

Change the text on an existing page and see how quickly it appears on the site and whether the layout survives.

Upload a photograph at the wrong size and see what happens. A good system crops and compresses it; a poor one shows it as-is and stretches the layout.

Find a way to change something across twenty pages at once. If there is no such way, you will be doing it by hand for the life of the site.

And try to undo your own edit. Being able to return to a previous version of a text is remembered exactly once, and on that occasion it is badly needed.

What a demonstration does not show

Demonstrations run on an empty site with three products. The problems start at three hundred.

Admin speed at volume. A list of a thousand items that takes twenty seconds to open is ordinary, and a demonstration will never reveal it.

Search inside the admin. Once there are many items, search is the only way to find one, and it can be surprisingly bad.

Bulk operations. Changing the category on forty products, raising prices by five per cent, unpublishing everything that is not selling. Without those, work becomes a slog.

And behaviour when two people work at once. Who wins if both opened the same page and saved? The right answer is a warning; the common answer is that whoever saved first is silently overwritten.

Plugins: the strength and the main danger

Ready-made systems have a plugin for every task, and that is their main advantage. It is also their main risk.

Every plugin is somebody else's code inside your site. It can slow pages down, conflict with other plugins, and carry vulnerabilities you will never see.

An abandoned plugin is the most dangerous of all: it keeps working but stops being updated, and within a year it becomes the hole people come in through.

The practical rules are simple. Before installing, look at the date of the last update and the install count. Do not run two plugins doing the same job. Every six months delete what you do not use — a disabled plugin is still code sitting on the server.

And keep a list: what is installed, why, and who decided. In two years nobody will remember.

Updates: Demonstrations run on three products; problems start at…

The dullest part and the commonest cause of a break-in.

Updates are released not for new buttons but most often to close vulnerabilities. A vulnerability becomes public knowledge, and from that day an automated sweep begins for sites that did not apply the update.

People skip them for an understandable reason: an update sometimes breaks the site. Hence the logic of if it works, do not touch it, which holds right up until the first break-in.

There is one correct order: a staging area, the update there, a check of key scenarios, then production. It takes half an hour and removes almost all of the risk.

And agree in advance who does it. Updates are recurring work; they need an owner and a place in the budget. Your host will not apply them for you.

Permissions

A point that surfaces at an inconvenient moment.

If several people manage content, each needs their own account with a role. Not one shared account whose password a former employee also knows.

The minimum set of roles: somebody who writes but cannot publish, somebody who publishes, somebody who changes settings. That covers most cases.

Think separately about what happens when somebody leaves. The account is disabled, not deleted — otherwise the record of who changed what disappears with it.

And check whether that record is visible at all. A change log answers who removed this block in one second; without it the same question is an unresolvable argument.

What to ask the agency

Six questions asked before signing rather than after.

Who will update the system and its plugins after launch, and is that in the price.

Is there a staging area where updates are checked before production.

Can all the content be exported in a portable form if we move to another agency.

How many people on the market can work with this system. The answer only us is not an advantage.

And show me how to make a bulk change across forty pages in this admin. Not describe it — show it.

How to check before deciding

A short procedure for one evening.

Take the list of what you will change on the site over a year: text, prices, products, articles, promotions.

Against each item note who will do it and how often.

Ask for access to a demonstration version and perform the three most frequent items by hand, timing yourself.

Multiply that time by the yearly frequency. The resulting number of hours is the real cost of the admin, and it usually exceeds the difference in build price.

If there is no time for arithmetic, there is a short rule: choose the simplest thing that covers your tasks. A shortage of capability is noticed immediately and fixed by development. An excess of complexity is noticed in a year, and by then nothing fixes it.