Een dag bouwen zonder remmen. Onze hackathon recap.

Een telefonische reservering, volledig door AI afgehandeld.

Het grootste project van de dag draaide om een vraag die steeds vaker op tafel ligt in de hospitality- en wellnesssector: wat als een gast gewoon belt, een gesprek voert, en aan het einde een reservering heeft staan? Zonder wachtrij, zonder formulier, zonder menselijke tussenstap? Dat klinkt als toekomstmuziek, maar het was onze vrijdag.

Om zoiets te laten werken, heb je drie lagen nodig die als tandwielen in elkaar grijpen: een backend die begrijpt wat er gevraagd wordt en de juiste data teruggeeft, een conversatie-engine die het gesprek stuurt, en een audiolaag die gesproken woord omzet naar tekst en weer terug. De keuze om dat plenair te starten, met een gezamenlijk architectuurmodel en uitgewerkte scenario's, bleek de juiste zet. Als het fundament wankelt, wankelt alles erboven.

De MCP-laag: het fundament onder alles.

Het eerste team begon met precies dat: een leeg vel en een bestaand data management platform. Daarbovenop moest een MCP-laag komen, een set endpoints die de voicebot kon aanroepen om informatie op te halen en acties uit te voeren. Wat er die dag tot leven kwam: endpoints voor het ophalen van producten, locaties en beschikbaarheid, plus de mogelijkheid om een boeking daadwerkelijk aan te maken. De reserveringsflow werkt. Iemand belt, de bot vraagt wat je wilt, de MCP-laag regelt de rest op de achtergrond.

Het slimste aan de architectuur is wat er nog niet inzit. De laag is bewust opgezet als uitbreidbaar fundament. Cadeaubonnen, complexere scenario's, extra rollen in het gesprek: de structuur staat er klaar voor. Bouwen voor vandaag én morgen tegelijk, dat is de uitdaging waar dit team vol op inzette. Claude werd ingezet voor de bouw van de MCP-laag. ElevenLabs voor de scripting en tooling van de bot. De conversatie-engine draait op Gemini Flash, aangestuurd via ElevenLabs.

De voicebot: van tekst naar telefoongesprek.

Als de MCP-laag het brein is, is de voicebot de stem. Het tweede team pakte het gesprek op, letterlijk. De uitdaging bij een voicebot is niet alleen technisch. Het is ook: hoe klinkt dit? Een eerste versie was ingesteld op de rustige, toegankelijke toon die bij een wellness-omgeving past. Prettig voor eindgebruikers. Minder handig als je snel wilt checken of een boeking wél of niet doorkomt. Oplossing: tijdelijk omschakelen naar een snellere testvariant. Pragmatisch en effectief.

Het resultaat aan het einde van de dag: een volledig gesprek van begroeting tot bevestigde reservering, afgerond binnen twee tot drie minuten. Iemand belt een nummer op, spreekt met een AI, en heeft een geboekte afspraak. Geen menselijke tussenstap nodig. Eén observatie bleef hangen: op een gegeven moment gebruikte vrijwel iedereen bij Cube tegelijk hetzelfde AI-model. Dat was voelbaar in de snelheid.

De Statamic Content Plugin: van ruwe tekst naar pagina in twee klikken.

Stel je voor: je hebt een Word-document vol goede content die eigenlijk al een webpagina had moeten zijn. Maar dan moet iemand dat handmatig vertalen naar de juiste CMS-componenten in de juiste volgorde. Hero bovenaan, tekstblokken ertussen, USP-kaarten, FAQ onderaan. Dat kost makkelijk een uur aan klikwerk. Dit team bouwde een plugin die dat probleem opheft.

De plugin werkt in twee fases. Eerst een scan: hij leest alle beschikbare Statamic-componenten uit, verwerkt hun veldstructuren en laat AI er een beschrijving bij genereren. Niet hard-coded, maar dynamisch. Voeg je morgen een nieuw component toe aan het CMS, dan pikt de plugin het automatisch op na een rescan. Dan de bouw: je plakt je tekst in de Page Builder, kiest een collectie, en de plugin zet er een volledige pagina van op. De editor ziet een preview met inklapbare kaarten per component en maakt met één klik een concept-entry aan in het CMS.

Technische uitdagingen.

De technisch leukste uitdaging? De conversie van HTML naar ProseMirror-nodes, het formaat dat Statamic intern gebruikt voor rich text. Geen simpele HTML-paragraaf, maar een geneste array van content-objecten, inclusief recursief verwerkte replicators met unieke ID's per kaart. Daarna volgde de integratie met Inertia.js, het framework dat Statamic 6 intern gebruikt. Het team reverse-engineerde het patroon vanuit een bestaande addon en maakte de plugin native voelen.

Halverwege de dag besloten ze de volledige UI te migreren van Blade naar Inertia. Niet gepland, maar het gevolg was een plugin die aanvoelt als een native onderdeel van het CMS in plaats van een los gereedschap. Claude Code draaide de hele dag mee als pair programmer: architectuurplanning, code-generatie, de Inertia-migratie en debugging.

Developer Mode voor React Native apps: meekijken zonder in te grijpen.

Stel: een gebruiker meldt een probleem in een app. Je wilt zien wat hij ziet, op zijn device, zonder dat je zijn account overneemt of zijn data aanraakt. Hoe doe je dat? Dat was de vraag achter dit project. Het antwoord is een Developer Mode-functie voor React Native apps die je binnen een dag kunt inbouwen in elk project.

Via een verborgen activatiemethode, beveiligd met een wachtwoord dat beheerd wordt via een omgevingsvariabele, opent een Developer-scherm met drie mogelijkheden. Impersoneren werkt via een QR-code die een medewerker genereert in het adminpanel. Die code is slechts zestig seconden geldig. Scannen in de app geeft read-only toegang tot de sessie van de gebruiker. Je ziet exact wat hij ziet, zonder iets te kunnen wijzigen. Stoppen doe je met één druk op de knop. De apparaatlogs registreren automatisch API-calls en errors in versleutelde bestanden op het device. Via het Developer-scherm zijn die per sessie in te zien, te delen via de share sheet (AES-256 versleuteld) of te wissen. 

Lastige puzzel: sessiebeheer.

De lastigste puzzel was sessiebeheer bij het impersoneren. Uitloggen wist normaal alle tokens, inclusief de originele sessie die je wilde bewaren. De oplossing: een patroon waarbij de eigen sessie in-memory bewaard wordt en na het impersoneren automatisch hersteld. Elegant, zodra je het ziet. Eén van die oplossingen die achteraf vanzelfsprekend lijkt. De hele feature, van backend tot app tot deep linking, encryptie en adminpanel, werd gebouwd via Claude Code.

Review Apps: elke feature zijn eigen speelveld.

Code reviewen doe je altijd op een acceptatieomgeving, nooit blind. Maar wat als je voor elke feature branch automatisch een eigen, verse omgeving krijgt? Dan hoef je niet te wachten tot iemand anders klaar is, en kun je wijzigingen beoordelen precies zoals ze bedoeld zijn, los van andere aanpassingen die toevallig ook op acceptatie staan.

Dat is wat dit team bouwde: review apps, automatisch aangemaakt per merge request, gebaseerd op Docker en GitLab CI/CD. Zodra een developer een feature branch aanmaakt, start een pipeline die via SSH verbinding maakt met een Docker-server en de applicatie opstart, compleet met database en cache-instantie. De URL wordt dynamisch gegenereerd op basis van project en issue.

Het fundament staat.

Daar bovenop: een preview-knop in het issue via een Chrome-extensie, en bij de merge request zelf een vergelijkingsfunctie waarmee je wijzigingen naast andere omgevingen kunt leggen. Aan het einde van de dag werkten de deploys van beide omgevingen, zowel lokaal als via de pipeline. Wat nog op de rol staat: standaard Docker-configuraties per framework en de volledige OTAP-straat. Maar het fundament staat. En met een eigen omgeving per feature wordt reviewen een stuk sneller en nauwkeuriger.

E2E-testen met een AI-agent: de browser als testpiloot.

Handmatig end-to-end testen is één van die taken die iedereen noodzakelijk vindt en niemand graag doet. Je klikt steeds dezelfde flow door, checkt of alles nog werkt, en hoopt dat je niks mist. Dit team pakte die uitdaging op met een AI-agent die het browserwerk overneemt. De basis was al aanwezig: een werkende OpenClaw/NemoClaw setup met browsergestuurde flows. Wat er nog moest komen waren robuustere testflows, betere tracing en slimmere omgang met accounts en credentials via 1Password. Wat er die dag gebouwd werd: browser actions voor navigatie, het selecteren van opties, het invullen van formulieren en het uitvoeren van validaties. Plus tooling voor reproduceerbare testflows en inzicht in tussenstappen via debug- en tracing-functionaliteit.

De grootste uitdaging was het betrouwbaar maken van multi-step browserflows. Dynamische pagina's, complexe reserveringsstappen, iframes en UI-state synchronisatie: het zijn precies de dingen waar geautomatiseerde tests graag struikelen. Het team werkte zich daar methodisch doorheen.Het resultaat aan het einde van de dag: een werkende desktop browserflow die een volledige reserveringsflow doorloopt, van datumselectie en extra's tot rituelen-stappen, en stopt net vóór de betaalstap. De basis voor volledige E2E-validatie ligt er. AI ondersteunde de hele dag bij architectuurkeuzes, het opzetten van de browserflows, testlogica en foutanalyse. De snelheid waarmee iteraties mogelijk waren, was merkbaar groter dan zonder.

En verder: twee projecten die de randen opzochten.

Nog twee projecten die de dag vulden, allebei op hun eigen manier waardevol: CI/CD-automatisering en een eerlijk experiment met een nieuwe technologie.

Een team werkte aan de integratie van een CI/CD-pipeline met een extern deploymentplatform voor Statamic en een DMP. Het doel: code van lokale omgeving naar staging deployen via GitLab, zonder handmatige stappen. Aan het einde van de dag werkte het deployen van beide omgevingen, lokaal én via de pipeline. De HTTPS-configuratie is nog een openstaand punt. De rest staat.

Dan was er nog een exploratie van Vue.js Lynx, een relatief nieuwe package voor het bouwen van native apps met Vue. De eerlijke conclusie na een dag: de documentatie is dun, custom fonts en SVG's geven problemen in de native variant en de styling is nog niet op orde. Maar veertig procent van de schermen staat, de webbuild werkt en het team weet nu precies waar de grenzen liggen. Dat is nuttige informatie. Weten wat nog niet werkt, is ook bouwen.

Tech Builds: wat een dag bouwen oplevert.

Aan het einde van de dag was er een demo. Iemand belde een nummer op, sprak met een AI en had twee minuten later een geboekte reservering. Een CMS-plugin zette een ruwe tekstdump om in een volledig opgebouwde webpagina. Een developer logde in als een andere gebruiker, keek mee en stapte er weer uit zonder een spoor achter te laten. Een AI-agent klikte zonder menselijke hand een volledige reserveringsflow door.

Dit zijn geen features uit een roadmap. Het zijn bewezen aannames, klaar voor de volgende sprint. Ideeën die in één dag de sprong maakten van "zou dit kunnen?" naar "dit werkt."

Dat is wat een hackathon doet. Het voorkomt maanden aan voorzichtig aftasten tot één dag vol directe antwoorden. En met een kantoor dat nu groot genoeg is om elk team zijn eigen hoek te geven, was er alle ruimte om die antwoorden te vinden.