Custom-built CMS, fully yours

In practice, “custom-built CMS” means one of three things, depending on what your team actually needs: a headless setup using an existing platform like Strapi, Directus or Sanity with custom content models and integrations, headless WordPress with custom plugins and a separate front-end (Next.js, Nuxt), or a custom Laravel or Node.js application with an admin interface that acts as a CMS for the data it manages.

Building a CMS from absolute zero (custom database schema, admin UI, content types, user management, API layer, all original code) is rarely the right choice. Off-the-shelf headless CMSes exist precisely so you don’t have to rebuild the boring parts. What we customise is everything that makes the CMS yours: the content model, the editor workflow, the integrations, the front-end, the deployment pipeline. More on the technical side in our CMS development work.

WordPress fits when content publishing dominates, when your team is comfortable in its admin, and when the integrations you need are reasonably standard. A custom-built CMS makes sense when permissions get complex, when the content model has unusual relationships, when performance demands are high, or when WordPress’s “everything is a post” model starts costing you more in workarounds than it saves in setup.

WordPress with custom plugins gets you far. We’ve built recruitment platforms, B2B sites, multilingual corporate sites and complex eCommerce on top of it. Custom usually wins when one of these is true: editors need workflows WordPress can’t model cleanly (approval chains, scheduled publishing across regions, content with non-trivial relationships), the front-end has performance demands that classic PHP rendering can’t hit, or the data is more important than the content (portal data, transactional records, structured operational information). Picking custom because it sounds more impressive almost always backfires two years later.

API-first means the CMS exposes content through a structured API (REST or GraphQL) rather than rendering pages directly. The content lives independently of where it’s displayed. Your website pulls content through the API. So can your mobile app, your in-store kiosk, your marketing automation tool, your AI search index, or any channel you haven’t thought of yet.

The practical benefit is decoupling. When the front-end changes (a redesign, a framework migration, a new channel), the content layer doesn’t have to follow. When the content model changes (new fields, new content types), the front-end can adapt independently. The trade-off is more upfront thinking about the content model and the API contracts, and slightly more moving parts to deploy. API-first works well for organisations with multiple digital touchpoints, or that know they’re heading that way. For a single-website use case, classic CMS rendering is often simpler and cheaper.

Content migration runs as a separate work block, usually after the new content model is finalised. We export from your existing CMS (WordPress, Drupal, Sitecore, AEM, Contentful, custom), map the fields to the new model, transform what needs transforming (HTML cleanup, asset path rewriting, taxonomy reconciliation), and import into the new system. Redirects from old URLs to new URLs get mapped and tested before launch so SEO doesn’t take a hit.

The trickiest part is rarely the technical export-import. It’s the editorial decisions: which old content stays, which gets retired, which gets restructured to fit the new model. We run that decision-making with your content team before the migration script runs, not after. For larger archives we do a test migration into staging first, let editors poke at it, then run the production migration during a planned content freeze.

Editors get an admin interface designed around their actual workflow, not around what the CMS framework offers by default. Content types match your real content (a “campaign” is a campaign, not a generic “post”), fields are grouped logically, validation prevents incomplete content from being published, and the preview shows what the front-end will actually render rather than a vague approximation.

For headless setups using Strapi, Directus or Sanity, we configure the admin so editors don’t see fields that don’t apply to them, set up role-based permissions that match your team structure, and add custom validation where the platform’s defaults aren’t enough. For headless WordPress, we use ACF Flexible Content (or similar) to give editors a block-based layout without the unpredictability of Gutenberg or page builders. The goal is that a new editor can publish their first piece of content within an hour of getting access, without reading documentation.

Each integration gets built with a clear contract: which events trigger which actions, what data shape is expected, how failures are reported. Authentication via OAuth or API keys is managed centrally, not scattered across endpoints. Updates to the CMS or to the integrated systems get tested in staging before production, with the integration contracts as the test cases.

The reason integrations break on every update is usually that they were stitched together with whatever worked at the time, with no clear ownership of the contract between systems. We build them with explicit input/output shapes, automated tests that run on every deploy, and monitoring that catches drift before users notice. For longer-lived clients we run a dedicated capacity model where one of our developers watches the integration layer, treating it as custom software that needs ongoing care, not a one-shot artefact.

Our hourly rate is €60-€65 across all roles (UX, frontend, backend, project management, QA), with our team split between Zwolle and Chandigarh. Custom-built CMS projects typically run €15,000 to €60,000 depending on scope, with platform-like products going higher. A headless WordPress setup with custom plugins lands at the lower end. A custom Laravel or Node.js application with multi-tenant features and complex integrations sits at the higher end.

The biggest scope variables are content model complexity (how many content types, how do they relate, how unusual are the editorial workflows), integrations (clean modern APIs are fast, older or custom internal systems take significantly longer), and migration work (a 100-page brochure site is different from a 50,000-article archive). Timelines run from 10 weeks for a focused headless WordPress build to several months for a custom platform. We scope it properly in the discovery week so you get a defensible number rather than a placeholder. Schedule a discovery call to walk through what you actually need.

After launch we offer ongoing support and maintenance through three packages: Care (4 hours per month, 24 working-hour response), Growth (8 hours per month, 8-hour response) and Partnership (16 hours per month, 4-hour response). Pricing starts at €240 per month, three-month minimum term, then monthly cancellable with one month notice.

Custom-built CMSes need ongoing attention more than off-the-shelf ones do, because there’s no vendor pushing automatic updates. We maintain the dependency tree, apply security patches, update framework versions on a planned cadence, and add new content types or admin features as your editorial needs evolve. For teams shipping regularly we run a dedicated-developer model with 40 to 160 hours per month, treating the CMS as a living product rather than a delivered artefact that gets touched once a year when something breaks.