Een betaald product bouwen met een AI-team van 18 agents: het bouwlog van PlainConsent

Mijn team is gebouwd om marketing te maken. Ergens dit voorjaar begon het software te maken.

PlainConsent is een cookie-consent-platform: een banner die je bezoekers zien, en daaronder een dienst die sites scant, toestemming vastlegt en de facturatie doet. Het is het eerste betaalde product uit hetzelfde agent-systeem dat mijn content schrijft en mijn merk bewaakt. Dit is het bouwlog, mét de delen die normaal gesneuveld waren: de twee kritieke security-gaten, de review die stierf op een maandlimiet, en wat er eerlijk gezegd nog niet live is.

Wat er live is, en wat niet

Die tabel is de hele filosofie in vier regels. Alles wordt open gebouwd en getest, en niets gaat live tot een mens dat besluit.

Waarom uitgerekend een cookiebanner

Omdat ik een werkwijze verkoop, en een werkwijze eerst bewijs nodig heeft voordat ze klanten verdient. Dogfood eerst: het systeem moest een jaar mijn eigen marketing draaien voordat het aan een product mocht beginnen. Hier geldt dezelfde volgorde. Eerst moet het product onder mijn eigen regels werken, daarna mag het verkocht worden.

Een consent-banner is bovendien een scherpere test dan hij lijkt. Hij staat op andermans website, voor andermans bezoekers, onder Europese privacywetgeving. Saaie categorie, nul tolerantie voor slordigheid. Precies wat je wilt laten bouwen door een proces dat zijn eigen reviews niet kan overslaan.

De banner kwam eerst

De zichtbare helft is één script: blokkeert standaard, vraagt eerst, onthoudt het antwoord. De specialisten bouwden hem in nachtelijke cycli, één afgebakende wijziging per cyclus, elk achter een poort van acht stappen met tests en onafhankelijke reviews.

De stand na die cycli: versie 1.9.0, 373 tests groen, twintig talen, geo-regels per land zodat de banner verschijnt waar de wet erom vraagt, een gehoste distributie met integriteits-hashes, en drie toegankelijkheidsrondes. De banner overleefde ook een licht-thema-herontwerp waarin elke kleurkeuze eerst een contrast van 4,5 op 1 moet halen voordat hij mee mag.

Dat lijstje is niet het interessante deel. Het interessante deel is dat er geen regel van mij 's nachts code voor nodig had. Het had mij 's ochtends nodig om nee te zeggen tegen releases.

De dienst eronder

Achter de banner zit het echte platform: een API, een scanner die je site bezoekt en rapporteert wat er in de browser van een bezoeker belandt, een consent-log als bewijsvoering, een worker, een scheduler, en Stripe-facturatie met een handtekening-geverifieerde webhook. Het spreekt TCF v2.3 en Consent Mode v2, de twee dialecten die het advertentie-ecosysteem verwacht. De testsuite staat vandaag op 403.

En hier is de zin die marketing normaal schrapt: dat hele platform draait nergens live. Niet omdat het stuk is. Omdat publiceren in dit systeem een aparte beslissing is, die van mij is, en die ik nog niet genomen heb.

De audit die twee kritieke gaten vond

Op 28 juli ging er een security-audit door het platform. Die vond twee kritieke problemen. Een publieke sleutel die admin-toegang gaf, en stored XSS in het dashboard: een gescande site kon script planten dat zou draaien onder de ogen van degene die de resultaten bekijkt.

Allebei het soort vondst waar producten aan eindigen als een klant ze eerder vindt. Allebei gefixt in één commit, bbd6077, en daarna geverifieerd tegen de code in plaats van tegen de belofte.

Waarom bestonden ze überhaupt, in een systeem met reviewpoorten op elke wijziging? Omdat poorten wijzigingen beoordelen, en deze gaten ontstonden in de naden ertussen. Een reviewer die elke nacht één afgebakende diff ziet, ziet niet het hele aanvalsoppervlak. Periodieke audits bestaan precies omdat nachtelijke reviews ze niet vervangen.

De poorten bewezen zichzelf één keer op een manier die ik niet leuk vond. Op een avond stond een afgebouwde feature klaar om te mergen terwijl beide onafhankelijke reviewers halverwege stierven, geveld door mijn maandelijkse spend-limiet. De regel hield stand: geen onafhankelijke review, geen merge. De feature wachtte. Autonomie houdt op bij de facturatiepagina, en ik heb besloten dat dat een feature is.

Het eerlijke scorebord

De herschreven positionering voor plainconsent.com staat in 34 lokale commits die nooit gepusht zijn. De live site toont nog de oude tekst. De betaalflow heeft nul echte klanten verwerkt, want hij staat niet aan.

Ik zou dat kunnen verzwijgen en je de testaantallen laten zien. Maar een bouwlog dat alleen winst logt is een advertentie. Het gat tussen "gebouwd" en "live" is waar dit systeem bewust een mens houdt, en op dit moment is die mens de bottleneck. Weten waar je bottleneck zit wint van doen alsof je er geen hebt.

Een bouwlog dat alleen winst logt is een advertentie.

Wie deed wat

De specialisten: de banner, het platform, de tests, de fix voor beide audit-bevindingen, en de nachtelijke discipline van één afgebakende wijziging achter één volledige poort. De audits en reviews: onafhankelijke agent-sessies die hard falen en merges blokkeren.

Ik: de prioriteiten, de nee's, de GO's, en elke beslissing die geld, klanten of het live internet raakt. Wie de score bijhoudt: dat is dezelfde verdeling als in hoe dit team mijn marketing draait, en dezelfde als in het migratieverhaal: productie is gesystematiseerd, oordeel niet.

De cijfers op één plek

Als je zelf met agents wilt bouwen

Geef elke wijziging een poort waar hij zich niet langs kan praten. Plan een periodieke audit die over wijzigingen heen kijkt, want je per-wijziging-reviews doen dat niet. En hou één stap die altijd menselijk is, en bewaak die, ook als jij daardoor het traagste onderdeel van je eigen systeem wordt.

Het product krijgt zijn lanceermoment, in de eigen volgorde: eerst bewijs, dan klanten. De veelgestelde vragen laten zien hoe deze werkwijze zich in de praktijk houdt. En kwam je voor de banner zelf: die staat op plainconsent.com, oude tekst en al.

---