Je Hebt Niet Altijd een CMS Nodig: Een Besliskader voor Moderne Websites

Als remote web agency in Nepal bouwen we een mix van service websites, marketing sites en product web apps. Eén vraag komt in bijna elke project kickoff terug: “Hebben we een CMS nodig?” Het eerlijke antwoord is: niet altijd. Veel websites zijn structureel simpel, en het toevoegen van een CMS creëert nieuwe operationele oppervlakken: auth, databases, permissies, plugin-risico, upgradewerk en editorial training. Dit artikel is een praktisch besliskader, gebaseerd op wat er nu verandert: static-first stacks, volwassen headless CMS’en en AI-ondersteunde editing workflows.

Begin met de taak die het “CMS” moet doen

Wanneer mensen “CMS” zeggen, bedoelen ze meestal één (of meerdere) van deze taken:

Een plek waar niet-engineers pagina’s kunnen aanpassen zonder een PR te openen.
Een gestructureerd model voor content types (posts, case studies, services, FAQ’s).
Editorial workflows: drafts, approvals, scheduling, rollen, revision history.
Content ops: redirects, interne linking, SEO-velden, mediabeheer.

Je hebt misschien maar één van deze nodig, niet het hele “traditionele CMS-pakket”.

Het “je hebt geen CMS nodig” profiel (meeste service sites)

Je hebt waarschijnlijk geen full CMS nodig als de meeste hiervan waar zijn:

Content verandert af en toe (niet dagelijks).
De site is vooral: homepage, services, about, contact en een blog.
Je contentmodel is ondiep (weinig relaties).
Je team kan leven met “content changes shippen via een releaseproces”.
Je hecht meer waarde aan voorspelbare HTML-output dan aan admin plugins.

In dat geval kan een static-first aanpak (MDX/Markdown + typed components + een build pipeline) een goede fit zijn. Als je op Next.js zit, combineer je dit meestal met een sterke technische SEO-basis:

“Maar wat met editing?” De echte beperking is workflow, niet technologie

Het sterkste historische argument voor een CMS was editing experience: “ons team kan geen Markdown editen en deployen”. Dat is nog steeds een faire beperking voor veel teams. Maar de vorm van die beperking verandert:

Veel teams gebruiken al Git-based workflows voor docs en product marketing.
Visual preview tools bestaan voor static en headless setups.
AI-ondersteunde editing verlaagt de drempel om tooling te leren.

De praktische takeaway: als je editing veilig en previewbaar maakt, kun je vaak een traditioneel admin panel overslaan.

Wanneer je wél echt een CMS nodig hebt (en er bewust één moet kiezen)

Een CMS verdient zijn complexiteit wanneer de website onderdeel is van een operationeel systeem met doorlopende editorial volume of complexe content-eisen. Je hebt waarschijnlijk wel een CMS nodig als je dit hebt:

Meerdere editors die vaak publiceren.
Role-based access control en approvals.
Content scheduling, revisies en audit trails als harde eisen.
Een sterk gestructureerd / relationeel contentmodel:
- products
- locations
- authors
- categories
- knowledge bases
Personalisatie of content die per user/session verandert.
Een site die in feite een applicatie is (membership, LMS, gated content).

In deze gevallen is een headless CMS of een “CMS + app framework” aanpak vaak de juiste tool.

De valkuil: “We bouwen gewoon een klein CMS”

Hier gaan teams vaak onderuit. De eerste versie klinkt klein:

een login screen
een editor
media uploads
publish/unpublish

Maar de echte CMS-eisen komen later:

rollen en permissies
drafts, previews, approvals
revision history en diffing
schema migrations
image transformations en optimalisatie
link integrity en redirect governance
abuse prevention, rate limits en content security

Als je een CMS bouwt, teken je ervoor om een ecosysteem aan concerns te onderhouden dat bestaat omdat content productie-infrastructuur is. Als je doel “pagina’s snel en veilig shippen” is, is het betere patroon:

een CMS gebruiken dat de moeilijke delen al oplost, of
helemaal geen CMS gebruiken en investeren in een workflow die contentwijzigingen veilig maakt

Een beslismatrix die we in echte projecten gebruiken

Hier is een set vragen die de juiste keuze meestal snel duidelijk maakt.

1) Hoe vaak verandert content?

Maandelijks of minder: static-first is meestal prima.
Wekelijks met meerdere auteurs: overweeg een CMS.
Dagelijkse editorial cadence: kies vroeg een CMS.

2) Wie moet kunnen publiceren?

Alleen engineers: MDX/Markdown is schoon en betrouwbaar.
Een klein team dat preview + gestructureerde forms kan gebruiken: lightweight content tooling werkt.
Veel niet-technische editors: CMS.

3) Heb je workflow features nodig?

Als je drafts, approvals, scheduling en rollen nodig hebt, beschrijf je een CMS.

4) Is je content relationeel?

Als je content afhankelijk is van relaties en queries (niet alleen pagina’s), wil je een CMS-backed model.

5) Is “pixel-perfect output” kritisch?

Static en MDX-first aanpakken winnen hier vaak omdat je end-to-end de HTML-output controleert.

CMS-alternatieven die goed werken voor agencies

In plaats van standaard naar een CMS te grijpen: kies de kleinste tool die de echte requirement oplost:

MDX/Markdown in-repo:
- het beste voor service sites, technische blogs en docs
- werkt goed met sterke QA gates en interne linking discipline
Een headless CMS:
- het beste als je gestructureerde content + editorial workflows nodig hebt
Een agent-native CMS (opkomende categorie):
- wil automatisering en AI-driven operations first-class maken
- voorbeeld: EmDash: Cloudflare’s Agent-Native CMS

Ons eigen voorbeeld: Lunover verhuisde van WordPress naar Markdown (2024)

In 2024 verhuisden we de Lunover site van WordPress naar een Markdown/MDX-first setup. Vandaag is ons “CMS” in essentie:

goed gestructureerde Markdown/MDX files in-repo
een kleine set herbruikbare componenten voor consistente secties (CTA’s, callouts, layouts)
een release workflow (preview, review, deploy)

Dit werkt voor ons omdat ons contentgedrag overeenkomt met het “geen CMS” profiel:

de meeste pagina’s veranderen niet vaak
edits zijn meestal klein en intentioneel (geen constante editorial publishing)
iedereen in het team kan Markdown lezen en ermee werken
structuur wordt afgedwongen door templates en conventies, niet door een dashboard

Het punt is niet dat WordPress “slecht” is. Het punt is dat zodra je content stabiel is en je team Markdown aankan, een CMS extra operationeel oppervlak kan toevoegen zonder evenredige waarde terug te geven.

Waar dit landt voor een web agency

Voor de meeste service websites is de “CMS-beslissing” eigenlijk een delivery-beslissing:

Wil je dat content changes worden beheerd als releases?
Of heb je een self-serve editorial systeem met workflow controls nodig?

We bouwen beide typen systemen, maar we kiezen bewust omdat het onderhoudsoppervlak op lange termijn anders is. Als je een nieuwe build of migratie plant en een aanbeveling wilt die past bij je team en updatecadence: