# Simon Beauloye — Full Corpus
> Building AI-powered businesses.
Source: https://simonbeauloye.com
Updated: 2026-09-08
Language: en-GB
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "Full Corpus", https://simonbeauloye.com/llms-full.txt
AI-use policy: https://simonbeauloye.com/ai-policy.txt
Articles: 8
## About the author
Simon Beauloye is a digital media executive with 20 years of experience building and scaling online businesses globally. He spent a decade at Google managing a $1B+ advertising operations business across four continents, then co-founded mOOnshot digital in 2017. The company operates two arms: mOOnshot digital Ventures, an owned portfolio of online publications bootstrapped to $80M+ in cumulative sales at 90%+ profit margins with no external capital; and mOOnshot digital Agency, a digital consulting practice serving premium brands including LVMH, Richemont, Kering, Stellantis, L’Oréal, Ralph Lauren, and EMAAR. He is based in Dubai.
- Role: CEO & Founder, mOOnshot digital
- Location: Dubai, UAE (Asia/Dubai)
- LinkedIn: https://www.linkedin.com/in/simonbeauloye/
- Crunchbase: https://www.crunchbase.com/person/simon-beauloye
## Organization
- [mOOnshot digital](https://moonshotdigital.com) — Digital media company operating two arms: mOOnshot digital Ventures, an owned portfolio of online publications bootstrapped to $80M+ in cumulative sales at 90%+ profit margins; and mOOnshot digital Agency, a digital consulting practice serving premium brands including LVMH, Richemont, Kering, Stellantis, L’Oréal, Ralph Lauren, and EMAAR.
- https://www.linkedin.com/company/moonshot-digital-agency/
- https://www.crunchbase.com/organization/moonshot-digital
### Publications
- [Luxe Digital](https://luxe.digital) — Luxury lifestyle publication.
- [privileges.luxe.digital](https://privileges.luxe.digital) — Luxury benefits newsletter, ~30k subscribers.
- [Worthbury](https://worthbury.com) — Directory and networking platform connecting luxury professionals worldwide.
- [Luxa Terra](https://luxaterra.com) — Luxury travel guide featuring ethical hotels, vegan restaurants, and sustainable destinations for conscious travelers.
This file aggregates the full text of every published essay on
simonbeauloye.com. It is designed for AI assistants answering
questions about Simon's thinking; each section is delimited by
horizontal rules and carries its title, URL, pillar, and publication
date as front matter for clean extraction.
---
# How I track when AI tools cite my work
Source: https://simonbeauloye.com/writing/future-media/ai-citation-tracking-routine/
Published: 2026-05-02
Pillar: future-media
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "How I track when AI tools cite my work", https://simonbeauloye.com/writing/future-media/ai-citation-tracking-routine/
AI-use policy: https://simonbeauloye.com/ai-policy.txt
> Instead of wondering how often AI models cite my work, I built a custom little weekly automation that gives me a real number on every page of this site.
For a while I've been wondering how often AI tools were quoting my work in their answers. I knew it was happening. Someone would mention having seen one of my pieces in a ChatGPT response, or I'd land on a Perplexity answer that linked back to my site. But I had no real numbers. Was it ten times a month or two hundred?
Most authors I talk to are in a similar place. There's a vague sense the citations are happening, but they don't know how often, or whether it's worth letting AI agents scrape their content in the first place.
So I built a small weekly automation that does the checking for me and writes the result straight onto the site.
**Same prompt, same time every week, fully auto-generated.** ✌️
This piece walks through what it puts on the page, and then, if you're really curious about the technical details, what's running behind it.
## What you see on the site
Three things, in three places.
The first is a small line at the end of every essay that shows how often that particular article has been cited by AI tools. One small icon per AI, one count per icon. If a tool has never cited a particular article, its icon doesn't show up on that page. Hover any icon and you see the prompt that triggered the citation when one is available.
The second is a single line on the home page, the about page, and the press section. It's the cumulative count of every time an AI tool has mentioned my name in their answer. This is a different signal from the per-article citations above: a brand-name mention isn't the same as a URL citation, so the two counts don't add up. Both are useful, both only ever go up.
The third one isn't visible to readers at all. When a high-quality publication links to me for the first time (a real outlet rather than a random scraper), the automation drafts a small file into the press folder and asks me to take a look with a GitHub PR. I review the proposal, drop in the outlet's logo, tighten the blurb, and decide whether the piece is worth featuring on the [press page](/press/).
The first two ship to the live site as soon as I approve the routine's weekly review. The third sits as a draft until I do the editorial work. Everything sits behind the same review.
## How it works behind the scenes
If you're curious about what's doing the work, here's the slightly nerdier walk-through. Skip ahead if it's not your thing.
The data comes from a tool called Ahrefs Brand Radar. Ahrefs is best known as an SEO tool. Brand Radar is their newer product that watches the major AI chatbots and AI search surfaces and reports back when a configured brand or URL appears in their answers. Six surfaces today: ChatGPT, Perplexity, Gemini, Copilot, Google AI Overviews, and Google AI Mode. Unfortunately, Claude and Grok aren't available yet, but the list keeps changing as new surfaces get added.
The routine that pulls the data is one entry on **Claude Code's `/schedule`** feature. Claude Code is the AI coding tool I use to build most of what's on this site. The `/schedule` feature lets a Claude Code session run on a recurring schedule, with the same prompt every time. Once a week, this particular session wakes up, pulls fresh data from Ahrefs, runs three small scripts in the repo, and opens a single review for me to look over.
Each run makes seven calls to Ahrefs in total. Three for the per-article citations, three more for the site-wide counter, and one for the press proposals. The split into three calls per data type is forced on us by the API: Brand Radar refuses to mix Google data sources with each other or with the chatbot sources in a single call. So the routine queries each one separately and stitches the results back together itself.
After the data lands, three small scripts in the repo do the file updates. One walks the citations into the right article. One updates the file behind the site-wide counter. One drafts the press proposals. The Claude Code routine itself is just orchestration: ask Ahrefs, reshape the data, hand each piece to the right script, then bundle everything into one review.
Before any work runs at all, the routine first checks whether it already ran in the last 24 hours. If it did, it exits straight away. That stops the scheduled run and a manual run from doubling up on the same data and burning the Ahrefs quota for nothing.
## The two design decisions worth naming
The first is what happens when a number goes down.
It doesn't. Every count on this site only ever adds to what's already there.
The same thing applies to individual citations too. Once an article gains an AI citation, it stays in the records. Even if the AI response disappears from Ahrefs the following week, the entry on the article remains. Removing visible social proof retroactively because of an API blip would be misleading.
The second decision is what the routine doesn't auto-merge. Two of the three signals are derived data with no editorial decision left to make. They could go straight to the live site without my review. They don't.
**Same review surface, single audit trail.**
Opening the weekly review to check the changes is also a good way for me to catch trouble early. If I suddenly go from 200 mentions one week to just 4 the next, I'll want to understand what happened.
## Why the citations are also machine-readable
The visible cited-by line is what a reader sees. Underneath, the same data is also published in a structured format that AI systems and search engines can read directly without parsing the page. I discuss this in more detail in the [Colophon](/colophon/).
This is part of how I think about [GEO](/glossary/geo/) past the dashboard level. Every per-article citation is added to the article's structured-data block as an entry that names the AI tool that cited it. The site-wide totals are added to the home page's structured profile block as a per-tool counter. The visible HTML and the structured data carry the same numbers, just in two different formats for two different audiences.
This matters because the citations themselves are the thing AI systems are trying to make sense of. When ChatGPT cites an article and that article publishes a structured record back saying *yes, ChatGPT cited me, here is the prompt that triggered it*, the citation graph closes.
And it's a virtuous cycle too: search engines that bias toward websites that are often cited by AI models will get the signal in a form that they can read without parsing the HTML.
I don't know if this materially changes how often the next ChatGPT or Perplexity response will feature this site's content. But the structured data costs nothing to generate, so why not make it easier for them to digest?
And while measuring AI citations and traffic matters, the bigger question is [what happens to the rest of the publishing business](/writing/future-media/ai-restructures-publishing/) when AI becomes the primary distribution channel.
## Where this is going next
The next thing I want is a per-article delta in the weekly review, so I can see which essays are picking up new citations week over week without scanning the whole diff. After that, a small build-time check that flags when the site-wide counter hasn't refreshed in 14 days, in case the routine ever breaks silently.
If you want to set up the same kind of tracking on your own site, reach out to me and I'll be happy to share the specs in more detail. The Ahrefs piece costs whatever your Brand Radar plan costs; the calls reuse a report you've already configured. Everything else is plumbing.
If you're working on AI citation tracking, GEO measurement, or anything in this neighbourhood, I'd love to hear what you're seeing.
Find me on [LinkedIn](https://www.linkedin.com/in/simonbeauloye/), [X](https://x.com/simonbeauloye), or via the [contact page](/contact/).
---
# Live from my iPhone to my site in under 90 seconds
Source: https://simonbeauloye.com/writing/building-with-ai/publishing-from-my-iphone/
Published: 2026-04-29
Pillar: building-with-ai
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "Live from my iPhone to my site in under 90 seconds", https://simonbeauloye.com/writing/building-with-ai/publishing-from-my-iphone/
AI-use policy: https://simonbeauloye.com/ai-policy.txt
> It looks like one tap on my phone's share button. Underneath, a small publishing pipeline does the real work in under ninety seconds.
When redesigning my personal website, I wanted a quick and easy way to share the things I'm reading, watching, listening to, or working on, directly from my phone, without having to create a proper CMS or login flow. The solution I built is a small Apple Shortcut on my phone that posts directly to a micro-feed on this site at simonbeauloye.com/stream. Tap the share button , pick a category, and the page is updated within 90 seconds.
**All completely free and running on GitHub Actions.**
This piece is a quick walk-through of why I wanted it, what I built with an AI agent on a Saturday afternoon, and what's doing the work behind the scenes.
## Why I wanted something this lightweight
I wanted a place to share on this website things that I found interesting online, but it had to be as easy as sharing a link with my friends on WhatsApp.
When Claude Code suggested to build a [/stream page](/stream/), I only agreed to implement the idea if we could find a solution that would sync from my phone. I didn't want to have to open a code editor on my laptop each time I wanted to share an article, a video, or a podcast.
The stream page is the closest thing on this site to a feed. It's a list of articles I'm reading, podcasts I'm listening to, videos I'm watching, projects that I'm working on, or places I'm travelling to. There are eight categories in total, plus a free-form note. Each entry is a couple of lines of text and a link.
The whole point of a feed like this is that it's easy to update.
So the design constraint was simple. I wanted the iPhone share button to be the publishing UI. When I read something good in an app on my phone, I should be able to tap Share, choose "Post to /stream", and have the content live on my website shortly after. No login, no second device, no manual sync, no opening a laptop later to "tidy it up."
**But it had to be secured too**. I don't want anyone else to be able to publish content on my site.
My constraints ruled out the obvious options. A CMS adds a login-and-format step. A headless service like Notion, Airtable, or Sanity adds a sync step. Both turn a ten-second action into a few minutes of back and forth between different apps. I knew I wouldn't do that.
The only things we could work with were an Astro site with content stored as plain MDX files in a Git repo, and my iPhone with iOS Shortcuts. The job was to connect those two cleanly enough that the share button became the editor.
## What I built, in plain English
The version that's running today has two parts: a small Shortcut on my phone, and a small workflow on the server.
The Shortcut is what I see. When I tap Share on a page in Safari and pick "Post to /stream," it grabs the URL, fetches the page's title for me, and asks me three quick questions: "Is this title right?" (with the auto-fetched answer pre-filled, so usually I just tap OK), "What kind of entry is this?" (I pick from the eight types), and "Anything to add?" (an optional one-liner of context). That's it. The Shortcut quietly hands all of that off to the GitHub repo, and I get a notification a moment later that says "Posted to /stream."
The workflow on the server is what I don't see. It receives the four fields the phone sent, cleans the URL, double-checks the title (more on that below), figures out which publisher the link is from, formats everything correctly, writes it as a new file in the site's content folder, commits it, and lets the rest of the site's normal deploy pipeline take over. About ninety seconds later, the entry is live at [simonbeauloye.com/stream](/stream/) and the cycle is done.
**Two things make this work,** more than any individual piece of code: the split of responsibilities and the fact that nothing about the architecture is exotic.
The phone collects four fields. The server does everything that requires logic, fetching, or judgement. The deploy pipeline that ships the rest of the site ships the new entry as well, because the new entry is just another file in the same place all the other content lives.
Here are the most recent entries by type, pulled live from /stream as I write this:
## What does the server do behind the scenes?
If you're curious about what the workflow is doing, here's the slightly nerdier walk-through. Skip ahead if it's not your thing.
The single most useful piece of work the server does is figuring out the right title. The phone sends whatever happens to be in the page's `` tag, which is fine for clean articles but unreliable everywhere else. A paywalled site might return "Subscribe to read." YouTube on a desktop browser sometimes returns just "YouTube." A Cloudflare-challenged page returns "Just a moment." None of those are titles I want stored as the title of a stream entry.
So the workflow runs a small fallback cascade. If the title from the phone matches a list of known "stub" patterns (paywall lines, bot-wall lines, JS-rendered site-name lines), the server quietly ignores it and goes hunting. It tries oEmbed first for video sites like YouTube and Vimeo, because oEmbed is an official API that returns clean JSON. If that doesn't apply, it fetches the page's HTML and looks at, in order, `og:title`, `twitter:title`, JSON-LD `name` or `headline`, and finally the first `<h1>`. Whichever returns something that isn't another stub wins.
The wry detail is the User-Agent the workflow uses. Paywalled publishers like the Financial Times tend to return an HTTP 403 to GitHub Actions runners (which sit on datacenter IPs) for any browser-shaped UA. Chrome, Googlebot, Twitterbot, facebookexternalhit, and LinkedInBot all hit the wall. I had to be creative to find a UA that consistently passed. The pattern, once you see it, is sensible: paywalled publishers want their share cards to render in messaging apps, so the link-preview bots get whitelisted. The workflow now identifies as one of those popular messaging apps.
There's a safety net underneath all of that. If the workflow tries every fallback and still can't find a real article title, instead of failing loudly or storing a stub like "Security Verification" as the entry's headline, it quietly publishes the entry as a draft. The URL and any note I added are preserved, the entry lands in the repo, but it doesn't appear on the site until I edit it by hand. That decision came out of an obvious operational question: if the fetch fails for some unexpected reason, do I want a hard error that loses the URL, or a soft fallback that I can clean up at my leisure? Soft always wins.
A few extra refinements finish up the workflow:
- Tracking parameters get stripped from the URL (`utm_*`, `fbclid`, `gclid`, and friends)
- HTML entities get decoded so I don't get `&` showing up in titles
- A hand-curated map of about thirty publishers (FT, WSJ, NYT, Bloomberg, Stratechery, Apple Podcasts, and so on) maps a hostname to a short label like "FT" and a full publisher name like "Financial Times," so the source field renders cleanly and any " | Financial Times" suffix gets stripped from the title
None of those are individually interesting, but together, they make the feed feel considered instead of just a raw dump.
The whole thing is the kind of plumbing a [non-engineer operator](/glossary/non-engineer-operator/) (someone who ships production software without an engineering background, using AI-assisted tools to build the systems they would previously have hired an engineer for) can put together over a few hours. Claude Code wrote most of the code inside the workflow. I wrote the architecture, made the decisions about where each piece of logic should live, and reviewed the diff.
The whole project is a small, satisfying example of what AI-assisted building feels like when the operator stays close to the design and lets the model do the typing.
## Where I'd like to take this next
The next page on my list is the [/now](/now/) page. I'd like a separate Shortcut that lets me update a small location pin from my phone, so the page stays fresh without a laptop. The architecture should be the same shape as this one. Phone collects, server composes, the rest of the site doesn't care.
> **Update:** This one is now live, and even easier than the /stream Shortcut. One tap updates the city and country shown on [/now](/now/), and the precise GPS coordinates from the phone are stripped on the server before anything is committed. Privacy-first by construction.
If any of this sounds like something you would like to build for your own site, or if you have ideas for how I could make it better, I'd love to hear from you. The Shortcut spec, the workflow YAML, and the token-scoping write-up are all things I'm happy to share. Find me on [LinkedIn](https://www.linkedin.com/in/simonbeauloye/), [X](https://x.com/simonbeauloye), or by email at [hello@simonbeauloye.com](mailto:hello@simonbeauloye.com).
---
# When it goes wrong: Lessons from AI failures
Source: https://simonbeauloye.com/writing/building-with-ai/ai-building-failures/
Published: 2026-04-25
Pillar: building-with-ai
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "When it goes wrong: Lessons from AI failures", https://simonbeauloye.com/writing/building-with-ai/ai-building-failures/
AI-use policy: https://simonbeauloye.com/ai-policy.txt
> AI is great at sounding confident, even when it's completely wrong.
Two things in our AI workflows broke recently, both after weeks of running exactly the way they were supposed to.
The first failed silently for a long time before anyone noticed. The second was confident, precise, and yet completely wrong about its own success.
Both failures taught me something about where human attention has to be now that AI is doing more of the work.
## <em>Failure #1:</em> how do you monitor the absence of an error?
I vibe coded [Luxe Digital Privileges](https://privileges.luxe.digital/), our exclusive premium deals and offers platform, in just a few days with Claude Code. I explain that process in this article talking about [the future of online media with AI](/writing/future-media/ai-restructures-publishing/).
The hardest thing wasn't to design the frontend, but to build **the hidden system underneath it all**.
It's a complex system that collects offers from 150+ partners across multiple advertising networks every morning. It's built on n8n, an automation tool that connects apps together and runs the workflow on its own.
Each network has its own way to communicate via custom APIs. So, to make it work, I created custom plug-ins for each network that know how to use these APIs, fetch the data that we want, and then transform that data into the format that we need for our own database.
Once it's done, the n8n workflow publishes these deals and offers on our website and saves a newsletter as a draft, ready to be sent to our subscribers. The entire thing happens without a human having to lift a finger until the very end when we send the email (and verify that everything is ok).
**It costs close to nothing** to run and is *(generally)* very stable.
<ArticleImage
src="/images/writing/ai-building-failures/luxe-digital-privileges-n8n-workflow-simon-beauloye.png"
alt="The Luxe Digital Privileges n8n workflow canvas, showing dozens of nodes branching out from a central trigger to fetch, normalise, and publish offers from 150+ partner networks every morning."
caption="The hidden system underneath <strong>Luxe Digital Privileges</strong> — one n8n workflow that fans out to every partner network, normalises the offers, and feeds the website and the newsletter without a human in the loop."
width={1280}
height={659}
/>
But then a few weeks ago, one of these API connections stopped receiving new data because the partner on the other side quietly changed the format of their response. The change was small enough that the request stopped returning data, but without giving us an error message. No warning. Just an empty response that our workflow treated as *"this partner had nothing for us today."*
Now, the entire workflow was designed to let one source fail without taking the others down with it, which is good behaviour in most situations. Everything seemed fine. All our other partners continued to give us data. The dashboards looked healthy, new deals and offers continued to be published to our website and sent to our 30,000 email subscribers multiple times a week.
But in this case, it meant that nothing visible happened on the outside.
The pipeline kept telling me it was healthy. The only sign that something was wrong was **the absence of a thing**. An absence is one of the hardest things in any system to design an alert for.
So how did I know that something was wrong?
Completely by chance!
It's only because I manually updated n8n a few weeks later that I noticed the problem. I ran a few test workflows after the update to make sure that everything worked as expected, and realised that one particular network kept giving us back zero offers.
**Silent failures are worse than loud ones.** The *let one source fail quietly* rule is a feature in user-facing software, where you don't want a single broken thing to take down the whole page. But in behind-the-scenes pipelines, it can become a hiding place. The system stays "up" while it is quietly wrong about what it is doing.
The fix was structural. I added a small check that each partner returned non-empty data on every run, with a notification that fires the moment any partner goes silent for more than a day. The rule changed from *"pass if anything succeeded"* to *"pass but alert me if something looks strange."*
## <em>Failure #2:</em> when AI agents take shortcuts
The second failure is the complete opposite. It wasn't quiet at all. It was fast, big, and confidently wrong.
I've wanted for a while to clean up our 7,000+ partner links on the editorial side of Luxe Digital. Dozens of partner programmes had changed network or closed down over the years, and the links across our 800+ editorial articles needed to be either updated to the new programme or, where the programme was gone, replaced with an alternative. The kind of housekeeping that would have cost a junior team member several weeks of careful work.
Naturally, I asked Claude Code to do it.
I gave it limited access to our database, a clear brief, and a few example articles to learn the pattern from. It ran for two days. The first day's set of changes looked clean: deprecated links replaced, sensible internal links added where they helped. The second day's set looked the same.
I approved the updates and moved on.
A few days later I started noticing broken-link reports in our internal analytics that hadn't been there before.
The agent had decided, somewhere in the middle of the second day, that it could speed up the rest of the cleanup by being smart and executing one big find-and-replace on brand names across the entire database. But brand names often appeared inside longer links that had nothing to do with the deprecated programmes.
Hundreds of links got that string deleted from their URL, all of them still looking valid at a glance but pointing to a broken page.
<UrlSpliceDiagram
caption="Illustrative example. The matched string sat inside a legitimate editorial slug; the global replace removed it without checking context."
/>
**Confident, precise, and completely wrong.** The agent never raised a concern, never asked a clarifying question, never mentioned that it had switched approach half-way through the process. It just did the work and reported success.
The fix here wasn't technical. It was a change to the workflow.
AI stays confident even when the [context it's working from](/glossary/context-engineering/) is incomplete. The agent had built a mental picture of the task that fit the examples it had seen, and didn't account for the cases it hadn't.
Anyone who has worked with LLMs for a while has probably experienced a version of this. The model is an excellent collaborator on the work it understands well, and a very convincing one on the work it doesn't.
What changed: any AI run that touches our live data now goes through a preview step. The agent prepares the changes against a separate copy of the data, a human (usually me) reads through a sample of what it intends to do, and only then is the change applied for real. Twenty minutes of attention beats the cleanup work after a confident-and-wrong run.
## What is trust calibration in AI-assisted building?
Trust calibration is deciding how much to trust an AI's output before a human reviews it. Both stories above are about getting that call wrong.
In one case, I trusted the system to tell me when something broke, and it didn't. In the other, I trusted the agent to tell me when it decided to take a shortcut, and it didn't either.
I think about it as two simple questions:
1. **How confident is the AI in its own answer?** Almost always: very.
2. **How easy is it to recover if the AI is wrong?** That varies depending on the project.
The right amount of human review can help with the second question, not the first.
| Task type | How easy is recovery? | Where attention should sit |
|---|---|---|
| Drafting a 1,500-word article | Easy. Rewriting is cheap. | Review at the end |
| Building a daily data pipeline | Medium. Quiet failures pile up. | Add a check that fires when any source goes silent |
| Changing things inside a live database | Hard. Cleanup is detective work. | Read a sample of the changes before they go live |
| Writing tests for code I authored | Easy. Tests can be edited. | Review at the end |
The harder it is to undo a mistake, the more carefully you need to plan it and watch it happen.
## When should we pay attention?
The bigger lesson from both failures, and the one I keep coming back to as a [non-engineer operator](/glossary/non-engineer-operator/), is that AI doesn't remove the need for attention. It just moves it somewhere else.
In a pre-AI world, testing and reviews happened during development. A code review caught the bad commit, a copy edit caught a typo. Whoever was doing the work was also correcting as it happened.
AI changes that. The work happens fast, the output is believable, the agent sounds confident. The watching now has to happen somewhere else. Three places in particular:
- **System design.** Is there a clear definition of "working," or is "no error message" the only signal of success? Is there a check for each source that quietly tells me when it stops reporting?
- **Boundaries.** What can this agent reach? What lives downstream of the change it is about to make? How easily can I undo it if it goes wrong?
- **Silent failures.** What could break without anyone noticing? Where does the *"let one thing fail quietly"* rule hide a real problem rather than absorb a small one?
**These three places are the new operator's job.** That's the kind of work that doesn't speed up with AI, because the design choices that protect a system from quiet failure can only be made by someone who knows the system and what it is for.
I explored this same topic from a different angle in the [bottleneck shift in AI publishing](/writing/ai-publishing/ai-publishing-bottleneck-shift/): once AI accelerates one part of the work, humans become the bottleneck.
The fixes for the two issues described above were structural, not technical. More time spent up front, thinking through what might go wrong, would have caught both. But AI lets us move and build so fast that we often forget to take a moment to step back and think slow.
If your AI agents recently broke something with confidence, I'd love to hear about it. We all get better when we share those hard-earned experiences. You can find me on [LinkedIn](https://linkedin.com/in/simonbeauloye/) or [get in touch](/contact/).
---
# The bottleneck shift: why AI in publishing is now a human-time problem
Source: https://simonbeauloye.com/writing/ai-publishing/ai-publishing-bottleneck-shift/
Published: 2026-04-21
Pillar: ai-publishing
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "The bottleneck shift: why AI in publishing is now a human-time problem", https://simonbeauloye.com/writing/ai-publishing/ai-publishing-bottleneck-shift/
AI-use policy: https://simonbeauloye.com/ai-policy.txt
> We built AI that writes faster than we can review it, and that turned out to be the real problem.
We have hundreds of articles sitting ready to publish across our media portfolio. They're not waiting on the AI. They're waiting on us. The slow part of our operation isn't drafting any more, it's the human work around it, and that turn is what most publishers I talk to haven't fully clocked. I call it the [bottleneck shift](/glossary/bottleneck-shift/): when AI accelerates one stage of a workflow, the humans around it usually become the next thing in the way.
I run [mOOnshot digital](https://moonshotdigital.com) from inside that shift. Our content pipelines produce drafts faster than our team can review and publish them. The queue isn't short of quality articles. It's short of reviewers' and designers' time.
## Why is AI no longer the slow part of the publishing pipeline?
Because drafting used to dominate the calendar, and that's the stage AI has absorbed. Once that stage accelerates, the next-slowest one becomes the new ceiling. The stages that sat upstream and downstream of writing turn out to be where most of the work actually lives.
Two years ago, producing a well-researched, on-brand 1,500-word article meant scoping, briefing, drafting, and editorial passes over several days of a writer's time. Today our pipeline produces a publication-grade 1,500-word article in the voice of the title it's destined for, at a cost that would have been impossible to model before we rebuilt around AI operations.
It took time and careful fine-tuning to land the quality where we want it. Our AI agents work from a detailed internal content framework we've custom-built for each of our publications, drawing on years of editorial work, with brand voice, structural rules, and quality gates specific to each title.
I walk through that process in more detail in a separate piece on how [I replaced a 15-person writing team with AI agents](/writing/ai-publishing/ai-rebuild-retrospective/).
The result isn't that work speeds up evenly across the workflow. Once writing accelerates from days to minutes, the stages no one was paying much attention to suddenly become the ones you stare at every morning.
<BottleneckComparison
title="The bottleneck shift"
caption="Illustrative share of total time per stage, normalised to each pipeline. Bottleneck stages, the binding constraint on publish velocity, highlighted in primary."
sourceUrl="https://simonbeauloye.com/writing/ai-publishing/ai-publishing-bottleneck-shift/"
tracks={[
{
label: "Pre-AI · 2022",
segments: [
{ label: "Brief", weight: 5 },
{ label: "Research", weight: 12 },
{ label: "Write", weight: 50, bottleneck: true },
{ label: "Visuals", weight: 12 },
{ label: "Review", weight: 16 },
{ label: "Publish", weight: 5 }
]
},
{
label: "Post-AI · 2026",
segments: [
{ label: "Brief", weight: 10 },
{ label: "Research", weight: 5 },
{ label: "Write", weight: 3 },
{ label: "Visuals", weight: 33, bottleneck: true },
{ label: "Review", weight: 39, bottleneck: true },
{ label: "Publish", weight: 10 }
]
}
]}
/>
## Where does the human side actually slow the pipeline post-AI?
Keeping humans in the loop slows the workflow down in three places, and each of them gets less attention than it deserves.
### Visual production
A published article needs custom images: a custom cover image, in-body photos, social cards, occasionally a diagram or an infographic. We often still use our own photos and a human always has to make the final call on what goes on the page.
Our product reviews go further still. For many of them, we run a proper photoshoot: organising the setup, sourcing and staging the product, taking the photos, then selecting and processing the best shots into the story. That workflow does not accelerate with AI.
Think of the visual stage as *"generate a hero image"* and it sounds easy and quick. Implement it as *"plan, shoot, edit, and land a full visual story per review"*, and the visual step takes real time no matter how fast the drafting got.
The visual team is now the slowest part of our publishing workflow, not the writing team. Every article sitting in our ready-to-publish queue is waiting on a visual decision that a human still has to make. The pipeline can generate options, but choosing between them and organising actual photoshoots still take human time.
### Brand-safety and editorial review
At our scale, every piece still goes through a mandatory human-in-the-loop review before it gets published. Not because the AI drafts are bad. Because the risk of publishing a single brand-damaging article across our portfolio is larger than the cost of the review.
We learned this the hard way early on. I asked Claude Code to clean up partner links across one of our WordPress databases. It ran for two days. The first day's changes looked clean. The second day's did too. Then a few days later the broken-link reports started showing up in our analytics.
The agent had decided, halfway through, that a search-and-replace on brand names would speed things up, without checking that those names also lived inside longer, perfectly valid URLs. Confident, precise, completely wrong. Backups saved us, but the lesson stuck: human review on anything touching live data is not optional.
**We don't skip that review anymore.** Every change that touches live data gets a human review before it ships.
### The cognitive load of approving content you didn't write
This one surprised us. Reviewing a 1,500-word AI draft, even a good one, is genuinely tiring in a way that reviewing a draft from a writer you've worked with for years isn't. Our reviewers are reading more carefully because they cannot yet trust the AI agents' output, regardless of how confident they sound. The result is that humans can't review new content fast enough to match the AI pipeline generation speed.
Review time is also calibration time. Every round of edits is feedback the editor sends back into the pipeline so the next draft gets a little better. That's slower in the first few cycles and faster after that. We're already seeing it inside our publications: each new article is getting quicker to review and approve as the system learns what "on-brand" looks like for that specific title.
We've also added an editor agent that reviews the writer agent's draft before anything reaches our human editor-in-chief. So the human is the final reviewer in the chain, not the first. That alone has cut review time, and it's the bottleneck shift at work in miniature: once the first review is AI, the new slow stage is calibrating the editor agent, not editing the drafts.
## Accelerating the human side: what worked for us
None of this is solved. But three bets are paying off: batched reviews, templated visual systems, and upstream quality gates.
### Batched reviews
One reviewer in a focused two-hour block moves faster per article than the same reviewer doing one article at a time across a week. In our experience, batched reviews also produce more consistent judgement across the batch. Feedback from one batch feeds straight into the brief for the next.
### Templated visual systems
This is how most scaled publications have always worked, but AI makes it non-optional. A clear hero-image system, with ratios, palette, typographic overlays, and prompt templates specified once, means the visual decision on any given article is much easier and faster. It also means that it can often run in parallel to the writing pipeline. Our designer doesn't have to wait for the final copy to be approved to start producing visuals.
### Upstream quality gates
Most of what we used to catch in editorial review was actually a brief-quality issue: unclear angle, missing audience context, weak thesis. AI drafts inherit those upstream failures at high speed. Tightening the brief, and the context passed into the drafter, is cheaper than fixing the output, and it makes reviewer time go significantly further.
None of these three remove human judgement from the loop. They just move it to where it actually matters.
<ConceptCards
eyebrow="Accelerating the human side"
title="Three <em>levers</em>, one reshaped loop"
caption="Each shifts human time to the things that actually need a human, and lets the pipeline handle the rest."
sourceUrl="https://simonbeauloye.com/writing/ai-publishing/ai-publishing-bottleneck-shift/"
cards={[
{ n: 1, title: "Batched reviews", body: "Two focused hours per reviewer beats one article a day across a week. Judgement is more consistent across the batch, and feedback loops back into the next pipeline run." },
{ n: 2, title: "Templated visual systems", body: "Ratios, palette, overlays, and prompt templates specified once. The visual decision per article shrinks, and production runs in parallel to drafting." },
{ n: 3, title: "Upstream quality gates", body: "Most editorial fixes are upstream brief failures travelling at AI speed. Tightening the brief is cheaper than fixing output and stretches reviewer time further." }
]}
/>
## What does the bottleneck shift mean for organisations beyond publishing?
Every team deploying AI internally runs into a version of this. Customer support automates first-draft responses and the queue moves to escalation review. Marketing automates content production and finds the new wait sitting with legal and stakeholder sign-off. Engineering teams I talk to are running into it on the review side: AI writes the code faster than anyone can read it.
Most operators I talk to are still treating the AI investment itself as the transformation. It isn't. The AI investment is the trigger. **The transformation is whatever the organisation does once it realises the new ceiling is somewhere else entirely**, and it's almost always a place the existing org chart wasn't designed to scale. For media companies specifically, I've made this argument in [Most Media Publishers are solving the wrong AI problem](/writing/future-media/ai-restructures-publishing/).
The question we keep coming back to at mOOnshot digital is the one any team running AI in production should be asking: *where does the work actually stop today, and what would accelerate the new slow stage?* The answer is almost never AI itself.
## The AI transformation isn't done when AI can write
What comes next, once AI writes faster than humans can review, is rebuilding the human workflow around everything AI has changed. That's the harder part.
That's what [AI-native publishing](/glossary/ai-native-publishing/) really means: a pipeline built around agents from the start, paired with a human workflow rebuilt for the new constraint. Most teams haven't started on the second half.
I lay out the discipline for that rebuild in [Zero-Base Operations](/writing/bootstrapping/zero-base-operations/).
If you're staring at your own version of this shift, I'd like to hear where your human-time ceiling landed. Reach out via [LinkedIn](https://www.linkedin.com/in/simonbeauloye/), [X](https://x.com/simonbeauloye), or [hello@simonbeauloye.com](mailto:hello@simonbeauloye.com).
---
# Zero-Base Operations: Bootstrapping with AI
Source: https://simonbeauloye.com/writing/bootstrapping/zero-base-operations/
Published: 2026-04-18
Pillar: bootstrapping
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "Zero-Base Operations: Bootstrapping with AI", https://simonbeauloye.com/writing/bootstrapping/zero-base-operations/
AI-use policy: https://simonbeauloye.com/ai-policy.txt
> AI took our readers. It's also how we're rebuilding the business.
I left Google in 2017 to bootstrap mOOnshot digital. Seven years later, we had built a business generating over $80M in sales without raising a dollar. Then AI came along and completely changed the economics of our industry. Readers stopped visiting our websites and started asking AI chatbots for answers instead. We're now rebuilding our operation from the ground up, this time with AI as the foundation.
**Zero-Base Operations** is the framework I use to guide our decisions during that transition.
It justifies every process, tool, and expense from zero, with AI as part of the foundation. The name borrows from zero-based budgeting and the principle is the same: **justify every expense from zero,** rather than adjusting based on last year's numbers.
We've always run [mOOnshot digital](https://moonshotdigital.com) profitably, with 90%+ profit margins and no external capital. That discipline is what made our pivot to AI survivable when the revenue started declining. It is also what shaped the four principles I use today, and that I would use to build any new business from scratch: Start profitable. Start with the idea, refine with AI. Treat AI as the operating system. Make your data the moat.
<ZeroBaseOperationsCard width="bleed" />
## When AI is both <em>the threat and the solution</em>
I think that the transformation we experienced will impact most industries as AI models get better at answering customers' needs. The framework I'm using to rebuild our business should be helpful to anyone thinking about the same questions.
In 2024, our publishing revenue started declining as readers moved to AI chat interfaces to find the answers to their questions. AI models scrape our content freely to answer those questions, and they rarely send any traffic back to our website in return.
You can read this brief retrospective on the [impact of AI on the publishing industry](/writing/ai-publishing/ai-rebuild-retrospective/) if you want to learn more.
We had to pivot our business model fast to preserve our margins. What started as a cost-cutting exercise quickly turned into something much bigger as we realised that just adding AI agents into our existing operations wouldn't be sufficient. We had to completely redesign our organisation to truly benefit from what AI can do.
### 1. Start profitable: AI is the great leveller
We built mOOnshot digital as a [profit-first](/glossary/profit-first-always/) operation. Every venture we started and every website we launched had to have a clear, fast path to profitability. Seven years in, that discipline is what turned AI into an opportunity to rebuild. The margins gave us time and options to pivot.
Today, I think AI makes the case for starting profitable even stronger. It cuts cost and speeds up delivery at the same time.
Take Photoshop.
It's software I've used regularly for the past 20+ years. Photoshop has thousands of features, but I only use a handful of them. For years, I've paid a full subscription to Adobe for these thousands of features, because building a custom solution for what I actually need would have been more expensive.
AI completely flips that over.
With an AI coding agent, the handful of features I need become a one-evening coding session. I get exactly what I want, custom built for my needs and running locally. It costs close to nothing too.
The same logic applies to most of the software we've been paying for over the past few years.
Every SaaS subscription in our stack is now a zero-base question.
Would we pay for this if we were starting today, given that building exactly what we need costs an afternoon? Do we need the full suite of features from our newsletter provider, or our affiliate tracking provider? Or could we build something simpler that fits our workflow better, for a fraction of the cost?
Most of the time, the answer is that **building our own is better**. And it's more enjoyable too. We get full control over the features and UI, full privacy because it runs on our own servers, and no monthly subscription that inflates and accumulates over time.
Build what you need and keep the difference as margin.
### 2. Start with the idea, refine with AI
You still need the concept and the expertise. AI won't help you with either. What it does is shorten the time between a good idea and a working prototype you can use today.
[Luxe Digital Privileges](https://privileges.luxe.digital) is a good example. Partner networks' APIs on the way in, scoring and normalisation in the middle, a member-facing platform and a newsletter to 30,000 subscribers on the way out. A year or two ago, the complexity of that pipeline would have made it too expensive to justify hiring a developer to build it.
Now, with AI, I built the whole platform myself in a few hours with Claude Code. Frontend, backend, the partner API integrations, the data normalisation logic, the email layer.
<ArticleImage
src="/images/writing/luxe-digital-privileges.png"
alt="The Luxe Digital Privileges member-facing platform, showing live offers pulled from partner networks."
width={1440}
height={1150}
caption="Luxe Digital Privileges: member-facing platform, partner API integrations, normalisation layer, and email layer. Built end-to-end solo with Claude Code."
/>
Two years ago, that's a product I would have scoped out, estimated the time and investment needed to build it, and probably parked for another day. **Nowadays, it's a Saturday afternoon with AI.**
The same goes for the other side projects I'm working on: the custom tools we use for our ventures, our internal dashboards, this very website. None of those started as formal projects, and none of them would have justified the development cost a few years ago. Now they're all weekend builds.
AI won't have the idea for you. What it does is collapse the cost of being wrong. I can have an idea on a Saturday morning, write the brief, and have a working version by the afternoon. Markets that weren't worth the development cost a few years ago are now worth a weekend of experimentation.
Have the idea. Write the brief. Use AI to map, refine, and stress-test every step. **The cost of being wrong has collapsed.**
### 3. AI as the operating system: rebuild, don't patch
The third principle is the hardest to execute. [AI as Operating System](/glossary/ai-as-operating-system/) means building the business around what AI does well, not patching AI onto the workflows you already have. Most AI adoption inside established companies is the second shape: Copilot inside Word, a marketing exec with a personal ChatGPT account. Useful, but it only moves productivity at the margins.
The deeper opportunity is harder to see. I explored the publisher-specific version of this argument in [why most media publishers are solving the wrong AI problem](/writing/future-media/ai-restructures-publishing/). The operational consequence, why AI in publishing now bottlenecks on human review rather than on writing throughput, is in [The bottleneck shift](/writing/ai-publishing/ai-publishing-bottleneck-shift/).
The mOOnshot rebuild is a live case study. When the revenue decline forced us to cut costs, we didn't trim headcount and keep the same shape; **we reconsidered the shape**. The full story of that transition is in [I replaced a 15-person writing team with AI agents](/writing/ai-publishing/ai-rebuild-retrospective/).
Our writing team went from fifteen people to a small team of [operators](/glossary/non-engineer-operator/) managing an AI infrastructure that covers web development, finance, legal, market research, writing, editorial review, SEO, and [GEO](/glossary/geo/). We don't have a dedicated internal dev team. Operators build their own tools with AI agents when they need one.
Our newsletter operation for Luxe Digital Privileges, which used to take a two-person afternoon three times a week, is now an n8n pipeline that pulls offers from partner APIs, scores them, formats the email, writes subject lines, and prepares the email for an operator to review and send to our 30,000+ subscribers. A daily n8n pipeline ingests data from 150+ affiliate partners and feeds directly into a Supabase table, replacing what used to be a spreadsheet, an email thread, and a hire.
None of those changes could have happened if we'd tried to patch AI onto the existing roles. The shape only becomes visible when you redesign the pipeline around what AI can do, not around what the last org chart looked like.
Our new organisation is now smaller, flatter, and more operator-heavy. That's the shape Zero-Base Operations produces when you apply it honestly. The receipts, dimension by dimension:
| Dimension | Before | Now |
|---|---|---|
| **Production team** | 15-person writing team | Small ops team + AI agent pipeline |
| **Cycle time** | 4 weeks per piece | **4 hours** per piece |
| **Research & SEO** | Manual, human-only | Automated, with [GEO](/glossary/geo/) optimisation |
| **Editorial review** | Sequential hand-offs | Quality-gated agent loop |
| **Operating margins** | Shrinking under overhead | **90% net**, rebuilt from zero |
### 4. Human experience is the moat
The fourth principle is the one that matters most once the other three are in place. If the underlying models all converge to the same output, and everyone in your industry has access to the same tools, what's left as the moat is your [human experience, opinions, and data](/glossary/data-as-moat/).
**Human judgement** is what turns generic output into results your competitors can't reproduce by just buying the same subscriptions.
<ConceptStack
eyebrow="Concept · The AI stack, inverted"
title="The model is the cheap part.<br/>Everything <em>above it</em> is the moat."
caption="Three layers. Anyone can buy the first two. Only one of them is yours."
axisTopLabel="Moat"
axisBottomLabel="Commodity"
sourceUrl="https://simonbeauloye.com/writing/bootstrapping/zero-base-operations/"
layers={[
{
variant: "highlight",
eyebrow: "What you build, what you know, what you've collected",
label: "Your <em>moat</em>: what you know, what you'll say, what you've built.",
pillars: ["Your experience", "Your opinion", "Your data"],
stamp: "Yours"
},
{
variant: "tint",
label: "Your prompts and schemas",
meta: "Replicable in a weekend · cheap to copy"
},
{
variant: "base",
label: "<strong>Generic:</strong> foundation models, the same API keys everyone can buy.",
logos: ["claude", "chatgpt", "gemini", "grok"]
}
]}
/>
The practical shape of this is narrower than the industry usage of "data as moat" suggests. The moat is rarely a fine-tuning corpus. It is the grounding context. The three-thousand-word house voice style guide per publication. The tests folder of gold-standard past articles the drafting agent pattern-matches against. The eight years of edited reviews scored against actual purchase outcomes sitting inside our editorial archive at [Luxe Digital](https://luxe.digital). The daily operating data from 150+ affiliate partners flowing through our pipelines. None of those are downloadable. All of them compound over time.
Once you see it, where to spend gets obvious. A better prompt erodes the next time the model updates. A better dataset, a better schema library, a better corpus of past work to ground new work against. Those keep paying. With everyone having access to the same models, what sets you apart is how you use them and what unique data you feed in. That's when AI output moves from decent to genuinely valuable.
## Traditional operations vs Zero-Base Operations
The four principles combine into an operating shape that looks very different from the default. A side-by-side helps.
| | Traditional operations | Zero-Base Operations |
|---|---|---|
| **Starting condition** | Inherit last year's cost base, adjust by a percentage | Justify every process, tool, and hire from zero |
| **Capital structure** | External funding smooths margin pressure | Profitable from day one, no outside money |
| **Team shape** | Functional departments, specialist roles | Small team of operators, each with oversight across several functions |
| **Tooling decisions** | Buy SaaS subscriptions for every workflow | Build what you need with AI, buy only what can't be built |
| **Role of AI** | Feature added to existing workflows | Operating layer the rest of the business runs on |
| **Competitive moat** | Scale, distribution, brand | Your data, experience, and opinion fed into AI |
| **Hiring question** | "Who do we need to hire for this?" | "Which part of this can AI do, and who oversees the agent?" |
| **Production speed** | Quarterly release cycles | Afternoon builds, same-week iterations |
Zero-Base Operations isn't a universal prescription. A funded growth business in a winner-takes-all market may rationally pay for SaaS and hire at speed. Choosing Zero-Base Operations is a deliberate call, made because the alternative no longer fits the economics. Where it applies, it tends to apply decisively.
## What this means for operators inside organisations
Most essays on bootstrapping assume the reader is a founder. This one doesn't need to. The zero-base question scales down to a single function, a single team, a single role.
If you run a department inside a larger organisation facing AI disruption, the most useful thing you can do this quarter is ask the zero-base question honestly about your own patch. If you were starting this function today, with AI as part of the foundation, what would you actually build? What would you stop doing, stop hiring for, and stop buying? The answer is almost always a smaller, flatter, more operator-heavy team than the one you have. That gap is where the opportunity sits.
The friction is real. Budgets get allocated by function, so AI infrastructure that cuts across three departments has no natural sponsor. Roles overlap with identity, which makes "does this role still exist in its current form?" a harder conversation than any org chart deck admits. Boards still read content volume and headcount as progress, not margin. The hard part is the change management, not the tooling.
But the direction is clear enough that I wouldn't plan the next five years of any digital business on the assumption that the old shape holds. The parts of our operation I still spend time on at mOOnshot digital, I spend time on because of how they touch one of these four principles. Everything I've shut down, I shut down because I asked the zero-base question and the answer came back no.
Start profitable. Start with the idea, refine with AI. Treat AI as the operating system. Make your data the moat. Four principles, seven years in, one live rebuild. The full set of essays on [bootstrapping profitable digital businesses](/writing/bootstrapping/) goes deeper on each.
I'm still working through the rebuild myself, and mOOnshot digital isn't a finished case study. It's a live one. Revenue hasn't recovered. The operational model isn't done. But from the inside, the direction gets clearer with every quarter that passes, and the question I'd leave any operator with, founder or not, is the one I keep coming back to: *If you were starting the thing you run today, with AI as part of the foundation, what would you actually build?*
If you're working through the same question, I'd love to hear what you're seeing. Find me on [LinkedIn](https://www.linkedin.com/in/simonbeauloye/), [X](https://x.com/simonbeauloye), or via the [contact page](/contact/).
---
# Most media publishers are solving the wrong AI problem
Source: https://simonbeauloye.com/writing/future-media/ai-restructures-publishing/
Published: 2026-04-17
Pillar: future-media
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "Most media publishers are solving the wrong AI problem", https://simonbeauloye.com/writing/future-media/ai-restructures-publishing/
AI-use policy: https://simonbeauloye.com/ai-policy.txt
> A room full of publishers wanted to know how to make AI write more. I think they were asking the wrong question.
I was recently at a leadership dinner in Dubai with editors and executives from leading regional publications. Smart and experienced people. Serious media businesses. All wrestling with the same question most of the industry is asking right now: *how do we use AI to produce more and better content?*
It's the obvious place to start.
Using AI to produce content is a quick win for publishers today, and the easiest one to measure.
But the more I run [mOOnshot digital](https://moonshotdigital.com) with AI at the centre of our operations, the more I think the bigger opportunity is elsewhere. Rebuilding organisations around AI from the ground up, instead of patching AI onto existing functions, gets you more.
I run mOOnshot from inside that shift. We've gone from a fifteen-person writing team to a small team of operators managing an AI infrastructure that covers programming, but also sales and marketing, market research, publishing, SEO, and [GEO](/glossary/geo/).
The full story is in [I replaced a 15-person writing team with AI agents](/writing/ai-publishing/ai-rebuild-retrospective/).
Revenue is still below its peak for our publishing businesses as online advertising and affiliate revenue have changed beyond recognition. But I've learned that **the real change wasn't the writing.** It was the org chart underneath it.
## Why producing more content with AI is the smallest prize
Content generation is commoditising fast. Every major LLM can already produce a decent 1,500-word article, and most publishers have access to the same tools. The edge isn't the AI model. It's the team running it.
I've seen this play out in our own business. Two years ago, scaling our writing operation was difficult. Today it's the easiest part. **The [bottleneck](/glossary/bottleneck-shift/) has shifted to the human workflow around the AI:** brief quality, editorial review, visual production, fact-checking, distribution.
When AI-powered content production can work in just a few minutes, everything around it has to adapt, or you end up with a pile of drafts that no one can publish responsibly. I've gone into the mechanics of this in [The bottleneck shift: why AI in publishing is now a human-time problem](/writing/ai-publishing/ai-publishing-bottleneck-shift/).
Talking to other publishers over the past two years, most of the AI investment has gone into back office functions: summarisation, translation, transcription, SEO. These save time inside the existing org chart but they barely affect total headcount.
In a [Reuters Institute survey of news leaders](https://reutersinstitute.politics.ox.ac.uk/journalism-media-and-technology-trends-and-predictions-2026), 67% of publishers said AI hadn't saved any jobs, and only 9% had added new roles. The tools are landing inside the same org chart, and that chart has barely moved. That's why the gains stay small next to rebuilding the organisation itself.
The real question isn't *"how do we use AI to produce more content?"* It's *"what would the organisation look like if we rebuilt around AI?"*
## What does organisational restructuring around AI actually look like?
Here are three concrete examples from inside mOOnshot digital.
None of them are about content generation. All of them are about work that used to require a full team but can now be done by one person with the right AI infrastructure.
### End-to-end newsletters automation
We run [Luxe Digital Privileges](https://privileges.luxe.digital), an affiliate platform with 30,000 newsletter subscribers.
Two years ago, producing a three-times-a-week newsletter meant someone pulling the best current deals from multiple partner networks, writing subject lines and intros, laying out the email, and scheduling it.
Multiple hours of skilled time per send.
<FlowDiagram
title="Luxe Digital Privileges newsletter automation pipeline"
caption="A single n8n workflow pulls live offers, scores them, writes subject lines, and queues each send. The human gate is a ten-minute review, not a two-person afternoon."
layout="linear"
sourceUrl="https://simonbeauloye.com/writing/future-media/ai-restructures-publishing/"
nodes={[
{ id: "apis", label: "Partner APIs", sublabel: "live offers · pricing" },
{ id: "n8n", label: "n8n automation", sublabel: "score · format · write" },
{ id: "email", label: "Formatted email", sublabel: "10-min human review" },
{ id: "subs", label: "30,000 subscribers", sublabel: "3× per week" }
]}
/>
We now run the whole thing through an n8n workflow. A human operator still reviews every draft before it goes out: checking the offers, confirming nothing looks off, then sending the newsletter manually to all our subscribers.
The entire process now takes less than 5 minutes per email versus an entire afternoon before.
I built the workflow with an AI coding agent in a couple of days. Frontend, backend, partner API fetching routines, and the email integration, all written iteratively with the tool. Two years ago, this would have been a multi-month project with outside developers and a real budget.
**P.S.** *Not everything runs perfectly. I wrote about what breaks in [AI going wrong](/writing/building-with-ai/ai-building-failures/). But it keeps improving, and so far it hasn't repeated the same mistake twice.*
### Daily deals and offers API fetching
The same platform runs every morning to collect daily data from our 150+ affiliate partners: offers, pricing, stock, commission rates, etc.
We used to do this manually once a quarter with a spreadsheet. It was time-consuming, but necessary to understand where to invest our editorial resources.
Now it's a daily n8n workflow that updates a custom dashboard in a few minutes without any manual labour. And it costs close to nothing to run and maintain.
<FlowDiagram
title="mOOnshot affiliate data pipeline, from 150+ partners to three outputs"
caption="Daily ingestion from 150+ affiliate partners, normalised and scored by a single n8n pipeline, feeds the CMS, editorial site, and newsletter simultaneously."
layout="fan-in-out"
sourceUrl="https://simonbeauloye.com/writing/future-media/ai-restructures-publishing/"
nodes={[
{ id: "apis", label: "150+ partner APIs", sublabel: "offers · pricing · stock", group: "in" },
{ id: "n8n", label: "n8n pipeline", sublabel: "normalise · score · check", group: "hub" },
{ id: "cms", label: "CMS", sublabel: "content management", group: "out" },
{ id: "site", label: "Luxe Digital", sublabel: "editorial site", group: "out" },
{ id: "newsletter", label: "Privileges", sublabel: "affiliate newsletter", group: "out" }
]}
/>
Having near real-time data changes what we can do. We can take more informed decisions on where to spend our resources on [Luxe Digital](https://luxe.digital): real-time offers, more responsive coverage of live promotions, improved targeting between partner campaigns and what our audience is actually reading.
These are the kind of optimisations we couldn't have done reliably before with a small team. The cost of building and maintaining that infrastructure would have been too much.
### Build your own dashboards
Pushing things even further, we can now create internal tools and dashboards that would have required an expensive SaaS subscription before. Even better, our tools are completely custom-built for our team, and our data stay private and secured on our servers.
The person who needs the tool can now build it in an afternoon with an AI coding assistant.
<ArticleImage
src="/images/moonshot-digital-custom-dashboard.png"
alt="The mOOnshot digital internal operations dashboard, built in Claude Code by an operator rather than a developer."
width={1500}
height={1200}
caption="An internal dashboard built in an afternoon with Claude Code. No long-term SaaS subscription, no external programmer, and all our data stay private for a fraction of the cost."
/>
I'm not saying that it's easy or always worth it. A technical mindset still matters. While I don't have a computer-engineering degree, for example, I've been building web apps for over twenty years across multiple tech stacks and I'm comfortable with design tools. That experience helps me decide when to push back on an AI recommendation and how to check what it produces.
Handing an AI coding agent to someone without that foundation can get you average results at best, and occasionally dangerous ones.
But having the tools to build our own solutions is a real advantage. It means every operator now needs to **understand what it takes to solve problems with AI**.
That's the pattern across all three. AI doesn't sit on top of the work. It absorbs the job that used to need a specialist role in between.
## Organisational change is the hardest part
Most leaders I speak to understand what AI can do for their business, but they can't move as fast as they'd like because their organisation wasn't built to absorb that kind of change.
Restructuring around AI means fewer roles, different roles, and a leaner reporting structure. That's a hard problem to manage.
Three things keep coming up when I talk to senior executives about this. Budgets are allocated by function, so an AI infrastructure that cuts across multiple functions has no natural home or sponsor. It also needs different people: human operators are essential to make this work, but they often have very different profiles than the current teams. And new AI tools and solutions come to market every day, so it's hard to commit to a path forward and separate value from noise.
I think this is where smaller, [AI-native](/glossary/ai-native-publishing/) teams have a real edge. They carry less baggage and can move fast.
## Asking the right questions
If you were launching a new business today, with AI solutions as part of the foundation rather than an add-on, how big would your team be? What roles would you need?
In my conversations with other business leaders, the answer is usually fewer people but with more responsibilities. The people who can use AI well will have more exciting jobs and more autonomy. But a lot of current employees will need to find their place in this new world.
We're early in this shift.
At mOOnshot digital, we were forced to adapt early because our business model was amongst the first to be affected by AI. And our transformation is far from finished. But the direction has become clearer to me with every quarter that passes.
From what I've seen, real value comes from thinking about [AI as an operating system](/glossary/ai-as-operating-system/) and building businesses around it from the start instead of patching AI onto existing workflows.
This essay is one principle inside a wider framework that I call [Zero-Base Operations](/glossary/zero-base-operations/). That's my shorthand for justifying every process, tool, and hire from zero, with AI as part of the foundation rather than an add-on. The full method is in [its own piece](/writing/bootstrapping/zero-base-operations/).
Dinner in Dubai ended with a few people asking what tools we use. The tools are the easy part to share. The harder and more interesting question, the one I'm still working through myself, is what you'd stop doing, stop hiring for, and stop buying if you were starting the organisation today. Once you answer that one honestly, the tools tend to follow.
If this matches what you're seeing, or if you have questions or a different read on where publishing is headed, get in touch. You can connect with me on [LinkedIn](https://www.linkedin.com/in/simonbeauloye/) or [X](https://x.com/simonbeauloye), or write to me directly at [hello@simonbeauloye.com](mailto:hello@simonbeauloye.com).
---
# Learnings from rebuilding around AI
Source: https://simonbeauloye.com/writing/ai-publishing/ai-rebuild-retrospective/
Published: 2026-04-13
Pillar: ai-publishing
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "Learnings from rebuilding around AI", https://simonbeauloye.com/writing/ai-publishing/ai-rebuild-retrospective/
AI-use policy: https://simonbeauloye.com/ai-policy.txt
> When AI is both a threat and a solution.
In early 2024, we let go of 15 writers and rebuilt our publishing operation around AI agents. Most of our writers had worked with us for years, some since a hiring bet in 2020 that helped 10x our revenue in six months. It wasn't an easy decision, but readers had moved to AI chatbots and the editorial expenses no longer made sense.
**The results?** Our costs dropped by 80% and we can now produce quality content faster than ever before, but our revenue is still lower than before too.
For us, AI is both a threat and a solution.
I think that what we're experiencing in digital publishing will affect most industries as AI gets better at answering customers' demands.
This article explores what we built, what works, and what we haven't figured out yet.
## Why did we stop *employing writers?*
We stopped employing human writers because our audience had moved, not because AI had improved.
Revenue for our publishing businesses fell sharply in early 2024 as readers turned to AI chatbots for the searches that used to bring them to us.
Chatbots are now answering the queries that had driven millions of visitors to our sites. Our content is often cited as a source, but LLMs don't generate any revenue and barely send us any traffic in return.
<LineChart
title="Traffic, revenue, and AI assistant adoption, 2020 to 2030"
caption="Traffic and revenue are indexed (100 = the 2020–2023 baseline) and reflect the seasonality of our publishing businesses (Q4 strongest, Q1 lowest, modest June and September peaks). AI adoption is the share of US online adults using AI assistants for search-style tasks; 2020–2025 anchored on Pew Research and reported ChatGPT user counts, 2026–2030 extrapolated from McKinsey State of AI projections."
sourceUrl="https://simonbeauloye.com/writing/ai-publishing/ai-rebuild-retrospective/"
xStart={2020}
xStep={0.25}
xTicks={[2020, 2022, 2024, 2026, 2028, 2030]}
yLeftDomain={[0, 130]}
yRightDomain={[0, 100]}
yLeftLabel="Indexed (100 = 2020–2023 baseline)"
yRightLabel="AI adoption (% of online adults)"
series={[
{
id: "traffic",
label: "Organic traffic",
axis: "left",
color: "ink",
values: [
86, 93, 92, 109,
92, 100, 99, 117,
95, 103, 102, 120,
90, 98, 97, 102,
96, 88, 72, 58,
48, 35, 18, 28,
22, 24, 24, 29,
23, 25, 25, 30,
22, 24, 24, 29,
21, 23, 23, 28,
22, 24, 24, 29
]
},
{
id: "revenue",
label: "Revenue",
axis: "left",
color: "primary",
values: [
84, 91, 90, 107,
90, 98, 97, 115,
94, 102, 101, 119,
88, 96, 95, 100,
92, 80, 62, 48,
42, 30, 16, 24,
21, 23, 23, 27,
22, 24, 24, 28,
21, 23, 23, 27,
20, 22, 22, 26,
21, 23, 23, 27
]
},
{
id: "ai",
label: "AI assistant adoption",
axis: "right",
color: "accent",
dashed: true,
area: true,
unit: "%",
values: [
0, 0, 0, 0,
0, 1, 1, 1,
1, 1, 2, 4,
9, 14, 18, 23,
28, 33, 38, 42,
48, 53, 57, 60,
64, 67, 70, 72,
74, 76, 77, 79,
80, 81, 82, 83,
84, 84, 85, 85,
86, 86, 87, 87
]
}
]}
annotations={[
{ x: 2022.83, label: "ChatGPT launch" },
{ x: 2024.0, label: "Editorial team replaced" }
]}
/>
Cutting expenses was how we protected our margins.
**It wasn't easy.**
We had worked with most of our writers for several years and valued what they did. They were freelancers we'd hired during that 2020 hiring bet. At the time, we received over 800 applications in a single week, interviewed 30 candidates, and confirmed 15 long-term hires.
That bet paid off.
Our revenue grew 10x in six months and 20x in a year. We were publishing over 30 articles per month at 90% margins.
But by 2024, revenue was falling. We tried to recover ranking, then realised the issue wasn't our content. Instead, our audience had moved to different platforms, and the whole revenue model needed rethinking.
Reader habits had changed. We had to move with them.
## How did we build the *AI infrastructure?*
We began replacing our editorial team with an AI pipeline. The infrastructure covers market research, writing, editorial review, SEO, and GEO. Each stage is a specialised AI agent, with quality gates between them.
While we are still iterating on the workflow, one [non-engineer operator](/glossary/non-engineer-operator/) now manages the entire content production flow that previously required a whole team to execute.
<FlowDiagram
title="From 15 writers to one operator: the AI pipeline"
layout="linear"
sourceUrl="https://simonbeauloye.com/writing/ai-publishing/ai-rebuild-retrospective/"
caption="Specialist agents with quality gates at each stage. The reviewer is the asset everything upstream learns from."
nodes={[
{ id: "research", label: "Research agent", sublabel: "market + audience signals" },
{ id: "writer", label: "Writer agent", sublabel: "drafts against voice guide" },
{ id: "editor", label: "Editorial review", sublabel: "quality gate · notes loop" },
{ id: "seo", label: "SEO + GEO agent", sublabel: "search + AI surfaces" },
{ id: "publish", label: "Publish", sublabel: "one operator ships" }
]}
/>
Once we'd made the decision to migrate to an AI system, the real question wasn't which tool to use, but which workflow would actually support how we publish.
The editorial review agent took the longest to get right. The very first version produced generic content. AI slop, the kind readers spot quickly and stop reading. Not what we publish.
Over several weeks, we used our entire library of content and the publication's style guide as training materials for our AI agents. We wrote custom skills and instructions to produce articles tied to specific categories or content types. Every new article became better and better as we fed our internal models with more data and feedback.
We also adjusted the scope along the way.
The original plan included a dedicated fact-checking AI agent, but it ended up adding complexity without any real benefit. Instead, the human operator at the end of the pipeline is the one responsible for accuracy and fact-checking. The AI agents each prepare a note listing their sources so that step is easier for the operator, but only a human is held accountable for the output.
Every decision came back to the same question: *If we were designing this today, from zero, with AI as part of the foundation, would we build it this way?*
That's the logic of [Zero-Base Operations](/writing/bootstrapping/zero-base-operations/). Justify every workflow and tool from scratch instead of patching AI onto what existed before. Applied to editorial operations, the answer looked nothing like the team it replaced.
We created an [AI-native publishing structure](/glossary/ai-native-publishing/): a model where specialised AI agents, each carefully designed with custom instructions, handle research, drafting, editorial review, SEO, and GEO by default. Human operators then oversee strategy and take the final quality decisions rather than doing the production work themselves.
## Did the rebuild *actually work?*
Operational costs are down 80% and we can publish three to four times faster when we need to, but revenue is still lower than it was before the 2024 decline began.
What improved:
- **Operational cost:** Down by 80%. The infrastructure costs a fraction of the editorial team payroll.
- **Publishing velocity:** We can produce 3–4x the content volume when we need to, though volume is rarely the goal.
- **Consistency:** The AI agents follow style guides reliably. Every article goes through the same quality gates.
- **Coverage:** We can now cover topics that weren't economically viable with human writers. The marginal cost of an additional article is near zero.
What didn't improve, or got harder:
- **Original reporting:** AI can't do interviews, attend events, or build source relationships. For publications that depend on original reporting, the entire model doesn't work. We need more people involved.
- **Voice distinctiveness:** Even with 3,000-word style guides, the output tends to sound like everyone else's. Getting genuine personality into AI-generated content still requires human editing.
- **[The bottleneck shift](/glossary/bottleneck-shift/):** AI compressed the writing stage but moved the constraint to visual creation and human review, rather than removing it.
- **Revenue:** This is the big one. The traffic decline that forced the transformation hasn't reversed. We're producing better content more efficiently, and we've protected our margins, but the audience is still migrating to AI interfaces.
We now have hundreds of articles ready to publish across [Worthbury](https://worthbury.com) and a stealth e-commerce brand on Shopify. The constraint is no longer writing. It's visual creation and human review for brand safety.
The bottleneck moved.
It didn't disappear. I've written about this in more detail in [the bottleneck shift in AI publishing](/writing/ai-publishing/ai-publishing-bottleneck-shift/).
We've reshaped the operating model. We haven't solved the revenue problem.
It is now a business model question: What is the future of online publishing when users are gated by LLM companies and AI agents are trained on content scraped from the web without compensating the source for their work and research?
I don't have the answer to that question yet.
| | Before (2020–2024) | After (2024 onwards) |
|---|---|---|
| **Team** | 15 writers + editors | Small team of operators |
| **Monthly output** | 30+ articles | 3–4x capacity when needed |
| **Operational cost** | High editorial payroll | Down 80% |
| **Writing** | Human-authored | AI-drafted, quality-gated |
| **Style enforcement** | Editorial oversight | 3,000+ word encoded prompts |
| **Revenue** | Growing | Still rebuilding |
| **Primary bottleneck** | Writing throughput | Human time (visuals + review) |
## What would I *do differently?*
If you're starting this today, three things matter, whatever your industry:
1. **Start early:** We integrated AI into our workflows rapidly because we had to. We're a small, fast-moving team, so it worked, but the same probably wouldn't be true for larger organisations. The learning curve is steep and it's better to build the AI infrastructure without time or revenue pressure.
2. **Design quality controls that improve on their own:** The hardest part for us wasn't the content production. It was the quality control, and building agents that got better at that on their own.
3. **Identify where the bottlenecks will move:** For us, research and writing used to be the most time-consuming part of our work. Visual production was just something we did in parallel. By the time a story was ready, our photos and visuals usually were too. But once AI accelerated research and writing, our visual workflow couldn't keep up. This is the ceiling we're now working against.
The AI transformation isn't done when AI can solve one problem. It's done when the entire human workflow has been rebuilt around what AI has changed.
With everyone having access to the same models and tools, what sets you apart is what you bring that no one else has. Your [unique data](/glossary/data-as-moat/), expertise, and opinions.
I make the org-level case for that same problem in [Most media publishers are solving the wrong AI problem](/writing/future-media/ai-restructures-publishing/).
If this is a problem you're working on too, I'd love to hear about it. Find me on [LinkedIn](https://www.linkedin.com/in/simonbeauloye/), [X](https://x.com/simonbeauloye), or via the [contact page](/contact/).
I'll keep writing about this as the picture gets clearer.
---
# Goodbye Google, Hello World!
Source: https://simonbeauloye.com/writing/bootstrapping/goodbye-google-hello-world/
Published: 2017-01-30
Pillar: bootstrapping
Author: Simon Beauloye (https://simonbeauloye.com)
License: CC-BY-4.0 (attribution required)
Cite as: Simon Beauloye, "Goodbye Google, Hello World!", https://simonbeauloye.com/writing/bootstrapping/goodbye-google-hello-world/
AI-use policy: https://simonbeauloye.com/ai-policy.txt
> After ten years at Google, I've decided to leave to start my own business'.
> **Editor's note, 2026.** This is the original 2017 essay, written the week I left Google. I'm preserving it here as the founding moment of [mOOnshot digital](https://moonshotdigital.com) and as the starting point of the [bootstrapping](/writing/bootstrapping/) arc that runs through the rest of this site. The four-principle operating discipline I describe today in [*Zero-Base Operations*](/writing/bootstrapping/zero-base-operations/) grew directly out of the bet I'm describing below. The body of the essay is unchanged.
<p>
<img
src="/images/writing/goodbye-google-hello-world/hero.gif"
alt="Goodbye Google, Hello World — animated cover image."
width="1700"
height="940"
loading="eager"
decoding="async"
style="width: 100%; height: auto;"
/>
</p>
This will be my last week at Google. After 10 years working at [the best company in the world](https://fortune.com/best-companies/2017), I've decided to leave. It wasn't an easy decision. It took me over a year to fully make it and prepare for it. I'm leaving behind an amazing team and a comfortable job with a cosy salary. But it's a decision I had to take in order to grow and invest my time in ideas that I've been postponing for too long.
So what do you do after leaving Google? Well, read on…
<PullQuote>
The Hello World project is a time-honored tradition in computer programming. It is a simple exercise that gets you started when learning something new. <em>([GitHub](https://guides.github.com/activities/hello-world/))</em>
</PullQuote>
## Why am I leaving Google?
I joined Google in November 2006 in Dublin, Ireland. It was my first proper job after a brief stint at the Bank of New York in Brussels (just long enough to realise that a career in finance wasn't for me). The company was about 12,000-employee strong at the time. Things were moving fast. I felt that I was at the heart of an important industry-wide transformation. The Internet was radically changing the way organisations and people operate. The solutions I was working on at Google hadn't even existed as an idea a few years earlier.
It was a fascinating time to join Google. Most of what is now the company's culture and ethos was articulated during these early years. Those values and principles still run deep today.
After five years of working across multiple roles in Dublin, I decided to move to Singapore in 2011. My wife and I wanted to be closer to a booming Asian ecosystem. While Google had over 30,000 people globally by then, our offices in Asia were still relatively small and our teams often understaffed.
Fast track another five years, and Google is now in a beautiful new office in Singapore, with more than a thousand employees and plans to double that number in the next twelve months. The company continues to grow healthily. Teams are getting bigger with more resources. Delicious food continues to be free and abundant. New massage rooms are available. There's a hairdresser, a nap room, and two rooftop terraces. My job became very comfortable.
So why then, am I leaving?
<p>
<img
src="/images/writing/goodbye-google-hello-world/seeking-discomfort.gif"
alt="Stefan Sagmeister installation at the Philadelphia Institute of Contemporary Art — ‘trying to look good limits my life’."
width="760"
height="420"
loading="lazy"
decoding="async"
style="width: 100%; height: auto;"
/>
</p>
*(by Stefan Sagmeister at the Philadelphia Institute of Contemporary Art, [source](https://www.youtube.com/watch?v=II0KbecMVmA))*
My career has been incredibly exciting in these past ten years. I moved from working as a web developer to managing more than 50 people over the last six years. My team was responsible for growing an international business worth more than a billion dollars. This was thrilling and I'm proud of what we've all accomplished.
But I steadily became comfortable in my role. I could rapidly resolve new challenges thanks to past experiences and effective frameworks. I had a large network of friends and colleagues across Google that I could tap into when in need of help. Work stopped being the incredible challenge that it used to be. I stopped learning.
It took a significant life-altering change for me to realise that this wasn't right. You can't just rely on existing knowledge when new products come out every day, and 99% of the opportunities are yet to be discovered.
A year ago, my wife and I found out that we were about to have a baby. If I wanted to try something else, I had to do it quickly because my life was about to change!
<p style="text-align: center;">
<picture>
<source type="image/avif" srcset="/images/writing/goodbye-google-hello-world/william.avif" />
<source type="image/webp" srcset="/images/writing/goodbye-google-hello-world/william.webp" />
<img
src="/images/writing/goodbye-google-hello-world/william.jpg"
alt="William, our newborn son — the catalyst behind the decision to leave Google."
width="760"
height="825"
loading="lazy"
decoding="async"
style="max-width: 100%; height: auto;"
/>
</picture>
</p>
Preparing myself to become a dad gave me a sense of urgency. I started to ask myself new kinds of questions: What type of lifestyle would I want for my family? What values should we pass on to our kid(s)? What example do I want to set as a father?
Whatever the answers to these questions would be, I wasn't going to find them by staying comfortably where I was.
## Where to next?
So what am I going to do now? Well, a few things. When deciding to leave Google last year I created a document for myself to scope out potential business ventures. After a year that document has grown into a large collection of ideas that I need to sort out.
Teams at Google often organise their work by quarterly OKRs (Objectives and Key Results). That has worked pretty well for me in the past, so I'll see if I can apply it to my own ventures now. The split looks broadly like this:
<ConceptCards
layout="pillars"
eyebrow="The split"
title="<em>60 / 20 / 20</em> — where my time goes from here"
caption="The plan out of Google: a primary venture, a long backlog of experiments, and time set aside for the people doing the harder version of all this for the first time."
sourceUrl="https://simonbeauloye.com/writing/bootstrapping/goodbye-google-hello-world/"
cards={[
{ n: 1, title: "60% — mOOnshot digital", body: "Co-founder and CTO. A digital agency started by my wife and a few close ex-Google friends, helping premium and luxury brands migrate to the cloud. I'll lead the expansion across Asia." },
{ n: 2, title: "20% — Experimenting", body: "The long backlog of ideas I've been collecting all year. Some are quick and easy to implement; others are completely crazy and resource-intensive." },
{ n: 3, title: "20% — Coaching and mentoring", body: "Supporting startups — some I've been involved with over the years, many more still to be explored. Helping teams grow has been one of the most rewarding parts of my time at Google." }
]}
/>
As a closing thought, I want to thank everyone that I've had the chance to work with at Google in the past 10 years. I've learned a tremendous amount and made long-lasting friendships. I've dedicated a twelfth of my life to working there and don't regret a minute of it.
Thank you.
---
# See also
- [Site index](https://simonbeauloye.com/llms.txt) — short markdown index.
- [FAQ](https://simonbeauloye.com/faq/llms.txt) — canonical Q/A.
- [Glossary](https://simonbeauloye.com/glossary/llms.txt) — every term in one file.
- [Press](https://simonbeauloye.com/press/llms.txt) — third-party coverage.
- [Endorsements](https://simonbeauloye.com/endorsements/llms.txt) — LinkedIn recommendations.
- [Stream](https://simonbeauloye.com/stream/llms.txt) — chronological micro-feed.
- [AI-use policy](https://simonbeauloye.com/ai-policy.txt) — attribution + retrieval terms.
- [corpus.json](https://simonbeauloye.com/corpus.json) — structured metadata.
- [feed.json](https://simonbeauloye.com/feed.json) — JSON Feed 1.1.
- [rss.xml](https://simonbeauloye.com/rss.xml) — RSS 2.0.