Most consultants can't show you what they built last weekend.

There's a TikTok comedian named George Brett Olson who does a recurring bit called the MF Function: a fictional standing assembly where ethnic and cultural delegations negotiate slang, food, and culture trades. The Caucasian Caucus offers "scallywag" in exchange for "Mark Ass Buster." The Italian Delegation forms the Gabagoo Guild and bans pineapple on pizza. The Arab Delegation gets a permanent veto over raisins. The Auntie Council overrules a roast battle. Hundreds of videos. Tens of thousands of comments. The bit lives at mffunction.com.

On Sunday I built a fan-made government-records site for the bit, called the Multicultural Bureau of Records, at mbofr.com. When it was done I sent George an IG message with the link. He loved it, made a video about it, and we got thousands of views and comments in a day. The site auto-updates every six hours with new "communiqués" pulled from George's TikTok. There are 22 ratified accords filed as actual documents. Bureaucratic-formal, with mock signatures, ratified stamps, and a photo-traced cameo of George on the seal. The Pineapple Accords look like a real treaty. The On My Mama Accords come with a F Around and Find Out (FAFO) Clause as a ratified addendum.

Total build time: about two hours of actual work, spread across a weekend.

The pipeline is the thing worth talking about. yt-dlp pulls every video. Deepgram and Whisper transcribe them. Claude extracts the trades, accords, leases, and rulings as structured data. A static HTML site renders the whole archive: no framework, no build step, fast and cacheable. GitHub Actions runs the pipeline on a 6-hour cron. A second workflow deploys human pushes to Vercel.

$10/month for Vercel hosting. $11 a year for the domain. Nothing else.

I built it because the bit is funny and the joke begged for a public-records parody. I wrote it up because the speed is the point.

What modern build velocity actually looks like

Most consulting case studies are about engagements that took six months. The headline metric is "saved $400K annually" or "reduced cycle time by 60%." Those are good metrics. They are also lagging indicators of a process that started with three months of meetings and a forty-page requirements document.

The MBofR build started with a conversation. "There should be a public ledger for this." Two hours later, the first version was live. The DM to George went out the same day. By the next, his video about it was up and the site was pulling thousands of views and comments. Nobody asked for a requirements document. Nobody sat through a kickoff meeting.

The build was the conversation.

This is what working with an LLM agent in the loop actually looks like in 2026. The bottleneck moved. It used to be the time between idea and working code. Now it's the time between idea and decision to build. The build itself takes hours, sometimes minutes. The friction is in the human deciding what to point the agent at.

If you've worked with a consulting firm in the last decade, you've been trained to expect a certain rhythm. Discovery. Planning. Build. Deploy. Each phase takes weeks. Each handoff loses information. Each meeting decides what the next meeting will be about. The MBofR site is what happens when you remove all of that and let one person with conviction and an LLM run the loop end to end.

I never asked George for anything

Notice what isn't in this story.

George never sat for a kickoff call. He didn't hand me a list of his videos, a transcript archive, a content calendar, a "data export." He didn't approve a scope of work. He didn't see the site until I sent him the link after it was already live.

Every byte of input was already public. TikTok serves up the videos. yt-dlp downloads them. Deepgram and Whisper transcribe them. Claude reads the transcripts and extracts the structured shape: who's in the assembly, what got traded, which accords ratified, which clauses survived. The data wasn't given to me. I went and got it.

This is the part most people still get wrong about AI consulting in 2026. The default assumption is: the client has the data, the client gives us the data, the engagement bottlenecks on data handoff. That model is mostly obsolete. For a huge fraction of the work that gets billed as consulting, the inputs already exist publicly: in product reviews, regulatory filings, court records, investor decks, podcast transcripts, support forums, partner sites, the client's own marketing. We just go get them.

When we sit down with a firm for the first time, we've usually already pulled, organized, and ingested most of what's publicly knowable about their business, their competitors, their regulatory environment, and their customers. The kickoff isn't where we start collecting data. It's where we show what we already found.

That's the bottleneck people don't see until it's gone. Not the build. The build is fast. The wait-for-data is what used to take months, and most of the time, the wait was for things we could have gone and gotten ourselves.

The reason I'm publishing this

It isn't because the site is impressive. It isn't, particularly. It's a parody fan archive for a comedy bit. The reason I'm publishing it is because most people working in AI consulting still build like it's 2019. Long timelines. Big teams. Deliverables instead of working software. The MBofR build is a small, vivid example of the alternative.

Not every problem fits a weekend. But many more problems do than the consulting industry's calendar admits.

The site is a parody. The speed is not. Tell us what you'd build if "gathering requirements" wasn't a phase.