CMS and custom development: when do you need them?
For a business website, first check what an existing CMS can handle after configuration. Add custom development where your requirements justify it: an integration, an editorial workflow or a business rule. Building your own CMS needs a stronger reason, because you must also maintain administration and publishing functions.
The decision concerns the people who publish as well as the technology. Have editors test real tasks before choosing: create a page, prepare its translation, get a change approved and find an earlier version.
Three levels of customisation
A website designed for your business can use an existing CMS. “Custom” can describe its design, content templates or selected functions without meaning that the team builds the whole system.
Configure a CMS
Work involved — Define content, templates, languages and permissions using available mechanisms
What to check — Can editors complete their tasks without workarounds?
Extend a CMS
Work involved — Add a specific feature, connector or interface
What to check — Who maintains the code and checks compatibility during updates?
Build a dedicated system
Work involved — Design the required administration and publishing functions
What to check — Which need justifies responsibility for this additional scope?
Configuration itself may require a developer. It can involve files, templates or extensions; it does not necessarily mean “no code”. Ask suppliers to separate standard functions, third-party modules and custom code in their proposals.
Describe requirements before comparing tools
List the content you need to publish: service pages, articles, references, documents or product records. For each type, define fields, relationships and who can edit it. Specify languages and who approves each version.
Write observable scenarios. “An editor prepares a French change; a manager approves it; the published version stays visible during review” gives you something to test. “A flexible and intuitive CMS” leaves too much open to interpretation.
Group requirements into launch essentials, useful later additions and optional features. For each custom feature, record the current problem, people affected and what they would do without it. You can then reject development whose usefulness does not justify its maintenance.
What Sulu, Drupal and WordPress illustrate
All three tools support websites adapted to specific needs. Their mechanisms and implementation differ; check the version and extensions planned for your project.
The Sulu 3.x documentation describes webspaces, hierarchical pages, languages and templates defining page properties. You can plan content structures specific to your website using that architecture.
In Drupal, Content Moderation lets you retain a published version while preparing a working copy for review. Combined with Content Translation, it supports separate moderation of each translation. You need to configure states, transitions and permissions for your organisation.
Content Moderation and Workflows are Drupal core modules. Automatic creation of the “Editorial” workflow depends on the installation profile; have its configuration checked. Separate moderation does not mean that every French change automatically triggers an English update.
WordPress supports registering custom content types. Its documentation recommends defining them in a plugin rather than the theme to retain that content organisation when changing themes.
These examples describe capabilities rather than a ranking. A documented feature does not prove that the delivered project includes it or that your team can use it. Request a demonstration within the proposed scope.
Decide from the requirements still unmet
Use this decision sequence:
1. Test the requirement using the chosen CMS and its configuration.
2. If it fails, examine a maintained, compatible extension or simplify the requirement where acceptable.
3. If a function is still missing, specify a custom extension with a maintenance agreement and tests.
4. Consider a dedicated system if the evaluated options cannot reasonably satisfy your central constraints. Document rejected alternatives and the cost of functions you would need to rebuild.
You can also retain the CMS for public content and use a separate tool for business operations. A transactional customer portal or CRM does not necessarily need to share the corporate website’s publishing system.
Example requirements for a French/English website
This is a proposed acceptance scenario, not a client case or a promised result.
Bilingual publication
Test to request — Edit French without publishing or overwriting English
Possible additional development — Translation connector or specific version tracking
Approval
Test to request — An editor saves a draft without permission to publish
Possible additional development — Extension to the approval workflow
Data from a business tool
Test to request — Import a record, then simulate the source being unavailable
Possible additional development — Connector with error logging and controlled recovery
URL change
Test to request — Check the old and new addresses after migration
Possible additional development — Redirect management in the CMS or server layer
Supplier handover
Test to request — Export content and document its structure
Possible additional development — Additional export for custom fields
For an integration, designate the authoritative system for each data item. Specify the direction of exchanges, edit rules and failure behaviour. An API alone does not settle those decisions.
Headless: assess editorial work too
In a headless architecture, the team separates content management from the interface that presents it to visitors. It can supply several interfaces from one content source. Consider this option when actual distribution needs or presentation constraints justify it.
Assess the additional work too: draft previews, page rendering, URLs, languages, search and deployment. Ask who owns each function. Measure speed using representative pages and content; the “headless” label guarantees neither speed nor better search rankings.
For a corporate website that your team needs to update without technical assistance, test previews and publishing as closely as the visitor interface. Visitors may like a website that editors find difficult to maintain.
Compare operating costs on the same scope
Compare proposals over a common period, such as three years. This is a calculation choice, not a prescribed standard duration. Use: initial cost + recurring costs over the period + planned changes + estimated exit cost. Separate confirmed amounts from assumptions and state the VAT treatment.
Initial costs include discovery, design, configuration, custom code, integrations and migration. Add content, translations, testing and training where the quote excludes them. See our guide to website budgets in Switzerland for more on website scope.
Depending on the project, recurring costs include hosting, licences, updates, technical monitoring and support. Ask about regression testing after updates and handling abandoned extensions. A solution without a paid licence can still require operating work.
Record exclusions such as content production, editor support, imported data corrections or new features. Ask what the warranty covers and what falls under maintenance. A cheaper proposal may cover less work.
Plan maintenance and handover
Identify who updates the CMS, extensions and custom code. Check how the team tracks dependencies, tests permissions and restores backups. Plugin count alone cannot tell you how secure a website is.
Plan a test environment and release procedure. For integrations, request error logs accessible to the people who need to intervene. Define how to handle a partial import and retry without creating duplicates.
At delivery, obtain the access, files and documentation agreed in the contract. Clarify code rights, third-party licences, export limits and conditions for transfer to another supplier. A usable export should let you understand relationships between content, media and translations.
Tests before accepting delivery
Have an editor and an approver carry out the agreed tasks using their own permissions. Test drafts, previews, approval, media and both languages. Check a restoration and a representative export too.
For migration, check old URLs, redirects, internal links and language annotations. Retain acceptance criteria for important journeys and mobile rendering. Our website creation and redesign service helps define these needs alongside content and interfaces.
Also test the transfer of fields, media and translation relationships on a representative sample. Specify handover items in the contract: exported content, code and configuration you are entitled to receive, model documentation and deployment procedure. A text-only file may omit what the next supplier needs.
Choose based on demonstrated behaviour in your scenarios, with a team and budget capable of maintaining it. Keep requirements, test results and responsibilities in a shared document.
Frequently asked questions
Does an existing CMS limit the design?
The result depends on the templates, theme and architecture. Request a demonstration of important components and their editing rules. Distinguish useful constraints that keep pages consistent from limits that prevent your intended uses.
Do we need our own CMS to control the website?
Control also depends on access, documentation, contractual rights and another supplier’s ability to take over. Examine these points for every option, including a dedicated system.
Can we add integrations after launch?
Yes, if the architecture and connected systems allow it. Define important data and interfaces during discovery even if you postpone implementation. This avoids treating an integration as assured when it may need structural changes.
How should we choose between Sulu, Drupal and WordPress?
Assess editorial scenarios, languages, integrations, available skills and operating costs. Ask the proposed team to demonstrate your tasks on the version and extensions it intends to deliver.