Bui Van Dat

How I Run 8 Niche Websites as a One-Person Team With AI Agents

The pipeline behind 1,581 articles on 8 sites: keyword plans, live product data, LLM drafts, nightly audits, and one human who owns the rules.

5 min read
In this article
  1. The shape of the system
  2. Rule 1: the model never decides what is true
  3. Rule 2: selection is code, not vibes
  4. Rule 3: every draft is checked by something that is not the writer
  5. Rule 4: the human approves rules, not every page
  6. Where AI actually helps
  7. What I would do differently
  8. The takeaway

People ask how one person keeps eight content websites alive. The short answer is that I do not write most of the words and I do not check most of the pages by hand. The long answer is a pipeline, and the interesting part is not the AI model. It is everything around it.

As of October 10, 2026, my eight niche sites hold 1,581 published articles. That number comes from the nightly audit, which scanned every one of them that day and found zero open issues. This post walks through how that works, where the AI fits, and where it absolutely does not.

The shape of the system

Every article goes through the same seven stages. Each stage is a separate script with its own log, so when something breaks I can see exactly where.

  1. Plan. A keyword tool groups search terms into article ideas and writes them into a CSV file per site: keyword, article type, intended questions, status.
  2. Research. A crawler pulls live product data for the keyword: titles, ratings, review counts, specifications.
  3. Select. Plain code, not AI, decides which products qualify. It enforces thresholds such as minimum review count and minimum number of strong candidates.
  4. Draft. A language model writes the article from the research file only, following a site brief and a strict output schema.
  5. Review. A second model pass compares the draft against the research data, then a rule-based checker looks for problems the model tends to miss.
  6. Publish. WP-CLI creates the post, attaches products, sets SEO fields, and uploads the cover image.
  7. Watch. Nightly jobs audit content quality, security, and speed. A Telegram bot reports three times a day and only pings me when something is actually wrong.

Rule 1: the model never decides what is true

The single most important decision in this system is that the language model is not a source of facts. It is a writer working from a file.

If a product has 4,812 ratings, that number comes from the crawled page, not from the model. If an article says a tool weighs 3.4 pounds, the checker can trace it back to the listing. When the research for a keyword is too thin, for example only two products with meaningful reviews, the row is marked skipped-thin and no article gets written at all.

That rule cost me volume. Some niches simply ran out of topics that met the bar. I accepted that, because a thin article written from the model’s memory is how you end up publishing confident nonsense.

Rule 2: selection is code, not vibes

I tried letting a model pick “the best” products. It was inconsistent from run to run and hard to debug. Now selection is a function with explicit thresholds stored per site, like select_min_strong=3 and select_min_reviews=50. When one niche had too few qualifying products, I lowered its thresholds deliberately, wrote down why, and reopened nine articles that had been blocked.

The benefit is boring and huge: when a reader asks why a product is on a list, there is an answer.

Rule 3: every draft is checked by something that is not the writer

Models are bad at noticing their own mistakes. So after the self-review pass, a separate audit script reads the published HTML, not the database, and checks 17 things on every article:

  • HTTP status, noindex, canonical URL, and a single H1
  • whether scores are consistent with the order of the list
  • unverifiable claims and forbidden phrases
  • shortcodes that leaked into the page or into JSON-LD
  • broken internal links and broken images
  • duplicate titles, title and meta description length
  • FAQ schema validity and products that are missing from the page

Some of those checks exist because they failed in production. A product name with an apostrophe once broke a shell command in the publish step 17 times in a single day. A model once escaped quotes twice and produced 12 published articles with broken links. Each incident became a check, and each check now runs every night. I wrote about the full list in 17 checks every AI-written article should pass.

Rule 4: the human approves rules, not every page

I do not read all 1,581 articles. I read samples, especially from new templates and new sites, and when I find a problem I fix the rule that allowed it. That is the leverage: one correction applies to every future article.

My actual daily work looks like this:

  • read the morning report from the bot
  • look at anything marked as needing a human
  • review a handful of new articles in full
  • decide on changes to thresholds, briefs, or checks

The bot is tuned to stay quiet. It alerts immediately for real incidents, like a site returning errors, a new admin account appearing, or a certificate expiring within 14 days. Everything else waits for the scheduled report. An alert system that cries wolf every day gets ignored, and then it is worse than nothing.

Where AI actually helps

To be precise about it, here is where models do real work in this system:

  • Drafting long-form articles from structured research
  • Reviewing drafts against that research
  • Screening keyword ideas, keeping, dropping, or reshaping them
  • Engineering, where I build and maintain the code with Claude Code

And where they do not:

  • deciding facts, prices, or ratings
  • choosing which products qualify
  • publishing without passing the checks

What I would do differently

Build the audit before the writer. I added the nightly audit after hundreds of articles were live, which meant a cleanup pass. If the checker exists first, every article is born inside the rules.

Log everything with dates. Many fixes involved backfilling old content. Having a backup and a log line for every batch change made those fixes safe to run.

Expect the data layer to be the hardest part. The writing pipeline is the visible part, but most of my debugging time went into data collection. That story is in building a self-hosted web scraping API.

The takeaway

A one-person team can run a surprising amount of content, but not by trusting a model to do everything. The setup that works for me is simple to describe: data from real pages, selection by code, writing by a model, checking by scripts, and a human who owns the rules. The AI is a strong worker inside that system. It is not the system.

  • AI agents
  • solo founder
  • content operations
  • automation