A content team can work around its CMS for years without noticing. A Google Sheet tracks what is waiting for approval, a WhatsApp message asks a developer to change a price, and three plugins cover things the system was never built for. The slowness is rarely in the writing. It sits in the steps around the writing that the CMS knows nothing about, and those steps are where a custom CMS earns its cost.
Where the time actually goes
When a general-purpose CMS does not match how a team works, the same symptoms show up. Approval happens outside the system, in email or a group chat, so nobody can tell at a glance what is waiting on whom. Editors run several plugins for what is, in their heads, one step. Changing a date or a price means asking a developer, because the content is tangled up with the layout. And connecting the CMS to a Next.js frontend or an email tool needs some workaround that only one person understands.
Take a travel company in Gurgaon that sells group tours and changes departure dates every week. Each itinerary is a hand-built page. The operations person messages the developer with the new dates, the developer edits the page, and the price in the sidebar still shows the old figure because it was typed in a second place. Nobody did anything wrong. The CMS simply has no idea that a departure date is a thing, so it cannot keep the two places in step.
None of these problems needs a custom CMS by itself. Together they tell you the content model and the workflow were designed for somebody else's team.
Content model first, screens second
The biggest change a custom CMS makes is that it starts from what the content is, before anyone draws an admin screen. For the Gurgaon tour company, a departure is not a paragraph on a page. It is a small record that several pages read.
tour: kumaon-lakes-6n
departure: 2026-03-14
price_per_person: 38500
seats_left: 9
status: open
Once a departure lives in one place, the itinerary page, the listing page and the booking form all show the same date and price. The operations person changes one field and every place that shows it stays consistent. The developer stops being the person who updates prices, which is better for everyone, including the developer.
The same thinking applies to the rest of the page. Instead of free-form pages, an editor fills named fields in a template, and the frontend renders them the same way every time. The person who presses Publish gets fewer choices about layout and more confidence that the page will look right on a phone.
Roles and states the whole team can see
A custom CMS also builds the team's actual steps into the system. The work usually lands in four places.
Roles and states come first. Writers, editors and approvers get different rights, and every item has a status the whole team can see, from draft through review and approval to published. The tracking spreadsheet goes away because the CMS now does its job. Templates come second, as described above.
Third, an API that other tools read. The website, a mobile app or the newsletter tool pulls from the same source instead of from a copy somebody exported last month.
Fourth, version history. Changes are recorded, so a wrong edit can be traced to a person and a time, and undone without anyone digging through backups.
- 01Draftwriter
- 02Revieweditor
- 03Approveapprover
- 04Publishcontent API
Changes requested go back to draft
Every state is visible to the team, and only the last step is public.
Keep the number of states small. Most teams need draft, review and published, and add an approval step only where a real person actually signs off, such as the finance head on anything with a price in it.
How the BéloVélo tour pages work
BéloVélo runs guided cycling tours on well-known French routes, and each tour has its own page. The pages were built from consistent templates with the same sections every time: the ride itself, highlights, what's included, availability and FAQs. The site also has clear paths for booking and inquiry, plus email capture for announcements.
The part that matters for workflow is that the team can add routes and update dates and prices without engineers. That works because a tour is structured content in a fixed template, not a hand-laid-out page. Changing a date changes one field, and the design does not break when they do it.
The same template approach is what lets new stage-themed pages, tied to the Tour de France, be published quickly while keeping their structure search-friendly. You can read the rest of the BéloVélo project story for how the pages were planned.
What usually goes wrong
Modelling pages instead of content. A "page" type with one big rich-text field hands the layout back to the editor, and six months later every page looks different and two of them break on mobile.
Too many states. A workflow with seven statuses gets bypassed within a month, usually by someone with admin rights who is in a hurry. Every state you add is another place an item can sit for a week with nobody noticing.
Permissions copied from the org chart. Rights should follow what a person does to content, not their designation. Otherwise the marketing manager is blocked from fixing a typo on the page she owns, and she will ask someone with more access to do it, which defeats the point.
AI suggestions with no owner. Auto-tagging and summaries are useful when an editor accepts or rejects each one. If the suggestions apply themselves, errors spread without anyone noticing.
Preview left for later. Editors who cannot preview a change in the real layout will ask a developer to check, and you are back to the WhatsApp message you started with. Build the preview in the first release, even if it is plain.
A one-hour exercise before you build
Sit with the editors and write down every step from idea to published, with a name against each one. It takes about an hour and it shows which parts of the workflow the CMS should own. Then work through this list:
- Mark the steps that currently happen outside the CMS, in chat or in a sheet.
- Choose the fewest states that cover them, and name who moves an item out of each state.
- Turn every page layout that repeats into a template with named fields.
- Find the details that change often, such as dates, prices, availability and seat counts, and make each one a single field that lives in one place.
- Check that an editor can preview a change without calling anyone.
If that last check fails, the developer dependency comes straight back. When the list is done, it doubles as the brief for a custom CMS build, and the piece on the features a custom CMS needs at launch will help you decide what goes in the first release.
