Vad kostar en headless CMS-lösning?

Headless CMS är den moderna arkitekturen för innehållstunga sajter: ett innehållslager som Sanity eller Contentful i botten och en snabb frontend i Next.js ovanpå. Den ger prestanda och frihet – men kostar mer att bygga från start. Frågan är om den lägre löpande kostnaden hinner väga upp den högre initialkostnaden för just er. Här är prisbilden och de tydliga kriterierna för när headless lönar sig.

Vad det kostar att bygga

Initialkostnaden är högre än för ett traditionellt CMS av en enkel anledning: frontend och innehållshantering byggs som två delar som kopplas ihop, i stället för att komma färdigpaketerade. Den friheten kostar utvecklingstid från start – men det är också den som ger lägre kostnader längre fram.

Licensmodeller för headless CMS

Utöver bygget tillkommer en löpande licens för själva CMS:et. Modellen liknar varandra mellan leverantörerna:

• Gratisnivå. De flesta har en kostnadsfri nivå som räcker för små projekt eller för att komma igång.
• Månads- eller årsavgift. För en företagssajt handlar det ofta om några tusen kronor i månaden, och avgiften växer med antal användare, innehållsmängd och API-anrop.
• Enterprise. Stora organisationer med höga krav på support och säkerhet betalar mer, ofta med avtal per år.

Räkna med licensen som en egen post i den löpande kalkylen, skild från utvecklingskostnaden.

Kostnaden över tid: därför kan headless vinna

Det är i den löpande kostnaden headless har sin styrka. Samma innehåll skrivs en gång och flödar ut dit det behövs – webb, app, nyhetsbrev, skärmar – utan att skrivas om per kanal. Redaktörerna arbetar i ett gränssnitt byggt för innehåll, och den moderna frontend-arkitekturen är ofta billigare att underhålla och bygga vidare på än ett traditionellt system som växt sig tungt.

För en organisation som publicerar mycket och till flera kanaler kan den lägre innehålls- och kanalkostnaden med god marginal väga upp den högre initialkostnaden inom ett par år.

Det är värt att förstå varför besparingen uppstår. I ett traditionellt system är innehåll och presentation ihopbyggda, så samma text som ska ut i en app eller på en skärm ofta måste skrivas eller anpassas på nytt för varje kanal. I en headless-uppsättning bor innehållet i ett neutralt lager och levereras via API dit det behövs. Ju fler kanaler och ju högre publiceringstakt, desto mer betyder det – och desto snabbare räknas den högre startkostnaden hem. Har du bara en kanal och skriver sällan uteblir hela den vinsten.

När headless inte lönar sig

Lika viktigt är att veta när man ska avstå. Headless är fel val när:

• Sajten är liten och uppdateras sällan – då är den högre initialkostnaden svår att motivera.
• Ni bara har en kanal och inga planer på fler – en av headless största fördelar uteblir.
• Teamet är litet och vill ha allt i ett verktyg – ett traditionellt CMS är enklare att förvalta.

I de fallen gör ett traditionellt CMS samma nytta billigare. Ärligheten kring detta är viktig: headless är kraftfullt men inte alltid rätt.

Ett konkret scenario

Säg att en innehållsdriven organisation publicerar dagligen och vill nå både webb och app från samma källa, med en snabb sajt och full designfrihet. Då är headless rätt – räkna med 800 000–1 100 000 kr att bygga plus någon tusenlapp i månaden för CMS-licensen, och en lägre löpande kostnad som betalar igen skillnaden.

Ställ det mot ett traditionellt CMS för samma organisation. Startkostnaden hade varit lägre, men varje ny kanal och varje omgång innehåll hade kostat mer i arbete, och en tung installation blir med tiden dyrare att förvalta. Över några år, med hög publiceringstakt och flera kanaler, är det just den skillnaden i löpande kostnad som gör headless till den billigare vägen totalt sett. För en liten sajt med en kanal hade slutsatsen blivit den motsatta – och det är hela poängen: valet avgörs av hur mycket du använder innehållet, inte av vilken arkitektur som låter modernast.

Ett vanligt misstag är att välja headless för att det är på modet snarare än för att behovet finns. Den högre initialkostnaden är bara motiverad om publiceringstakten eller antalet kanaler faktiskt bär den. Vi på Weapp bygger headless-lösningar i Next.js och hjälper er först avgöra om arkitekturen passar era behov. Se våra tjänster eller hör av er med er publiceringstakt och era kanaler.