CMS-krønike #00: Hvorfor vi bygger dette bygger dette

E2E-ROUNDTRIP-1774627983401E2E-ROUNDTRIP-1774618691302Vi har bygget hjemmesider siden midten af halvfemserne. Ikke som et sideprojekt. Som vores hovedopgave. Vi startede det første rigtige webagentur i Danmark i 1995 — før de fleste havde hørt ordet. Vi var de første til at gøre mange ting, og vi bærer den historie med en stille form for stolthed. Vi har leveret et sted mellem tusind og tusindvis af hjemmesider gennem tre årtier — til læger, detailhandlere, advokatfirmaer, kommuner, startups der blev til virksomheder og virksomheder der blev til institutioner. Vi ved, hvad en CMS skal kunne, fordi vi har set, hvad der sker, når den ikke lever op til det.

Så hvorfor bygger vi en tredje?

Vi byggede Site Manager først. Derefter ODEUM CMS, som stadig driver hundredvis af klienters hjemmesider i dag. Begge var bygget med et specifikt formål for deres tid — og begge lærte os noget, markedet ikke kunne. Denne gang er det anderledes på én vigtig måde: @webhouse/cms er open source. Ikke et produkt, vi sælger. Ikke en platform, vi hoster. Et værktøj, vi giver tilbage.

“Hver CMS, vi har bygget, har været et svar på, hvad den forrige ikke kunne gøre. Denne er et svar på, hvad ingen af dem nogensinde var designet til at gøre.”

Ikke fordi de eksisterende muligheder er dårlige — nogle af dem er bemærkelsesværdige stykker ingeniørkunst — men fordi ingen af dem er bygget ud fra de specifikke antagelser, vi har om, hvordan webindhold bør fungere i 2026.

WordPress-problemet

Vi har bygget på WordPress i mange år. Vi vedligeholder stadig WordPress-hjemmesider. Det er udbredt af en grund: det gav ikke-tekniske redaktører reel autonomi på et tidspunkt, hvor det var radikalt. Men WordPress var designet til en verden, hvor udvikleren bygger strukturen, og redaktøren udfylder den. Den verden eksisterer stadig. Den er bare ikke den eneste længere.

Den kompleksitet, der ophobes i en moden WordPress-installation — plugin-afhængighederne, PHP-versionernes drift, databasen, som ingen fuldt ud forstår, temaet, der virker indtil det ikke gør — er ikke et svigt af WordPress. Det er vægten af tredive års bagudkompatibilitet. Vi respekterer den vægt. Vi er bare ikke villige til at bære den for nye projekter.

“WordPress løste 2005’s problem perfekt. Vi skal løse 2026’s problem.”

Headless-CMS-problemet

Det oplagte svar de sidste fem år har været: gå headless. Brug Contentful, Sanity, Prismic — adskil dit indhold fra din rendering. Og det gjorde vi. Vi brugte flere af dem. De er på mange måder fremragende.

Men headless-CMS’er har lavet en stille trade-off, der sjældent bliver nævnt direkte: de flyttede kompleksiteten fra serveren til integrationslaget. Du kæmper ikke længere med databasen — du kæmper med API’en. Du vedligeholder ikke længere en PHP-monolit — du vedligeholder en JavaScript-klient, der taler med en tredjeparts-service, hvis prismodel kan ændre sig, hvis API’en kan versionere, hvis oppetid er en andens SLA.

“En headless-CMS er ikke indholds-infrastruktur. Det er en indholds-abonnementstjeneste.”

Endnu vigtigere: alle headless-CMS’er, vi evaluerede, behandlede AI som en eftertanke. En webhook-trigger, måske. En integration, du kunne skrue på. Ikke noget, der var integreret i, hvordan indhold bliver skrevet, valideret og beskyttet.

Hvad vi egentlig tror på

Efter tredive års byggeri og to års observation af, hvordan AI forandrer, hvad det betyder at skrive kode og indhold, er vi nået frem til et sæt overbevisninger, som ingen eksisterende CMS fuldt ud afspejler.

• Indhold bør være filsystem-native. JSON-filer i en /content-mappe, committet til git, læseligt for ethvert værktøj — inklusive AI-agenter, der opererer direkte på repository’et.
• AI bør være first-class, ikke skruet på. Generering, omskrivning, SEO-optimering og indholdsbeskyttelse bør være indbygget i motoren, ikke samlet fra plugins.
• Menneskelige redigeringer er hellige. Hvis et menneske skriver en sætning, bør ingen AI nogensinde overskrive den uden eksplicit tilladelse. Felt-niveau-låse. Automatisk. Uforhandligt.
• Statisk output bør være standarden. Det færdige produkt bør være for-renderet HTML og CSS. Ingen runtime-rammeværk, medmindre udvikleren aktivt vælger det. Hurtigt, billigt, robust.
• Udvikleroplevelsen bør være begrænsningen. Hvis det tager mere end tres sekunder at have en fungerende CMS i et nyt projekt, har værktøjet fejlet.

Det er, hvad vi bygger. Vi kalder det @webhouse/cms.

Arven

Dette er ikke vores første CMS. Før headless-æraen byggede vi ODEUM CMS — et tilpasset content management-system, der drev en generation af vores klienters hjemmesider. ODEUM lærte os, hvad en CMS egentlig skal kunne på produktionsniveau: overleve redaktørfejl, håndtere struktureret data elegant og aldrig komme i vejen for den person, der blot skal ændre et telefonnummer klokken 21 på en fredag.

@webhouse/cms er efterfølgeren. Genopbygget fra bunden i TypeScript, designet til AI-native arbejdsgange, med tredive års produktionserfaring indlejret i antagelserne.

Hvordan byggeprocessen ser ud

Vi gør dette offentligt, i faser, og dokumenterer hver betydningsfulde beslutning i denne serie.

Fase 1 er fundamentet: skemadefinition, filsystem/JSON-lagringsadapteren, byggepipeline’en, der genererer statisk HTML, CLI’en og et komplet testsæt. Indholdsmodellering, persistens, output — den centrale løkke.

Fase 2 er AI-integration: en ContentAgent, der kan generere og omskrive indhold, en SeoAgent, der optimerer på tværs af hele sitet, hierarkisk URL-ruting og sitemap-generering. Og kritisk: AI Lock-systemet, der automatisk beskytter menneske-redigerede felter på feltniveau med et fuldt revisionsspor.

Fase 3 er produktionsinfrastruktur: en Supabase/PostgreSQL-lagringsadapter til teammiljøer, Docker-pakning og en Fly.io-deploy-pipeline. Når fase 3 lander, stopper dette med at være et lokalt værktøj og bliver noget, du rent faktisk kan køre i produktion.

Vi leverer på uger, ikke kvartaler. Den første commit er i denne uge. Den første rigtige hjemmeside kører på det kort efter.

Dette er den CMS, vi havde brug for for tredive år siden. Vi bygger den nu.

E2E-ROUNDTRIP-1774618691302

E2E-ROUNDTRIP-1774627983401