Een jaar geleden zag mijn werk eruit zoals dat van de meeste marketeers. Per klant een map op mijn laptop, een handvol documenten in Drive, wat losse exports, en een chatvenster waarin ik telkens opnieuw uitlegde wie de klant was en wat we vorige maand hadden afgesproken. Dat werkt tot een uur of drie 's middags. Daarna begin je jezelf tegen te spreken.
De opzet die ik nu gebruik is niet spannender dan drie keuzes. Al het klantwerk staat in een git-repository. Het werk zelf gebeurt in de terminal, niet in een chatvenster. En boven die repo's hangt een geheugenlaag die onthoudt wat niet in de code staat. Op mijn laptop staan inmiddels 52 van die repo's en 282 geheugenbestanden. Hieronder leg ik uit hoe die drie lagen in elkaar grijpen, en laat ik met de verbouwing van Flipperkast zien wat het concreet oplevert.
Laag 1: elke klant krijgt een repository, geen map
De eerste beslissing is de saaiste en de belangrijkste. Alles wat bij een klant hoort gaat in een git-repository op GitHub. Niet alleen code. Ook de productlijst als CSV, de kennisbank over de leveranciers, de researchnotities, de teksten, de exports uit Google Ads.
Het verschil met een gedeelde map is dat een repository een geschiedenis heeft. Elke wijziging is een commit met een datum, een omschrijving en een vorige versie waar je naar terug kunt. Als een klant in oktober vraagt waarom een prijs is veranderd, dan zoek ik dat niet terug in mijn hoofd of in een mailwisseling. Het staat in de historie, met de reden erbij.
Het tweede voordeel is minder voor de hand liggend. Een repository is de map die een AI-agent kan lezen. Een agent die in de repo van een klant werkt heeft de productdata, de kennisbank en de eerdere beslissingen binnen handbereik zonder dat ik ze hoef te plakken. Dat scheelt niet alleen tijd, het scheelt vooral fouten: de agent leest de echte prijslijst in plaats van een prijs die ik uit mijn hoofd noemde.
Laag 2: het werk gebeurt in de terminal
Ik gebruik AI nauwelijks nog in een chatvenster. Het draait in de terminal, in de map van de klant. Dat lijkt een detail voor techneuten, maar het verandert wat je kunt vragen. Een chatbot kan je advies geven over een categoriepagina. Een agent in de repo kan de categoriepagina bouwen, de build draaien, controleren of hij niet stukgaat, en de wijziging committen met een omschrijving.
Terugkerend werk heb ik vastgelegd als eigen commando's. Een handvol voorbeelden uit mijn eigen set:
/redesignleest de site van een prospect, kiest passende secties uit mijn eigen templatebibliotheek en bouwt daar een concrete homepage-variant van./proposalmaakt op basis van die variant een voorstel, inclusief de ideeën die in de pagina zelf zijn ingebouwd in plaats van als losse lijst ernaast./recapvat aan het eind van een werksessie samen wat er gebeurd is, in de vorm waarin ik het naar een klant kan sturen.
Zo'n commando is niets anders dan een tekstbestand met instructies. Dat is precies waarom het werkt: als de uitkomst niet goed is, pas ik de instructie aan en is de volgende keer beter. Bij een chatbot corrigeer je elke keer opnieuw dezelfde fout.
Laag 3: het tweede brein
De derde laag is de laag die mensen meestal overslaan. Een repository onthoudt wat er in de bestanden staat. Hij onthoudt niet dat een klant een hekel heeft aan een bepaalde toon, dat een meting tot 10 mei dubbel telde, of dat we een aanpak vorig kwartaal al hebben geprobeerd en hebben laten vallen.
Daarvoor heb ik een aparte geheugenmap. De regels zijn expres streng, want geheugen dat te vrij is wordt een rommellade:
- Eén feit per bestand, met een korte omschrijving bovenaan waarmee ik later kan beoordelen of het relevant is.
- Vier soorten: wie de klant of gebruiker is, feedback over hoe ik moet werken, lopende projecten, en verwijzingen naar externe bronnen zoals dashboards en tickets.
- Bij feedback altijd het waarom erbij. Een regel zonder reden wordt over drie maanden verkeerd toegepast.
- Bestanden verwijzen naar elkaar, zodat één feit je naar de aanpalende feiten brengt.
- Eén indexbestand met per geheugen een regel. Dat is wat er aan het begin van een sessie meekomt, niet de volledige inhoud.
Wat er juist niet in mag is minstens zo belangrijk. Geen dingen die de code zelf al vertelt, geen samenvattingen van gesprekken, geen wachtwoorden. En feiten die niet meer kloppen gooi ik weg in plaats van dat ik ze aanvul. Een geheugen dat je niet opschoont wordt een verzameling halve waarheden die net geloofwaardig genoeg is om schade aan te richten.
De eerlijke kanttekening: geheugen liegt met terugwerkende kracht. Een notitie van drie maanden geleden noemt een bestand of een instelling die inmiddels anders heet. Daarom is de vaste regel dat elk feit dat tot actie leidt eerst opnieuw gecontroleerd wordt in de bron. Het geheugen bepaalt waar ik ga kijken, niet wat waar is.
Wat die drie lagen samen opleveren: Flipperkast
Theorie is goedkoop, dus hier is een project dat volledig op deze manier is gedaan. Pinball Palace, de webshop achter flipperkast.nl, verkoopt en verhuurt flipperkasten en amusementsautomaten en doet dat sinds 1998. De bestaande site is een WordPress-site die vooral vertelt dat het bedrijf bestaat. Je kunt er niet bestellen, prijzen staan los van de voorraad en per uitvoering van een kast is er geen eigen pagina.
De verbouwing loopt in één repository. Daarin zitten de nieuwe WooCommerce-templates, 34 PHP-bestanden in totaal, de productlijst als één CSV met 73 producten, en een kennisbank per leverancier. Tussen 16 juni en 17 juli 2026 zijn er 104 commits gemaakt. Die nieuwe winkel staat op een afgeschermde testomgeving, dus de screenshots hieronder zetten de huidige live site naast de versie die klaarstaat.
Homepage
Links de site zoals hij nu live staat: een hero met een enkele knop naar een overzicht. Rechts de nieuwe versie, waarin de bovenkant van de pagina meteen doet waar een webshop voor is. Een balk met de dingen die klanten daadwerkelijk vragen (levering door heel Nederland, nieuw en gebruikt, eigen technische dienst), een zoekveld, een schakelaar tussen prijzen inclusief en exclusief btw, en een winkelmandje.
De btw-schakelaar is een goed voorbeeld van iets wat je alleen bouwt als je de klant kent. Pinball Palace verkoopt aan particulieren die een kast in de woonkamer zetten en aan horeca die hem exploiteert. Die twee groepen willen een ander bedrag zien. Dat staat in de kennisbank in de repo, dus het is een eigenschap van de winkel geworden in plaats van een discussie per offerte.
Aanbodpagina
Op de huidige site is verkoop een tekstpagina met een rode menukolom. Je leest waarom een speelautomaat gezellig is, maar je ziet geen aanbod. De nieuwe categoriepagina is een echt overzicht met filters, een teller die meeloopt met de paginering en een sorteervolgorde die ook werkt.
Productpagina
Dit is de pagina waar het verschil het grootst is, en waar de repo het meest heeft opgeleverd. Op de oude site is een flipperkast één pagina met een prijs en een lap Engelse tekst van de fabrikant. In werkelijkheid verkoopt een fabrikant als Stern dezelfde titel in verschillende uitvoeringen, met een prijsverschil dat in de duizenden euro's loopt.
In de nieuwe opzet zijn twaalf van die kasten uit elkaar gehaald naar 31 losse producten, elk met een eigen pagina, prijs en foto's, met onderlinge links tussen de uitvoeringen. Daaronder staat wat een koper echt nodig heeft om te beslissen: conditie en voorraad, opties zoals shaker motor en ontspiegeld glas met hun meerprijs, en de keuze tussen kopen, huren of langskomen.
Die splitsing was geen ontwerpkeuze, het was een datakwestie. Omdat de productlijst als CSV in de repo staat, kon ik zien dat de uitvoeringen als varianten waren opgevoerd terwijl klanten ze als losse producten zoeken. Op iemand met een eigen kast in zijn hoofd komt dat verschil hard aan: wie op de naam van een specifieke uitvoering zoekt, wil daar een pagina over vinden en geen keuzemenu op een algemene pagina.
Contactpagina
De laatste is de eenvoudigste, maar hij laat zien wat er gebeurt als je een pagina vanuit de vraag van de bezoeker opbouwt in plaats van vanuit het bedrijf. Adres, telefoonnummer, e-mail en openingstijden staan naast een kort formulier, in plaats van onder een menukolom met voorwaarden.
Toen en nu
| Onderdeel | Zoals het was | Zoals het nu werkt |
|---|---|---|
| Klantdossier | Map met documenten, kennis in mijn hoofd | Repository met historie per wijziging |
| AI | Chatvenster, elke keer opnieuw uitleggen | Agent in de repo van de klant |
| Terugkerend werk | Elke keer opnieuw prompten | Vastgelegd commando dat ik bijstel |
| Afspraken en voorkeuren | Verspreid over mail en gesprekken | Geheugenbestand met reden erbij |
| Productdata | Losse export per keer | Eén lijst in de repo, bron voor de winkel |
Voor wie dit werkt, en voor wie nog niet
Deze opzet is de moeite waard als je met terugkerende klanten werkt waarbij beslissingen op elkaar stapelen. Webshops, campagnes die maanden doorlopen, sites die stap voor stap worden verbouwd. Daar betaalt de investering zich terug in het tempo waarmee je in de tweede maand werkt.
Als je werk uit losse, kortlopende opdrachten bestaat, of als het bij één site blijft die je een keer oplevert, dan is dit overhead. Dan is het bijhouden van de geheugenlaag meer werk dan het bespaart. Er is ook een reële drempel: git, de terminal en het geduld om instructies bij te stellen in plaats van te klagen over de uitkomst. Wie dat niet wil, kan beter een deel automatiseren dan het hele stelsel.
De eerste stap is klein en kost een middag. Kies één klant waar je het meeste werk hebt, zet alles wat je over die klant hebt in één repository, en schrijf tien geheugenbestanden op met wat je over die klant weet en nergens staat. Werk twee weken zo. Wat je op dag tien opzoekt in plaats van bedenkt, is precies wat de opzet je oplevert.