Hva koster en headless CMS-løsning?

Headless CMS er den moderne arkitekturen for innholdstunge nettsider: et innholdslag som Sanity eller Contentful i bunnen og en rask frontend i Next.js oppå. Den gir ytelse og frihet, men koster mer å utvikle fra start. Spørsmålet er om den lavere løpende kostnaden rekker å veie opp for den høyere startkostnaden hos akkurat dere. Her er prisnivået og de tydelige kriteriene for når headless lønner seg.

Hva det koster å utvikle

Startkostnaden er høyere enn for et tradisjonelt CMS av en enkel grunn: Frontend og innholdshåndtering utvikles som to deler som kobles sammen, i stedet for å komme som én ferdig pakke. Den friheten koster utviklingstid fra start, men det er også den som gir lavere kostnader senere.

Lisensmodeller for headless CMS

I tillegg til utviklingen kommer en løpende lisens for selve CMS-et. Modellene ligner på hverandre hos de ulike leverandørene:

• Gratisnivå. De fleste har et gratis nivå som er nok for små prosjekter eller for å komme i gang.
• Måneds- eller årsavgift. For en bedriftsnettside dreier det seg ofte om noen tusen kroner i måneden, og avgiften øker med antall brukere, innholdsmengde og API-kall.
• Enterprise. Store organisasjoner med høye krav til support og sikkerhet betaler mer, ofte med årsavtaler.

Før opp lisensen som en egen post i den løpende kalkylen, atskilt fra utviklingskostnaden.

Kostnaden over tid: Derfor kan headless vinne

Det er i den løpende kostnaden headless har sin styrke. Det samme innholdet skrives én gang og publiseres der det trengs (web, app, nyhetsbrev, skjermer) uten å skrives om for hver kanal. Redaktørene jobber i et grensesnitt laget for innhold, og den moderne frontend-arkitekturen er ofte billigere å vedlikeholde og videreutvikle enn et tradisjonelt system som har vokst seg tungt.

For en organisasjon som publiserer mye og til flere kanaler, kan den lavere innholds- og kanalkostnaden med god margin veie opp for den høyere startkostnaden i løpet av et par år.

Det er verdt å forstå hvorfor besparelsen oppstår. I et tradisjonelt system er innhold og presentasjon bygd sammen, så den samme teksten som skal ut i en app eller på en skjerm, må ofte skrives eller tilpasses på nytt for hver kanal. I et headless-oppsett ligger innholdet i et nøytralt lag og leveres via API dit det trengs. Jo flere kanaler og jo høyere publiseringstakt, desto mer betyr det, og desto raskere tjenes den høyere startkostnaden inn. Har du bare én kanal og skriver sjelden, går du glipp av hele den gevinsten.

Når headless ikke lønner seg

Det er like viktig å vite når man bør la være. Headless er feil valg i disse tilfellene:

• Nettsiden er liten og oppdateres sjelden. Da er den høyere startkostnaden vanskelig å forsvare.
• Dere har bare én kanal og ingen planer om flere. Da faller en av de største fordelene med headless bort.
• Teamet er lite og vil ha alt i ett verktøy. Da er et tradisjonelt CMS enklere å forvalte.

I slike tilfeller gjør et tradisjonelt CMS samme nytte billigere. Det er viktig å være ærlig om dette: Headless er en kraftfull arkitektur, men ikke alltid det riktige valget.

Et konkret scenario

La oss si at en innholdsdrevet organisasjon publiserer daglig og vil nå både web og app fra samme kilde, med en rask nettside og full designfrihet. Da er headless riktig. Regn med 1–1,4 millioner kr for å utvikle løsningen pluss en tusenlapp eller så i måneden for CMS-lisensen, og en lavere løpende kostnad som etter hvert henter inn forskjellen.

Sammenlign det med et tradisjonelt CMS for den samme organisasjonen. Startkostnaden ville ha vært lavere, men hver ny kanal og hver runde med innhold ville ha kostet mer i arbeid, og en tung installasjon blir med tiden dyrere å forvalte. Over noen år, med høy publiseringstakt og flere kanaler, er det nettopp den forskjellen i løpende kostnad som gjør headless til den billigere veien totalt sett. For en liten nettside med én kanal ville konklusjonen ha blitt den motsatte, og det er hele poenget: Valget avgjøres av hvor mye du bruker innholdet, ikke av hvilken arkitektur som høres mest moderne ut.

En vanlig feil er å velge headless fordi det er på moten snarere enn fordi behovet finnes. Den høyere startkostnaden er bare berettiget hvis publiseringstakten eller antall kanaler faktisk kan bære den. Vi i Weapp utvikler headless-løsninger i Next.js og hjelper dere først med å avgjøre om arkitekturen passer til behovene deres. Se tjenestene våre, eller ta kontakt og fortell hvor ofte dere publiserer og hvilke kanaler dere bruker.