CMS vs Custom Website: How to Choose

The useful question is not “WordPress or Next.js?” It is “who will change a page on a Tuesday, and what else is this site supposed to do?” Palmate builds websites on both CMS and custom stacks. We will not pick a CMS because it is familiar, or a custom app because it sounds more serious.

For cost shape — brochure versus portal — start with the website cost estimator. For build-versus-buy thinking that is not website-shaped, see custom software versus SaaS.

What you are actually choosing

A CMS (WordPress, a headless content tool, a hosted site builder) is rented editorial capability. Non-engineers can publish. You inherit plugins, themes, and an update calendar. You also inherit the attack surface of whatever you installed.

A custom site is owned presentation and routing. Engineers ship pages as code. Content can still be edited if you add a headless CMS or MDX files — that is a hybrid, not a third religion. You own performance, information architecture, and the obligation to deploy.

Neither choice is “more SEO.” Search cares about unique titles, crawlable HTML, and pages that answer a query. A slow plugin soup loses to a fast custom page. A custom site with no sitemap process loses to a boring CMS that actually publishes.

When a CMS is the right default

Use a CMS when the job is publishing:

• Marketing pages and articles change weekly by people who should not open a pull request.
• You need drafts, roles, and a media library more than you need a unique checkout.
• The integrations are common (forms, newsletter, analytics) and a maintained plugin exists.

A CMS is a poor default when the homepage is a thin wrapper over an operational system — authenticated portals, role-specific pricing, or a catalogue that is not a blog. You will fight the data model until the site is a second ERP.

WordPress can be operated well. It is not operated well when plugins are a shopping list and nobody patches. Launch still needs the website development checklist and the interactive launch checklist.

When custom earns its keep

Custom is justified when the site is software:

• Service pages, tools, and structured content that must share a design system and a sitemap generated from code — this site is that shape.
• Performance and accessibility budgets you cannot keep if every page loads a different plugin.
• Auth, dashboards, or estimators that do not belong in a theme.

Custom is a poor fit when the only requirement is “the owner wants to edit the about page” and there is no engineer after launch. You have bought a repo with no editor.

Headless CMS plus a custom front end is a valid hybrid: editors keep a UI; engineers keep routing, performance, and preview. It adds a second system to host and a preview contract to keep honest. Budget for that, or you will ship “edit in the CMS, see it live three deploys later.”

The 3-year total cost of ownership (TCO)

Decisions often falter because leaders compare initial invoice cost instead of lifecycle operating costs. A traditional CMS looks cheap to build but steadily increases in maintenance overhead as security vulnerabilities, plugin incompatibilities, and hosting upgrades mount.

The reality of headless CMS architectures

Many organizations jump to a "Headless CMS" believing they will gain the best of both worlds without compromise. In practice, headless introduces specific architectural obligations that must be designed before launch:

1. Webhook Invalidation & On-Demand Revalidation: When an editor hits "Publish" in the CMS, the static front-end must receive a secure webhook and invalidate the specific page cache without re-building the entire site for 15 minutes.
2. Real-time Live Previews: Non-technical writers refuse to publish blind. You must build a secure, authenticated preview route (/api/draft) that renders unpublished draft drafts alongside the live production design.
3. Content Schema Migrations: When a page design changes, the headless content model must be migrated without corrupting hundreds of existing published articles.

If your team does not have a dedicated frontend developer on retainer, adopting a headless stack usually ends in frustration where editors complain that publishing takes three steps instead of one.

Ownership and lock-in

CMS lock-in is plugins, shortcodes, and a theme only one contractor understands. Custom lock-in is a repo only one contractor understands. Both fail the same test: can a competent stranger publish a page and roll back a bad release?

Ask:

• Where does content live, and how do you export it?
• Who applies security updates?
• What is the preview and publish path?
• Can you leave without rewriting every URL?

If the vendor cannot answer, you are renting folklore.

A decision sequence

1. List who publishes, how often, and whether they will use git.
2. List pages that are really applications (login, tools, account).
3. Trial the CMS with your pages, not a theme demo.
4. Price the plugin and patch burden against an engineering retain.
5. Choose CMS, custom, or headless hybrid — and name an owner.

Palmate’s web development work starts with that inventory. If the honest v1 is a CMS, we will say so. If the honest v1 is a custom site with a small editorial workflow, we will say that too.

A website you cannot update is a brochure that dies. Pick the stack that matches who holds the pen.

Authoritative References & Standards

To cross-reference the engineering patterns and regulatory considerations described in this guide, consult the following authoritative industry documentation and RFC standards:

• Mozilla Developer Network (MDN) Web Docs — Authoritative specifications on HTML5 semantics, CSS Grid/Flexbox, and browser APIs.
• Google Web Vitals Standards (web.dev) — Benchmarks for Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).
• W3C Web Standards & Specifications — Global consortium guidelines for accessible, performant internet architecture.