CMS or Custom Code? How to Compare Website Maintenance Costs

The useful question is not whether a content management system or a custom-built website is inherently more professional. It is who needs to change the site, how the changes reach production, and who will maintain the underlying software.

A small site with infrequent changes may work well as static files deployed from a repository. A publication with multiple editors may benefit from an established CMS. A complex service can combine a CMS for editorial content with a separate application for business logic. The right comparison is between actual proposals with the same scope.

Define the alternatives before estimating

A CMS provides a mechanism for managing content through an interface. Some products can be self-hosted; others are delivered as services. Their editing tools, integrations, licensing terms and data export options vary, so verify the particular product and configuration instead of treating a category label as a feature list.

“Custom code” is less precise. It might describe a few HTML, CSS and JavaScript files, a site generated from a repository, or a web application with a database and a custom administrative interface. A custom project can use established libraries, frameworks and hosted services. Building every component from scratch is not a requirement.

A hybrid is also possible: an editorial system stores content, while a separate application retrieves it and renders pages. Ask vendors to explain which parts they propose to build, buy or operate, and how those parts interact.

Compare the editorial workflow

Start with an actual content change. Ask the people who will maintain the site to create a draft, insert an image, preview the result, request a review and publish it. Then repeat the exercise with a restricted account. Note which steps require a developer and what happens when that person is unavailable.

A CMS can reduce repeated engineering work when authors frequently publish articles or update product information. Its usefulness depends on the editor, roles, templates and configuration. A powerful plugin is less useful if it makes ordinary publishing difficult or creates an undocumented dependency.

A static site may be practical when changes are rare and a team understands the repository and deployment process. “We only change a phone number occasionally” still needs an answer: who makes that change during an emergency, how is it reviewed, and how quickly can it reach the live site?

A custom administration interface can make editors independent, but it is itself software. Budget for access control, testing, documentation, defect fixes and ongoing changes.

Make the proposals comparable

Before comparing prices, give both teams the same list of pages, content types, integrations, user roles, availability expectations, security requirements and expected update frequency. Specify what the acceptance test must demonstrate.

A cheaper quote may omit content migration, testing, backups or training. Ask what is included, what counts as an extra, the number of support hours, response windows, and who pays for third-party services. An hourly rate alone says little about the total.

Separate launch spending from the recurring costs of ownership:

• Design, implementation, configuration and migration.
• Hosting, domain, licences and other subscriptions.
• Dependency and environment updates, compatibility testing and fixes.
• Backups and periodic restoration tests.
• Monitoring, form and integration maintenance, access management.
• Routine content changes, editorial work and staff training.
• New features and the cost of moving to another provider.

Some of these costs may belong to an internal team rather than an agency, but the time still needs an owner.

An illustrative first-year calculation

The following numbers are invented solely to show the method; they are not market rates or a quote. Assume equivalent agreed page, form, backup and testing requirements, and a fictional engineering rate of 3,000 rubles per hour. The recurring hours include the agreed maintenance and content changes. Editorial salaries and new features outside scope are excluded from both options.

The more expensive launch almost balances out in this deliberately constructed example because the recurring assumptions differ. Change the workload, licence, hosting, contractor availability or editing needs and the result changes too. A CMS might have no comparable licence fee; a custom application might need paid services or many more maintenance hours. Ask both providers to justify their assumptions and identify a separate contingency.

For a longer horizon, extend the recurring costs over the same number of years and include expected redesigns, renewals and migration expenses. Do not extrapolate a one-off setup estimate without checking which parts recur.

Performance, search and security are implementation questions

Neither a CMS nor static output guarantees a fast site. Image sizes, third-party scripts, caching, server response, network conditions and browser work all matter. Measure representative pages after configuration on devices and connections relevant to the audience.

Likewise, search visibility depends on accessible pages, useful content, working internal links, appropriate metadata, redirect handling and other factors. Check how each proposal handles page creation, URL changes, removed pages and sitemaps. A field in an editor does not ensure correct configuration or indexing.

Both choices need security and recovery work. Limit privileges, protect accounts, update components and practise restoring backups. For a CMS, identify responsibility for its core, themes and extensions. For custom software, identify responsibility for its libraries, environment and application-specific logic. Threats depend on what the site actually does.

Three practical scenarios

A small brochure site. If updates are rare and a developer can maintain a repository and deployment pipeline, static files may be sufficient. Confirm the process for urgent edits and handover. If the owner needs to edit every week, include a usable editing workflow.

A frequently updated publication. Several writers may need drafts, review, images and restricted roles. A CMS may provide much of this through existing tools. Test the real workflow rather than assuming every product has the same features.

A service with unusual business rules. A separate application may be appropriate for accounts, integrations and custom workflows, while a CMS handles public editorial pages. Document the boundaries, data exchange, ownership and incident responsibilities between the components.

Questions to settle before signing

1. What exactly is included in both estimates, and what is out of scope?
2. Who can make and approve a routine change without the original developer?
3. What are the launch costs, recurring costs and support hours for the same time horizon?
4. Who updates software, monitors failures and tests restoration?
5. Who controls the domain, hosting, repository, design assets and production credentials?
6. How can content and data be exported, and what would changing providers cost?
7. What documentation, acceptance tests and handover materials are included?

Choose the process your team can operate and fund after launch. The most economical architecture is the one that meets the agreed needs over time, including the human work needed to keep it useful and recoverable.

Russian original: https://morlix.ru/blog/cms-ili-sayt-na-chistom-kode-plyusy-minusy-i-stoimost-podderzhki

Original article (Russian)