Hvornår en headless webshop kan betale sig

Headless betyder at butikkens motor og butikkens facade er skilt ad. Motoren har katalog, priser, kurv, ordrer og kunder, mens facaden er en selvstændig applikation der henter det den skal bruge gennem et API.

I en traditionel opsætning er de to ting det samme program. PrestaShop eller WooCommerce renderer siden ud fra sine egne skabeloner, og ændrer du en skabelon, ændrer siden sig.

I en headless opsætning kan facaden være hvad som helst: et Next- eller Astro-site, en app, en kiosk i butikken, et katalog til en handelspartner. Motoren ved det ikke og er ligeglad.

Det er hele forskellen, og alt andet folk siger om headless, er konsekvenser af den ene beslutning.

De klassiske argumenter for headless var hastighed, frihed i designet og skalerbarhed, og de holder ikke så godt som de gjorde.

Hastighed først. En veloptimeret PrestaShop eller Shopify-butik med ordentlig caching og fornuftige billeder er hurtig nok til at score grønt på Core Web Vitals. Vi har målt headless-butikker der var langsommere end den løsning de erstattede, fordi frontenden hentede otte API-kald i vandfald før der stod noget på skærmen. Arkitekturen giver et højere loft, men ikke et bedre gulv.

Frihed i designet er også blevet et svagere argument. Moderne temaer kan langt mere end for fem år siden, og Hummingbird i PrestaShop 9 og de nye Shopify-temaer dækker de fleste behov. Når designfriheden reelt bliver bindende, er det efter min erfaring som regel fordi nogen har tegnet noget der ikke burde bygges.

Skalerbarhed er stadig et rigtigt argument, men for langt færre butikker end dem der bruger det. Skalerer I ikke ud over hvad en ordentlig server og et CDN kan klare, er det ikke jeres problem.

De tre argumenter alene har aldrig været nok, og de er ikke blevet bedre.

Arkitekturen har ikke ændret sig. Antallet af steder, jeres sortiment skal kunne læses fra, har.

For fem år siden havde I én frontend, nemlig webshoppen, og måske et feed til Google. I dag er der flere, og de er ikke jeres: en assistent der svarer på spørgsmål om jeres produkter, et katalog hos en markedsplads, en agent der sammenligner for kunden, en partner der trækker et sortiment ind i sit eget system.

I en traditionel opsætning er svaret på hver af dem en ny eksport. Endnu et feed, endnu et script, endnu en ting der går i stykker når nogen ændrer et felt.

I en headless opsætning er de bare endnu en forbruger af det API der allerede findes. Det er dér argumentet er blevet stærkere, ikke fordi jeres eget site bliver bedre, men fordi det ikke længere er det eneste sted data skal hen.

Læg mærke til nuancen. Det er ikke et argument for at rive frontenden ned, men for at motoren skal kunne svare ordentligt gennem et API, uanset hvad frontenden er bygget af.

Her ligger den fejl der koster mest.

At en platform har et API, betyder ikke at den har et API I kan bygge på, og vi ser tre problemer igen og igen.

Felter der ikke findes. API'et returnerer det platformen selv bruger, og de felter en agent eller en partner har brug for, altså kompatibilitet, mål, leveringstid og energimærke, findes ikke fordi butikken har skrevet dem i beskrivelsen.

Hastighedsgrænser der ikke passer. Et API der klarer jeres egen frontend, klarer ikke nødvendigvis tre partnere og en assistent der poller, og det opdager man typisk i november.

Ingen kontrakt. Felter skifter navn ved en opdatering, og alt der lå ovenpå knækker. Et API uden versionering er efter min mening ikke rigtig et API.

Derfor begynder vi altid med at se på datamodellen og ikke på frontend-rammeværket. Er produktdata rodet, gør headless det værre, fordi rodet nu er synligt fra flere steder på én gang.

Det her er den del der reelt er ny.

En sprogmodel læser ikke jeres side som en kunde gør, for den vil have strukturer. Og det den kan svare på, er præcis det der står som felter, mens alt der står i prosa er gætteri for den.

Det gør indholdsmodellen til det der afgør om I bliver valgt. Ikke designet, ikke teksten, ikke hastigheden, men strukturen.

En headless opsætning tvinger jer til at lave den struktur, fordi frontenden ikke kan vise noget der ikke findes som data. Det er nok arkitekturens bedste bivirkning, at den gør det umuligt at snyde.

Man kan sagtens lave den samme struktur i en traditionel butik, der er bare ingen der tvinger en til det, og derfor bliver det sjældent gjort.

Læg dertil MCP. Skal en assistent kunne slå op i jeres sortiment og svare på lager, er det nemmere at lægge en MCP-server oven på et eksisterende, ordentligt API end at bygge en der skal ind i en monolits indre.

Headless koster tre steder, og kun ét af dem står i tilbuddet.

I tilbuddet står frontenden, og det er den del alle regner med.

Ude af tilbuddet står det, I mister undervejs. Alle de færdige moduler der bare virkede: anmeldelser, størrelsesguide, cookiebanner, chat, loyalitetsprogram, prissammenligning. I en traditionel butik installerer man dem, i en headless butik bygger eller integrerer man dem, hver gang.

Det andet der ikke står, er driften. To systemer at opdatere i stedet for ét, to steder hvor noget kan gå ned, en frontend der skal bygges og deployes når indholdet ændrer sig hvis I har valgt statisk generering, og en udvikler der skal være der når marketing vil flytte en knap.

Vi plejer at regne med at den løbende omkostning er halvanden til to gange en tilsvarende traditionel butik. Ikke det dobbelte i licenser, men i timer.

Det er ikke et argument imod, men et argument for at kende tallet før beslutningen tages.

Headless er nok det rigtige valg når mindst to af de her er sande.

I sælger gennem flere kanaler end webshoppen, og kanalerne skal have samme data. Butik, app, markedsplads, partnere, og ikke bare "vi overvejer en app".

I har en indholdsmodel der ikke passer i platformens kasser: konfiguratorer, produkter med afhængigheder mellem valg, B2B-priser der afhænger af aftale og mængde.

I har udviklere, enten internt eller som fast partner, og ikke et bureau der bygger og forsvinder.

I har volumen nok til at loftet betyder noget, altså trafik der kommer i spidser som reelt presser platformen.

Og det fjerde, som er blevet vigtigere: jeres data skal kunne læses af andre systemer I ikke selv kontrollerer, og det bliver ikke færre med tiden.

Headless er forkert når butikken drives af to personer der begge har andre opgaver.

Det er forkert når det bliver solgt på hastighed alene, for så kan I købe hastigheden for en tiendedel af pengene ved at rydde op i billeder, scripts og moduler.

Det er forkert når begrundelsen er at platformen føles gammeldags, for følelser er ikke en arkitekturbeslutning.

Og det er forkert når produktdata er rodet. Så er rækkefølgen omvendt: ryd op først og byg om bagefter, hvis I stadig synes det er nødvendigt. Ofte er det ikke.

Der findes en mellemvej, og den er efter min vurdering den rigtige for de fleste.

Behold platformen som den er, lad frontenden være i fred, og gør motorens data ordentlige og tilgængelige.

Konkret betyder det at I flytter de felter der står i prosa ud som rigtige felter, sørger for at API'et eksponerer dem, lægger en MCP-server eller en veldefineret integration ovenpå når der er nogen der skal bruge den, og versionerer det I stiller til rådighed.

Det giver jer størstedelen af den gevinst headless bliver solgt på, altså at flere frontends kan læse jeres sortiment, uden at I skal bygge og drive to systemer.

Og skulle I senere beslutte jer for headless alligevel, er arbejdet lavet. Den svære del af en headless-migrering har aldrig været frontenden, men datamodellen.

Sådan afgør vi det med en kunde, og det tager en eftermiddag.

Skriv de frontends ned der skal kunne læse sortimentet inden for to år, og tæl dem. Er svaret ét, er headless sandsynligvis forkert.

Tag de tyve vigtigste produkter og skriv de spørgsmål ned som kunder faktisk stiller om dem. Tjek om svarene findes som felter, for gør de ikke, er det opgave nummer et uanset arkitektur.

Tæl de moduler I bruger i dag og som ville skulle bygges om, og gang med en realistisk pris. Det tal er som regel det der afgør sagen.

Spørg hvem der skal flytte en knap om seks måneder. Er svaret "vi skriver til bureauet", så regn med ventetid i den daglige drift.

Og sæt tal på loftet: hvad er den trafik I reelt har i spidsbelastning, og klarer den nuværende opsætning den. Måler I det i stedet for at gætte, falder argumentet ofte fra hinanden af sig selv.

Der er fire mønstre.

Det første er headless som svar på et hastighedsproblem der skyldtes 34 moduler og ukomprimerede billeder, og den regning bliver betalt to gange.

Det andet er at bygge frontenden færdig før nogen har set på indholdsmodellen. Så ender det med en smuk facade der henter data den selv skal sammensætte, fordi motoren ikke kan svare ordentligt.

Det tredje er at glemme redaktørerne. En headless butik uden et ordentligt redigeringsmiljø betyder at hver kampagne bliver en udviklingsopgave, og det dræber tempoet i marketing, hvilket er dyrere end noget andet i regnestykket.

Det fjerde er at tro at valget er permanent. Den rigtige rækkefølge er næsten altid at rydde op i data, gøre API'et ordentligt, og så se om I stadig har et problem.