Building a Paid Product With an AI Team of 18 Agents: The PlainConsent Build Log

My marketing team was built to produce marketing. Somewhere this spring, it started producing software.

PlainConsent is a cookie consent platform: a banner your visitors see, and a service underneath that scans sites, logs consent and handles billing. It is the first paid product to come out of the same agent system that writes my content and checks my brand. This is the build log, with the parts that usually get cut: the two critical security holes, the review that died on a spend limit, and what is honestly not live yet.

What is live, what is not

That table is the whole philosophy in four rows. Everything gets built and tested in the open, and nothing goes live until a human decides it does.

Why a cookie banner, of all things

Because I sell a way of working, and a way of working needs proof before it deserves customers. Dogfood first: the system had to run my own marketing for a year before I let it near a product. The same order applies here. First the product has to work under my own rules, then it may be sold.

A consent banner is also a sharper test than it looks. It sits on other people's websites, in front of other people's visitors, under European privacy law. Boring category, zero tolerance for sloppiness. Exactly the kind of thing you want built by a process that cannot skip its own reviews.

The banner came first

The visible half is a single script: block by default, ask first, remember the answer. The agents built it in nightly cycles, one bounded change per cycle, each behind an eight-step gate of tests and independent reviews.

The current state after those cycles: version 1.9.0, 373 tests green, twenty languages, geo rules per country so the banner shows where the law requires it, a hosted distribution with integrity hashes, and three accessibility passes. The banner also survived a light-theme redesign in which every color decision has to earn a 4.5 to 1 contrast ratio before it ships.

None of that list is the interesting part. The interesting part is that no line of it required me to write code at night. It required me to say no to releases in the morning.

The service underneath

Behind the banner sits the actual platform: an API, a scanner that visits your site and reports what it drops in a visitor's browser, a consent log for audit evidence, a worker, a scheduler, and Stripe billing with a signature-verified webhook. It speaks TCF v2.3 and Consent Mode v2, the two dialects the ad ecosystem expects. The test suite stands at 403 today.

And here is the sentence marketing would normally delete: that entire platform runs nowhere live. Not because it is broken. Because publishing is a separate decision in this system, it is mine, and I have not made it yet.

The audit that found two critical holes

On July 28, a security audit went through the platform. It found two critical problems. A public key that gave admin access, and stored XSS in the dashboard: a scanned site could plant script that would run in the eyes of the person reviewing it.

Both are the kind of finding that ends products when a customer finds them first. Both were fixed in one commit, bbd6077, and then verified against the code rather than against the promise.

Why did they exist at all, in a system with review gates on every change? Because gates review changes, and these were born in the seams between changes. A reviewer who sees one bounded diff per night does not see the whole attack surface. Periodic audits exist precisely because nightly reviews cannot replace them.

The gates did prove themselves once, in a way I did not enjoy. One evening a finished feature stood ready to merge while both independent reviewers died halfway, killed by my monthly account spend limit. The rule held: no independent review, no merge. The feature waited. Autonomy ends at the billing page, and I have decided that is a feature.

The honest scoreboard

The rewritten positioning for plainconsent.com sits in 34 local commits that have never been pushed. The live site still shows the old copy. The paid flow has processed zero real customers, because it is not switched on.

I could hide that and show you the test counts. But a build log that only logs wins is an ad. The gap between "built" and "live" is where this system keeps a human, on purpose, and right now that human is the bottleneck. Knowing where your bottleneck is beats pretending you have none.

A build log that only logs wins is an ad.

Who did what

The agents: the banner, the platform, the tests, the fix for both audit findings, and the nightly discipline of one bounded change behind one full gate. The audits and reviews: independent agent sessions that fail loudly and block merges.

Me: priorities, the no's, the go's, and every decision that touches money, customers or the live internet. If you are keeping score, that is the same split as in how this team runs my marketing, and the same one described in the migration story: production is systematized, judgment is not.

The numbers, in one place

If you want to build with agents

Give every change a gate it cannot talk its way past. Plan a periodic audit that looks across changes, because your per-change reviews will not. And keep one step that is always human, then guard it, even when it makes you the slowest part of your own system.

The product will get its launch moment, in its own order: proof first, customers second. The FAQ covers how this way of working holds up in practice. And if the banner is the part you came for: it is at plainconsent.com, old copy and all.

---