Headless i AI-alderen: hvornår det er svaret, og hvornår det er en dyr omvej

Headless betyder, at butikkens motor og butikkens facade er skilt ad. Motoren har katalog, priser, kurv, ordrer og kunder. 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. Du ændrer en skabelon, og siden ændrer 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. Alt andet, folk siger om headless, er konsekvenser af den ene beslutning.

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

Hastighed: 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, ikke et bedre gulv.

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

Skalerbarhed: det 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.

Det, der er ændret, er ikke arkitekturen. Det er antallet af steder, jeres sortiment skal kunne læses fra.

For fem år siden havde I én frontend: webshoppen. 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 der, 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.

Bemærk nuancen. Det er ikke et argument for at rive frontenden ned. Det er et argument 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å. Vi ser tre problemer igen og igen.

Felter, der ikke findes. API'et returnerer det, platformen selv bruger. De felter, en agent eller en partner har brug for — kompatibilitet, mål, leveringstid, 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. Det opdager man i november.

Ingen kontrakt. Felter skifter navn ved en opdatering, og alt, der lå ovenpå, knækker. Et API uden versionering er ikke et API, det er et tilfælde.

Det er derfor, vi altid begynder med at se på datamodellen, 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. Den vil have strukturer. Og det, den kan svare på, er præcis det, der står som felter. 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. 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 arkitekturens bedste bivirkning: 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.

Det, der står i tilbuddet, er at bygge frontenden. Det er den del, alle regner med.

Det, der ikke står, er det, I mister. 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. 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. Det er et argument for at kende tallet, før beslutningen tages.

Headless er 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. Ikke "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 en fast partner. Ikke et bureau, der bygger og forsvinder.

I har volumen nok til, at loftet betyder noget. Trafikken kommer i spidser, der reelt presser platformen.

Og det fjerde, der 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 er drevet af to personer, der begge har andre opgaver.

Det er forkert, når det bliver solgt på hastighed alene. Køb hastighed 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. 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, byg om bagefter — hvis I stadig synes, det er nødvendigt. Ofte er det ikke.

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

Behold platformen som den er. Sæt frontenden i fred. Og gør motorens data ordentlige og tilgængelige.

Konkret: flyt de felter, der står i prosa, ud som rigtige felter. Sørg for, at API'et eksponerer dem. Læg en MCP-server eller en veldefineret integration ovenpå, når der er nogen, der skal bruge den. Versionér det, I stiller til rådighed.

Det giver jer størstedelen af den gevinst, headless bliver solgt på — 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. Det har været 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. Tæl dem. Er svaret ét, er headless sandsynligvis forkert.

Tag de tyve vigtigste produkter, og skriv de spørgsmål ned, kunder faktisk stiller om dem. Tjek, om svarene findes som felter. 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. 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.

Fire mønstre.

Det første er headless som svar på et hastighedsproblem, der skyldtes 34 moduler og ukomprimerede billeder. 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 skal sammensætte selv, 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. Det dræber tempoet i marketing, og det er dyrere end noget andet i regnestykket.

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