How I run a network of indie sites with a crew of AI bots

1. Why I'm writing this

Let me start with the reason: I want you to know these practices are real. I'm not trying to tell a "one person beats a company" story.

I'm Hugozen. My day job is a one-person mix of product, engineering and operations. I coordinate dozens of AI bots and look after a dozen-plus personal indie sites (tools, content sites, directories, small games, culture-themed projects). I only give rough counts and I don't name the sites. One person can only keep that many sites alive by handing most of the repetitive work to AI bots. It works, and it has plenty of traps. There's no shortage of posts about how AI makes you faster; most of them show results and skip the places where things went wrong. I want to do the opposite: practices, judgment calls and failures first, results later.

2. The coordinator model

I think of my own role as coordinator, not executor.

The bot that faces me only understands the request, splits it into tasks, writes the brief, and checks the result. It doesn't write long pieces of content itself, and it doesn't touch anything live. The real work runs in workers on my own Mac Studio: drafting, editing code, running builds, running checks.

There are three reasons for splitting it this way.

First, the coordinator's context has to stay clean. The moment it starts doing the work itself, its context fills with execution detail and its later judgment gets worse. If it only sees the brief and the result, its judgment stays steadier.

Second, local workers are controllable. The real work happens on my own machine, so I can check where files are, what changed, and whether anything crossed a line. If something breaks, I can roll it back.

Third, personal work stays separate from everything else. Personal projects use personal model accounts and keys; other work goes through its own channels. The two never mix, and sensitive personal tasks only use the personal channel. I draw that line hard, because once it blurs I can no longer say clearly what touched what.

The toolchain isn't exotic: Claude, GPT, DeepSeek (via Ollama Cloud) and Cursor on the model side, Cloudflare Pages for hosting; a coordinator bot splits tasks and writes briefs, workers on the Mac Studio at home execute, and I do the acceptance.

On money, one rough number: about USD 1,000+ a month goes to AI and infrastructure (that's cost, not revenue). I don't publish any revenue figures. On cost I keep to a few rules:

• Don't use an expensive model for work a cheap one can do. Checks, formatting and bulk classification don't need much from a model.
• Expensive models are for the calls that matter: flagship content, choosing between plans.
• Every task has a boundary and a budget in mind. Bots don't get to retry forever.

3. A typical task flow

An abstract example: "add a batch of explainer pages to a tool site."

1. The request. I state the goal, the boundary and what must not be touched, in a few sentences. For example: only edit the explainer pages; don't touch anything payment-related; don't touch live configuration.

2. The brief. The coordinator turns that into a brief for a worker. The brief has four parts: background, what to do, red lines, and what the deliverable looks like. The red lines matter most, e.g. "don't deploy, don't change DNS, don't include this class of sensitive information." Writing the red lines clearly matters more than writing the goal clearly.

3. Local execution. The worker runs on its own branch on my machine and puts output in an agreed folder. It never touches the main branch, so whether it did well or badly, the result can be thrown away as a whole.

4. Acceptance. The coordinator doesn't take "I'm done" for an answer. It looks at things that can be checked: is the file where it should be, do the line counts match, did anything cross a line, does the build pass. If a script can check it, I write the script.

5. My call. After it passes, I decide whether to merge and whether to ship. I don't hand deployment to a bot.

The core of the whole flow: swap "trust" for "verify."

4. Traps and lessons

1. The vaguer the brief, the more rework. Early on I wrote things like "help me do X," and the bot filled in a lot I hadn't asked for, sometimes editing things it shouldn't. Now every brief has four parts: background, task, red lines, deliverable. Rework dropped a lot.

2. Red lines must be checkable. "Don't expose sensitive information" gets interpreted a dozen ways. "Search the whole output for these words; the result must be zero" is an actual constraint. Only constraints a script can verify are real constraints.

3. It will confidently say "done." Saying it's finished is not finishing. I've been burned: a report said "verified" when only half had been. My rule now: no checkable evidence, no credit.

4. It makes things up when facts are missing. Ask a bot to write about personal experience and it happily invents plausible details, numbers and stories. So wherever I'm unsure, I require it to leave a placeholder that says "to be filled in" rather than improvise. That's where the placeholders in my drafts come from.

5. Don't take shortcuts with keys and channels. Mixing personal and other channels to save effort is the most dangerous kind of laziness. Isolation looks like extra hassle, but when something goes wrong you know exactly how far it reached.

6. More concurrency isn't better. As the bot count grew, the first thing to break was the coordinator's attention, not compute. Once many tasks are out, acceptance becomes the bottleneck.

7. Don't ship too many AI-generated pages at once. This is the lesson that cost me the most. I have a content site that put up a large number of AI-generated pages in a short time and then lost a lot of Google indexing. It still gets by on Bing traffic and visibility in GEO / AI search, and it's slowly recovering. The lesson: don't flood a site with AI content pages. Go for a few carefully edited, high-quality pages first, then scale up gradually. Nearly every newcomer learns this the hard way. Bots make volume far too easy, which is exactly why a human has to keep a hand on the brake. The longer version is in the SEO post.

5. What's next

From here this blog will follow three lines: agent coordination, SEO for going overseas, and monetization. The monetization line covers methods and judgment only, such as how to weigh ads against payments. It won't contain revenue figures.

A word on money, up front: articles here are free to read. I practise monetizing indie sites myself, which is why I write about it. This site may offer products, services or consulting in the future, and when it does they will be clearly labelled, not blended into articles. Right now the site has no checkout.

If you're also building sites alone, read along and compare notes. There's no public contact address on this site; to follow new posts, subscribe to the RSS feed.