Choosing between an off-the-shelf CMS and a custom admin panel

Written By: BrainSoft In Engineering

Almost every project that needs an admin side reaches the same fork: install something like WordPress, Strapi or Django admin, or build the screens yourself. The decision usually gets made in an afternoon and then lives with the team for years. I have inherited both kinds of codebases, and the pain is different in each case, not absent in one of them.

Start from the content model, not the tool. If editors manage pages, posts and media, an off-the-shelf CMS will get you live in days. If the admin exists to drive business logic, approvals or integrations, a custom panel is usually cheaper over its lifetime. Below is how I actually weigh it.

What an off-the-shelf CMS buys you

A mature CMS ships with the boring parts already solved: a WYSIWYG editor, media library, revisions, roles, a plugin ecosystem, and documentation that new hires have probably read before. That is a real head start. On a brochure site or a blog, I can hand an editor a login on day two and they know what to do.

The cost shows up later. Plugins drift, and security patches arrive on someone else's schedule. Customising the admin often means fighting the framework's assumptions about what content is. I have watched teams spend two weeks bending a CMS into a shape it was never designed for, when the underlying requirement was a single form with a validation rule.

• Good fit: content publishing, marketing pages, small teams, fast launch.
• Watch for: plugin sprawl, admin UX you cannot change, upgrades that break customisations.
• Hidden work: theming around the CMS's markup, patching plugins nobody maintains anymore.

What a custom admin panel costs and returns

A custom panel means you own the schema, the permissions and the workflows. If an order needs three approval steps with different roles, you build exactly that instead of bolting it onto a CMS with a plugin plus a hook plus a cron job. The screens match how the business actually works, which matters most when the admin is used eight hours a day by staff.

The honest downside is that you are now responsible for the parts a CMS gave you free. Authentication, file uploads, audit logs, password resets, accessibility. None of it is hard, all of it takes time. Budget for it explicitly, because it is the line item people forget.

// The schema is the decision. If it looks like this, a CMS is fine.
const Page = {
  title: 'string',
  slug: 'string',
  body: 'richtext',
  publishedAt: 'date'
};

// If it looks like this, you are writing business logic, not content.
const Claim = {
  policyId: 'ref',
  status: 'enum:draft|review|approved|paid',
  approverId: 'ref',
  amount: 'decimal',
  auditTrail: 'append-only'
};

That second shape is where a custom panel earns its keep. State machines, money, and audit requirements are not content, and every CMS I have used treats them as an awkward guest.

The questions that actually decide it

I run through these with the client before writing any code. They are blunt on purpose, because the answers tend to be.

• Who uses the admin, and for how long each day? Occasional editors tolerate a generic CMS. Full-time staff do not.
• Does the data have states and transitions, or is it just records? States push you toward custom.
• Will the admin need to call internal systems, ERPs or payment providers? Integration logic is easier to own than to plugin.
• How long will this live? A two-year microsite and a ten-year operations tool deserve different answers.
• Is there a compliance or audit requirement? Append-only logs are trivial to build and painful to retrofit.

A middle path exists and is often right: a headless CMS for editorial content, plus a small custom panel for the operational side. Two systems, clear boundary, each doing what it is good at. If you want help scoping which side of the line your features fall on, get in touch and we can walk through the model together.

Migration is the part people underestimate

Whatever you pick, assume you will change it once. Content in a CMS is exportable but rarely clean: shortcodes, embedded plugin markup, media references that break. A custom panel's data is yours, but only if you wrote a migration path and kept the schema documented. I have spent more time untangling a WordPress export than I ever spent building a simple CRUD admin, and I have also seen a bespoke panel become unmaintainable because nobody wrote down what the tables meant.

So write the schema down either way. Keep an export script in the repo. Treat the admin as a product with users, not as a side effect of the database. That habit matters more than the initial choice, and it is the one thing I would insist on regardless of which route the team takes.

Frequently asked questions

#Engineering