6 factoren die de prijs van een headless implementatie bepalen

Veel bedrijven en organisaties maken momenteel de afweging of ze hun volgende website laten ontwikkelen op een traditioneel CMS of een headless CMS. Niet vreemd gezien de groeiende populariteit van headless. Als je beide CMS-en met elkaar vergelijkt, zie je veel verschillen. Niet alleen in gebruik en implementatie, maar ook als het gaat om kosten.

In dit artikel zoomen we in op het laatstgenoemde aspect: wat zijn factoren die zorgen voor de kostprijs van een headless CMS-implementatie?

1. Licentie

WordPress is waarschijnlijk het bekendste traditionele CMS van deze eeuw. Één van de grote voordelen van WordPress is dat het gratis is, althans, je hoeft geen licentiekosten te betalen voor het gebruik. Achter WordPress zit een community die voor de doorontwikkeling zorgt. Al is WordPress gratis, realiseer je wel dat je voor hosting en onderhoud van dit CMS flinke kosten kunt maken.

In tegenstelling tot WordPress worden de meeste headless CMS-en (door)ontwikkeld door een bedrijf. De investeringen in de software worden terugverdiend door middel van licentiekosten. Met de licentie inkomsten kunnen weer nieuwe ontwikkelingen worden gedaan.

Vaak hebben headless-systemen een freemium model om te starten. In veel gevallen ga je pas betalen als je het CMS ook daadwerkelijk (op grotere) schaal gaat gebruiken. Je betaalt vaak per gebruiker, module of naar gebruik (bijv. API requests). Dit kan ervoor zorgen dat je licentiekosten redelijk snel stijgen.

Als je een headless CMS hebt ingericht, switch je niet zo snel meer naar een ander CMS, dus zorg van te voren dat je een goed beeld krijgt van de licentiekosten en welke variabelen zorgen voor een eventuele stijging. Ga er niet vanuit dat als je nu niets betaalt voor een traditioneel CMS je ook wel een headless CMS vindt wat je voor ‘een appel en een ei’ kunt gebruiken. Vaak gaan de licentieprijzen van een headless systeem dat door meerdere medewerkers wordt gebruikt en veel API-requests krijgt richting de duizenden euro’s per jaar.

2. Implementatie

Dat een headless CMS voortborduurt op een andere visie dan een traditioneel CMS komt sterk tot uiting bij de implementatie. Hier zie je ook vaak een conflict ontstaan. Een headless CMS wordt aangekocht omdat de visie toekomstbestendig lijkt, maar als de organisatie niet klaar is voor een omnichannel contentstrategie en ‘traditioneel’ blijft werken heb je weinig aan een headless CMS. Het artikel “Wat is de waarde van een headless CMS bij traditioneel gebruik?” gaat dieper op dit onderwerp in.

De implementatie kent twee factoren die de kostprijs bepalen:

1) je interne medewerkers en hun kennis en kunde,
2) de expertise die je moet inkopen voor een succesvolle implementatie.

Welke expertise heb je nodig bij een Headless implementatie?

Ik ga er even vanuit dat je een headless CMS vanuit een omnichannel contentstrategie wilt implementeren. Omnichannel betekent dat een bedrijf een naadloze klantervaring uitserveert over alle kanalen (offline, online, app, etc) waardoor het één kanaal lijkt. Vaak zie je dat organisaties wel een headless CMS aanschaffen, maar de implementatie op een traditionele manier uitvoeren.

Bij een headless implementatie heb je twee rollen harder nodig dan bij een traditionele implementatie: de content architect en de content curator.

De content architect helpt bij het organiseren van content en adviseert de beste aanpak om de content te structureren, zodat het gemakkelijk kan worden hergebruikt in verschillende situaties en op verschillende kanalen en apparaten.

De content curator verzamelt, selecteert en filtert de content en plaatst het in context. Content curatie is steeds harder nodig, omdat bedrijven veel content produceren, maar er daardoor ook veel waardevolle content verloren gaat.

Er is tegenwoordig zoveel informatie en de meeste consumenten hebben niet de tijd (of de zin) om al deze content door te spitten. Dat is exact waar de content curator op focust. Die kijkt wat voor de doelgroep relevant is, om welke inhoud ze het meeste geeft om dit vervolgens in een perfecte boog te presenteren.

Een fout die veel bedrijven maken, is om de rol van curator te zien als een coördinerende rol. Echter heeft de curator ook daadwerkelijk strategische skills om de verbanden tussen content te analyseren en te weten bij welke ‘buyer persona’ de content hoort en te bepalen waar de content binnen de ‘marketing funnel’ thuishoort.

De rol van content architect en content curator hebben maar weinig bedrijven en organisaties intern beschikbaar. Binnen marketing en communicatie wordt content toch nog vaak gezien als ordinair productiewerk terwijl je bij een succesvolle headless implementatie anders naar content moet kijken.

Als je kijkt naar de overige rollen, dan zijn die vrij ‘traditioneel’. Denk aan: een (content)marketeer, strateeg, SEO-expert, designer, developer, etc. Heb je één of meerdere rollen niet beschikbaar, dan zul je deze extern moeten inhuren. Headless trajecten zijn vaak stevig qua impact in uren, dus maak ruim budget vrij.

3. Customizations

Een andere factor die de prijs van een headless CMS implementatie kan opdrijven, is de behoefte voor aanpassingen. Voor de front-end heb je bij een headless CMS enorm veel vrijheid, maar omdat je niet zomaar bij de broncode van het CMS kunt komen (er zit namelijk een bedrijf achter), kun je niet zomaar even een paar modificaties aan het systeem doen. In heel veel gevallen wil je dit ook niet, maar als je specifieke wensen hebt over hoe een oplossing moet werken, dan is het verstandig om hier goed onderzoek naar te doen.

4. Apps

Dit onderdeel is niet voor iedereen relevant maar we hebben hem door de jaren heen een aantal keer zien langskomen: een app. Als een bedrijf een eigen app heeft is deze vaak als ‘monoliet’ naast de bestaande communicatie (portal, website, etc) ontwikkeld. Als een bedrijf de ‘omni-channel content’ filosofie achterna gemaakt moet deze app ook ‘opeens’ meegenomen in het headless traject. Je kunt dit dus beter van te voren bedenken dan halverwege of aan het eind van het traject.

5. Integraties

Een website of app staat zelden op zichzelf, zeker niet binnen een headless CMS-implementatie. Vaak moet (ruwe) data uit andere bronnen komen, of bijvoorbeeld uit een uitgefaseerd CMS, een CRM-systeem of een Customer Data Platform. Hoe meer integraties des te meer uren je moet spenderen aan het ontwikkelen van de integraties als ook aan eventuele modules die je moet aanschaffen om koppelingen te maken.

Bekijk van te voren of een headless CMS kan integreren door middel van een GraphQL, REST API, webhooks en/of Zapier of Mulesoft. Hoe beter een CMS koppelbaar is des te minder kostbare tijd er besteed hoeft te worden aan dure integraties.

6. Hosting / veiligheid / upgrades

Het laatste onderdeel betreft hosting, veiligheid en doorontwikkeling. Als een headless CMS ook een ‘hosted CMS’ is, wordt er vaak centraal zorg gedragen voor hosting, veiligheid en upgrades. De kosten hiervoor zitten dan verdisconteerd in de licentieprijs. In sommige gevallen moet je nog extra voor gebruik en hosting bijbetalen als je de ‘fair use policy’ overschrijft.

Kies je een ‘self hosted’ headless CMS dan zul je zelf voor deze zaken moeten zorgdragen. Dit kan een behoorlijke impact op je budget hebben. Zeker security is een onderdeel wat aandacht vraagt, dus analyseer vooraf wie er verantwoordelijk is voor dit onderdeel.

Conclusie

Door de jaren heen hebben we bij meer dan 1000 CMS-selecties en -implementaties meegekeken en meegedaan. En ja, wij zullen snel Plate adviseren, zo eerlijk moeten we zijn. Toch hebben we door de jaren heen geleerd om niet zomaar iedere klant en traject op het Plate platform te onboarden. We willen dat klanten bewust voor Plate kiezen omdat ze goed nadenken over wat ze wel en niet hebben. Als blijkt dat een ander CMS dan beter past, vinden we dat eigenlijk niet echt een probleem. De markt is groot genoeg en we weten waar we sterk in (willen) zijn.