Zo bouw je een AI-first website zonder CMS

Auteurs: Robert van Geenhuizen, thought leader in thought leadership, en Djahed Atayi, thought leader in commerciële AI-transformatie.

Voor de lijst van de vijftig invloedrijkste vrouwelijke CEO's en tech-leiders van Nederland bouwden we een rapport met vijftig profielen erin. Je kunt de lijst sorteren, filteren op taal, en per persoon staat er een grafiekje bij. Alles op één pagina, die in een middag af was.

Dat is het soort ding waar ik vroeger een offerte voor liet maken. Een developer, een sprint, en aan het eind iets wat nét niet deed wat ik bedoelde.

Sinds die aflevering krijg ik steeds dezelfde vraag, en die gaat niet over het rapport. Hij gaat over wat eronder ligt. Welke architectuur heb je nodig om een website zonder CMS te draaien?

Dit stuk is het antwoord. De onderdelenlijst, de volgorde, wat je juist niet nodig hebt, en vijf dingen die we ermee hebben gemaakt die je zelf kunt openklikken. Aan het eind staat een lijst die je kunt aftikken om te zien waar je staat.

Maar de hele architectuur staat er voor één ding. Je maakt wat nodig is, niet wat kan.

Eerst het punt, anders is de rest gereedschap zonder reden

Er zit een zin in de uitzending die ik sindsdien blijf herhalen.

"Wat technisch mogelijk was, was niet wat de prospect of de klant altijd nodig heeft."

En even later: "Alles wat je tot nu maakte was een compromis. En die compromis gaat eruit."

Daar gaat dit over. Niet over hosting, niet over frameworks, en niet over of een CMS goed of slecht is.

Twintig jaar lang bepaalde het systeem wat je kon maken. Je had een idee, je legde het naast wat je thema toeliet, en wat overbleef zette je online. Dat ging zo geleidelijk dat je het niet eens meer merkte. Je vroeg niet meer wat je lezer nodig had. Je vroeg wat er paste.

Drie wensen die nooit door de tekentafel kwamen

Maak het concreet. Dit zijn drie dingen die klanten mij door de jaren heen hebben gevraagd, en die geen van drieën gemaakt zijn.

Alle drie stuk gelopen op hetzelfde. Er was een plugin voor, en die plugin deed het net anders. Of er was een developer voor nodig, en dan werd het een project met een offerte en een oplevering. En tegen die tijd was de aanleiding weg.

Dus deed je het niet. Je schreef er een alinea over en je zette er een plaatje bij.

Het gekke is dat niemand dat als een beperking ervoer. Het voelde als hoe het werkt.

Vijf dingen die we ermee gemaakt hebben

Voordat de techniek komt: dit is wat eruit rolt. Drie dingen die live staan en die je zelf kunt openklikken. Bij elk ervan staat wat het vroeger had gekost, en dat verschil is het hele verhaal.

Ranglijstrapport

Vijftig profielen, sorteerbaar, op één pagina

Vijftig vrouwelijke CEO's en tech-leiders met hun cijfers, hun onderwerpen en hun ritme. Je zet de lijst om op de kolom die jou interesseert, je filtert op taal, en elk profiel heeft een eigen kaart met balkjes die de verhoudingen laten zien.

Kostte vroeger: een pdf. Of vijftig losse pagina's in een CMS, met een developer voor de sorteerfunctie en een redacteur die vijftig keer hetzelfde formulier invult.

Bekijk het rapport →

Zelftest in een artikel

Vier vragen, en een uitkomst die bij jou past

Onderaan het stuk over het CMS staat een keuzehulp. Je vult vier vragen in en er komt een antwoord uit dat bij jouw situatie hoort. Geen mailadres, geen opslag, en het staat in de pagina zelf en niet in een tool van iemand anders.

Kostte vroeger: een quiztool met een mailmuur ervoor, omdat het anders niet uit kon.

Doe de zelftest →

Met een database eronder

Deelcodes, een claim die aftelt, en een beheerscherm

Deze pagina heeft ambassadeurscodes op naam, een claimsysteem dat aftelt hoeveel plekken er nog zijn, en een beheerscherm erachter. Dat draait op dezelfde statische site. Zonder CMS betekent dus niet zonder functies.

Kostte vroeger: een plugin met een licentie, of een developer met een offerte.

Bekijk de pagina →

Dat eerste rapport is meteen het punt van de hele serie. Zo'n ranglijst kan tien dingen doen die de lezer helpen: sorteren, vergelijken, een plek in de lijst zoeken, een profiel opslaan. In een CMS kies je er nul van, want elk ervan is een apart project.

Er zijn er nog twee die hier niet als kaart staan. De presentatie-engine levert een voorstel van drieënveertig pagina's op, opgebouwd uit wat er over die klant bekend is, in de huisstijl van die klant. Die staat niet open, want er staat klantwerk in. En voor een klant bouwden we een rekenmodel met schuifbalken waarin iemand zijn eigen bedragen invult. Dat staat online, maar het draagt de naam van die klant, dus daar staat hier geen beeld van.

Tien dingen die een pagina kan doen zodra het compromis eruit is

De voorbeelden hierboven zijn van ons. Nuttiger is de vraag wat jij zou maken als het niets extra's kostte. Dit is de lijst die ik langsloop bij een stuk, en meestal blijkt er één ding bij te zitten dat het verhaal echt beter maakt.

• Een tabel die de lezer zelf sorteert. Twintig leveranciers, en iedereen kijkt naar een andere kolom.
• Een rekenmodel met de bedragen van de lezer. Jouw voorbeeld overtuigt niemand, zijn eigen getallen wel.
• Een zelftest die uitkomt op een advies. Vier vragen, en aan het eind staat er wat bij zijn situatie past in plaats van wat bij iedereen past.
• Een vergelijking waarin je twee dingen naast elkaar zet, en de lezer kiest welke twee.
• Een tijdlijn die je kunt uitklappen, in plaats van een alinea met zeven jaartallen erin.
• Een kaart of plattegrond waarop iemand zijn eigen regio aanklikt.
• Een grafiek uit echte data, die meegroeit als de data wordt bijgewerkt in plaats van een screenshot van een Excel van vorig jaar.
• Een filter over een lange lijst. Vijftig profielen zijn onleesbaar. Vijftig profielen met twee knoppen erboven zijn een naslagwerk.
• Een stuk tekst dat zich aanpast aan wie er leest. Kwam iemand binnen op een pagina over accountancy, dan gaat het voorbeeld erna ook daarover.
• Iets wat de lezer meeneemt. Zijn uitkomst, zijn lijstje, zijn versie van het model.

Geen van deze tien is nieuw en geen ervan is ingewikkeld. Ze werden alleen nooit gemaakt omdat elk ervan een apart project was.

In de uitzending werd dat verschil in één zin gevangen. Vroeger conformeerde je je aan wat het systeem toeliet, viel er in de uitzending, "en nu maak je wat je je kunt verbeelden".

In dat ranglijstrapport zitten er vier van in één pagina, en geen ervan heeft iemand apart gebouwd. Ze kwamen erin omdat ze het rapport beter maakten.

De vijf lagen, kort

Waar dit op staat hebben we in een apart stuk uitgelegd, dus hier alleen het skelet.

Onderop het taalmodel. Daarboven de waarheidslaag: alles wat waar is over jouw bedrijf, op een plek waar een machine bij kan. Daarboven de skills, het vastgelegde werk. Daarboven de agents. En daarboven een schil waarin iemand het geheel kan gebruiken zonder te weten hoe het in elkaar zit.

De website zit niet in die plaat. De website is wat eruit komt.

Dat is de denkfout die ik het vaakst zie. Mensen vragen naar de website-architectuur, en de website is het gevolg, niet het onderwerp.

Wie bij de website begint, bouwt een mooie schil om niets heen. Wie bij de waarheidslaag begint, krijgt de website er bijna gratis bij. Dat klinkt als een woordspel en het is het verschil tussen een traject van maanden en een week werk.

Welke architectuur heb je nodig om een website zonder CMS te draaien?

Je hebt er zeven nodig, en voor wat per bezoeker verschilt komt er een achtste bij.

Hieronder staat wat elk onderdeel doet en waarom het er is, zonder namen die indruk moeten maken.

1. Een map met de site erin, onder versiebeheerBij ons een Git-repo op GitHub. Elke wijziging is een commit en je kunt altijd terug naar gisteren. Dit is niet optioneel. Zonder geschiedenis durf je een machine niet in je website te laten schrijven.
2. Hosting die publiceert op een pushBij ons Netlify. Je duwt naar de hoofdtak en binnen een minuut staat het live. Geen bouwstap, geen server om te onderhouden, geen updates die 's nachts iets slopen.
3. Een contextmapDe waarheidslaag als bestanden naast de site: wie de doelgroep is, wat de producten zijn, hoe het merk eruitziet en klinkt, wat er eerder is gemaakt. Dit is het saaie deel. En het beslist alles.Hier begint het echte werk
4. Een taalmodel met toegang tot die mapBij ons Claude. Het model leest de context en schrijft in de repo. Let op. Het model is uitwisselbaar. Bouw je iets wat alleen bij één leverancier werkt, dan heb je je oude probleem terug in een nieuwe jas.
5. SkillsVastgelegd werk: welke stappen, in welke volgorde, met welke informatie, en waar een mens tussen moet. Een skill is het verschil tussen een model dat iets moois maakt en een systeem dat elke keer hetzelfde goede maakt. Djahed schreef op [hoe dat er in de praktijk uitziet](kennismaken-djahed-atayi).
6. BouwersKleine scripts die uit gegevens een pagina schrijven. Bij ons schrijft een script het artikel, een ander de beelden, een derde de deelkaart. Waarom niet alles door het model laten typen? Een script wordt niet moe. En het improviseert niet.
7. Controles die de deploy kunnen blokkerenHier komen we zo apart op terug, want dit is het stuk dat de meeste mensen weglaten. Het maakt het verschil tussen een demo en iets waar je op durft te bouwen.
8. En voor wat echt dynamisch is: een database plus wat kleine functiesBij ons Supabase en een handvol functies op de hosting. Alleen voor wat per bezoeker verschilt, zoals dat claimsysteem. De rest is gewoon een bestand.

Wat je niet nodig hebt

Dit rijtje is korter en scheelt meer.

• Geen CMS, en dus geen rechtenmodel, geen themalaag en geen upgradepad
• Geen framework, want er is niets om te compileren
• Geen bouwserver, dus ook geen bouwserver die omvalt
• Geen pakketbeheerder met een boom van afhankelijkheden eronder
• Geen staging-database die uit de pas loopt met de echte
• Geen plugins, en dus geen plugin-updates en geen lekken die erin zitten

Vraag er ook niet om. De reflex om die dingen erbij te halen is sterk, want zo hebben we het twintig jaar gedaan, en elk ervan komt met onderhoud dat niemand had ingecalculeerd.

Het scheelt ook aan de veiligheidskant meer dan je denkt.

van de kwetsbaarheden in het WordPress-ecosysteem zit in plugins, niet in WordPress zelf. Waar dat cijfer vandaan komt

Een onderdeel dat er niet is kan niet lek zijn, en hoeft nooit geüpdatet.

Dat geldt ook voor de bouwkant. Geen bouwstap betekent geen bouwstap die op een dinsdagochtend omvalt omdat een pakket ergens diep in de boom een nieuwe versie kreeg.

Hoe ziet die repo er van binnen uit?

Abstract blijft dit lastig te geloven, dus hier onze eigen map, met de namen erbij.

Zo ziet dat eruit als je erin kijkt. Elke regel is een wijziging aan de site, met een naam erbij die zegt wat er is veranderd en waarom.

Twee dingen die de moeite waard zijn om over te nemen.

Wat niet in de repo staat, komt nooit live. Dat klinkt als een open deur tot je het als gereedschap gebruikt. Ruwe transcripten van gasten staan bij ons in een map die is uitgesloten van versiebeheer. Niet omdat het gevoelig materiaal is, maar omdat het onbewerkte spraak is van mensen die geen toestemming hebben gegeven voor publicatie. Die map kán niet per ongeluk live komen.

Sleutels staan nooit in de repo. Ze staan lokaal op de machine en als omgevingsvariabele bij de hosting. Dezelfde waarde, twee plekken, nul in de geschiedenis van je project.

En één waarschuwing uit ervaring die veel tijd kost als je hem niet kent: zet zo'n map niet in een gesynchroniseerde cloudmap. Bij een van onze projecten verdwenen er tweehonderdtweeëntwintig bestanden tijdens een sync, en stond er vier dagen later oude code live vanuit een verouderde kopie, zonder foutmelding.

Welke diensten draaien er, en wat doet elk?

Tot hier ging het over de vorm. Nu de namen, want dat is de vraag die ik het vaakst terugkrijg: wat draait er dan echt.

Vier dingen dragen het, en meer is het niet.

GitHub houdt de site vast. Elke pagina, elk script en elke afspraak staat er als bestand, met geschiedenis. De hoofdtak is wat live staat.

Netlify zet neer wat er in de repo staat. In de instellingen staat letterlijk: publiceer deze map. Er is geen bouwstap, dus er is ook geen bouwstap die op een dinsdagochtend omvalt.

Supabase is de enige database, en die draagt alleen wat per bezoeker verschilt: aanvragen en deelcodes. De rest van de site is gewoon een bestand.

Claude leest de contextmap en schrijft in de repo. Uitwisselbaar, en dat is met opzet. Bouw je iets wat alleen bij één leverancier werkt, dan heb je je oude probleem terug in een nieuwe jas.

Daaromheen hangen vier diensten die elk één ding doen. Resend stuurt de bevestigingsmail, Slack krijgt de melding, Pipedrive krijgt de deal, en Calendly geeft de vrije momenten terug. Geen van de vier weet iets van de andere drie, en dat is precies waarom je er een kunt vervangen zonder de rest aan te raken.

En dan tien kleine functies op de hosting, voor de handelingen die een server nodig hebben. Ze draaien alleen als iemand ze aanroept, dus er staat niets te wachten dat je moet bijhouden of updaten.

Hier staan ze op een rij, met wat ze zijn, wat wij ermee doen, en waar je ze vindt. Alle acht hebben een gratis of goedkoop startpunt, en geen van de acht heeft een verkoper nodig om te beginnen.

En hieronder alle onderdelen bij elkaar, met wat er stukgaat als je er een weghaalt.

Van die acht is er maar één die iets van jouw bezoekers bewaart. Dit is de hele tabel achter elke aanvraag op deze site: tien kolommen, en daar past alles in wat een contactformulier, een boeking en een claim met een deelcode nodig hebben.

Twee dingen wil ik er apart uit lichten, want ze klinken als een detail en dat zijn ze niet.

De sleutels staan nergens in de repo. Ze staan lokaal op de machine en als omgevingsvariabele bij de hosting. Eén sleutel in een commit en hij staat er voorgoed in, ook nadat je hem weghaalt.

Alles wat met een liggend streepje begint gaat hard naar de foutpagina. Zonder die regel waren de werkbestanden van het ontwerp gewoon op te vragen op de live site. Dat is één keer nagekeken en toen rechtgezet.

Hoe gaat een wijziging van idee naar live?

De concrete keten, zoals hij bij ons loopt.

Je zegt wat er moet gebeuren. Dat kan een zin in een chatvenster zijn, of een spraakbericht onderweg.

Het systeem leest de contextmap. Wie is de doelgroep, hoe praat dit merk, welke pagina's staan er al, waar zou dit het beste passen.

Het schrijft een tweede versie van de pagina. Niet de bestaande. Een nieuwe, ernaast.

Het vraagt of het live mag. In de uitzending werd dat kort en goed samengevat: "Er zit gewoon een dubbele check tussenin."

Na dat ja gaat het naar de repo, de hosting bouwt, en binnen een minuut staat het er.

In de praktijk is een minuut ruim gerekend. Dit is de deploylijst van deze site op de middag dat dit stuk werd geschreven: negentien tot dertig seconden per wijziging, en elke regel is een commit die op de hoofdtak kwam.

De volgorde eromheen is waar het interessant wordt. Voordat er iets naar de hoofdtak gaat draaien eerst de harde regels en daarna de gewone controles. En nadat het er staat draait de hosting de harde regels nog een keer, voordat hij publiceert. Dat tweede is er niet voor de netheid: wie rechtstreeks naar GitHub pusht zonder eerst de controles te draaien, komt er anders gewoon langs.

Er loopt een tweede keten die net zo is opgebouwd, en die gaat niet over pagina's maar over mensen. Je maakt een deelcode op naam, die persoon deelt zijn eigen link, en wie daarop binnenkomt vult een formulier in. Die aanvraag gaat eerst in de database. Pas daarna gaan de bevestigingsmail, de melding en de deal eruit, naast het opslaan en niet ervoor. Valt de mail om of ligt het meldingskanaal eruit, dan staat de aanvraag er nog steeds.

Dat is de hele lus, twee keer. Wat hem bruikbaar maakt in plaats van eng, is de stap ervoor en de stap erna: de context waaruit hij put, en de controles die hem tegenhouden.

Waarom de controles het echte werk zijn

Hier scheidt het zich, en dit hoofdstuk is de reden dat ik dit stuk wilde schrijven.

Iedereen kan een model in een repo laten schrijven. Dat is een middag werk en het ziet er meteen indrukwekkend uit. Het probleem komt in week drie, als er iets doorheen glipt wat niemand ziet.

Bij ons draait er daarom een reeks controles, en die blokkeren de deploy.

• Of een blok een beeld heeft
• Of er geen resten van code in de uitvoer staan
• Of er geen zwarte balken in een beeld zitten
• Of elke klasse in de HTML ook echt een opmaakregel heeft
• Of verwijzingen wijzen naar bestanden die ook meegaan naar de site
• Of het ritme van de tekst nog klopt met hoe wij schrijven
• Of elk citaat letterlijk in het transcript staat, bij de juiste spreker
• Of de tekst nergens wegvalt tegen de kleur waar hij op staat

Twee dingen daaraan zijn belangrijker dan de lijst zelf.

De regel is niet nul, de regel is niet meer dan gisteren. Een site heeft een verleden. Eis je nul, dan zet iemand de controle uit op de dag dat het druk is, en dan doet hij nooit meer iets. Leg de stand van vandaag vast als basis en blokkeer op alles wat erbij komt. De oude rommel blijft zichtbaar en mag niet groeien.

En er zitten tests op de controles. Dat klinkt overdreven tot je het een keer meemaakt. Een controle die niemand naloopt verandert stilletjes in een leeg script dat groen staat, en dan denk je dat je gedekt bent terwijl er niets meer gebeurt.

Deze week gebeurde precies dat, bij ons. Een controle die nakijkt of een citaat bij de juiste spreker staat, zette er in het stuk over agentic AI negentien keer "klopt" onder. Hij keek of de woorden op dat spoor in het transcript stonden, en dat deden ze. Alleen stond in dat transcript zesentachtig procent van alle woorden op één spoor, dus dat spoor zei niets. Het hele stuk stond onder de verkeerde naam, met negentien groene vinkjes eronder.

De waarschuwing daarover stond al in onze eigen documentatie. Er stond letterlijk dit scenario, aangemerkt als de belangrijkste regel van dat bestand. Gelezen, en daarna toch op het vinkje vertrouwd.

Die controle weigert nu. Staat te veel op één spoor, dan zegt hij dat hij het niet kan bepalen en komt het stuk er alleen langs als een mens heeft opgeschreven dat hij het heeft nagelopen.

Dat is de les die ik boven alle techniek in dit stuk zet. Een regel die je alleen kunt lezen, bindt niet.

Heb je hier een technisch team voor nodig?

Een vraag die altijd komt: heb ik hier een technisch team voor nodig?

Nee, en dat is niet hetzelfde als niemand.

Wat je niet meer nodig hebt is de rij mensen die er tussen zat om het werk technisch mogelijk te maken.

Wanneer moet je dit juist niet doen?

Vier dingen zie ik fout gaan, en drie ervan hebben niets met techniek te maken.

Er zijn smaken, en dat is geen detail

Er viel in de uitzending een nuance die ik hier niet wil weglaten. Anders wordt dit een verhaal dat te mooi is.

Over die tweede smaak zei Djahed in de uitzending de zin die het scherpst is: "AI gaat zich dan conformeren aan wat Elementor en WordPress toelaat."

Je bent dan sneller. Je bent niet vrijer.

Wie vandaag alleen sneller wil publiceren, moet smaak twee nemen. Dit stuk gaat over smaak één, omdat de vraag die ik krijg daarover gaat.

De checklist

Loop dit af voordat je iets bouwt. De volgorde is niet willekeurig: elk punt maakt het volgende mogelijk, en de eerste vier dragen de rest.

Die eerste vier gaan allemaal over dezelfde vraag. Weet dit systeem wat waar is over jouw bedrijf, en houdt iemand dat bij? Dat is redactioneel werk en het staat los van elke techniekkeuze die je erna maakt.

De laatste vier gaan over de keten eromheen. Die zijn in een week te bouwen, maar alleen als de eerste vier er liggen. Andersom werkt niet, en dat is de volgorde waarin de meeste mensen het toch proberen.

Drie keer of vaker nee op die eerste vier wil zeggen dat je aan de verkeerde kant begint. Dat is te repareren en het kost vooral tijd, geen geld.

Wat kost het om dit op te zetten?

Het meeste werk zit in de opzet, en bijna al dat werk is niet technisch.

Wat eraf gaat is minder zichtbaar, maar het telt op.

Die laatste rij is wat je de afgelopen jaren niet hebt gemaakt.

Wat we niet weten

Wij hebben geen cijfer over wat dit oplevert. We zien het werk anders lopen en er komen dingen uit die er eerder niet uitkwamen, en dat is geen meting. Zodra we er een hebben staat hij hier.

We weten ook niet hoe dit uitpakt bij een organisatie met een redactie van vijftien mensen en een jurist die meekijkt. Wat wij zien is onze eigen keten en die van onze klanten, en dat zijn kleinere clubs waar iedereen elkaar spreekt.

En de smaak die wij draaien is de meest rauwe. Dat is de sterkste variant en tegelijk de variant die het meeste vraagt van de mensen eromheen.

Wat we evenmin weten is hoe lang deze opzet meegaat. Hij staat er sinds het voorjaar. Vraag het over twee jaar nog eens, en dan is dat pas een antwoord.

Waar het op neerkomt

De vraag die ik krijg gaat over architectuur, en het antwoord gaat maar voor de helft over techniek. De repo, de hosting en de bouwers zijn een week werk. De contextlaag en de mensen eromheen zijn het echte project.

Wat je ervoor terugkrijgt is niet snelheid. Het is dat de vraag verandert.

Vroeger begon elk plan bij wat er kon met wat je had. Dat werkte als een filter dat je niet zag zitten: ideeën die er niet doorheen pasten, kwamen nooit tot de tekentafel, en na een tijdje bedacht je ze niet eens meer.

Nu begint het bij wat de lezer nodig heeft, en dan bouw je dat. Je maakt wat nodig is, niet wat kan. Dat is een kleiner verschil in techniek dan het klinkt en een groter verschil in werk.

Dat merk je het eerst aan wat je collega's voorstellen. Als de reflex "dat kan niet in ons systeem" wegvalt, komen er ideeën boven die er al jaren waren.

Kijk dus niet als eerste naar je website. Kijk naar wat er over jouw bedrijf ergens staat vastgelegd, en wie dat bijhoudt. Daar begint het, en de rest is een week werk.

Verder lezen: waarom een CMS een probleem oplost dat niet meer bestaat, welke twee lagen er onder agentic AI horen, en wat er gebeurt als je sales nooit meer een presentatie maakt. Het ranglijstrapport waar dit stuk mee begon staat hier.