Running an AI Content Pipeline at 498 Posts: Legal Safety, Cost, and CI Safety Nets

I'm six months into OwnQR, a $15 lifetime QR code tool I run solo from Vancouver. About 40 paying customers, ~$600 MRR, bootstrapped, no investors. The honest reason I'm writing this is that almost everything published about "AI content pipelines for SaaS blogs" stops at the editorial level — pick the right model, write better prompts, review the draft. Useful, but it skips the failure modes that show up only at scale, and the one that scared me most was legal exposure, not quality.

By "at scale" I don't mean enterprise. I mean a single founder publishing ~498 articles in six months on a domain that started at DR 0, with a laptop and a budget that wouldn't pay one human writer for one of them. This post is the system that got me through it without an incident, plus the architecture decisions I now wish someone had told me earlier.

The four-pass framework everyone teaches

Most editorial guidance for AI-assisted SaaS content converges on a four-pass review:

1. Positioning and audience fit — does the piece say something specific to your product, or could it run on any competitor's blog?
2. Claim verification — every statistic, attributed quote, and benchmark gets checked.
3. Depth and usefulness — does the article teach the reader something they can use, or does it describe a concept abstractly?
4. Voice and tone — does it sound like you, or does it read in the averaged, hedging voice that LLMs default to?

This is correct, and it works at the article level. I use a version of it. But once you cross roughly fifty published posts, two things break.

The first is that human-paced claim verification stops scaling. The second is that a failure mode invisible to all four passes starts accumulating across the corpus. That second one is what nearly cost me real money.

The fifth pass nobody talks about: legal and risk verification

A surprising amount of competitive copy in the SaaS space — comparisons, alternative pages, "X vs Y" articles — sits in a legally sensitive zone governed by the Lanham Act (§43(a) for false advertising in the US) and the FTC's 16 CFR Part 465 endorsement and comparative advertising rules. The same is true in most other jurisdictions; the specifics differ but the contour doesn't.

The risks aren't dramatic individually. They're cumulative:

• Hardcoded competitor prices that go stale. "Competitor X charges $29/month" is fine the day you write it and false the day they change. Multiply by 498 articles and 5 competitors and you have a maintenance nightmare and a defamation surface.
• Charged or accusatory metaphors. Words that frame a competitor's pricing model as predatory, exploitative, or coercive read fine in a single draft. Across a corpus they read as a sustained smear, which is exactly what plaintiffs' lawyers look for.
• Comparative claims with no current source. "Their tool doesn't support X" might be true today and false tomorrow when they ship X. If your post still says it three months later, you're publishing a false statement of fact about a competitor.
• Implied endorsement from third parties. "As mentioned in [Publication]" without verification is a quick way to attract a cease-and-desist.

A model trained on the open web will produce these patterns confidently and constantly, because the open web is full of them. None of the four standard passes catches this — they're tuned for editorial quality, not legal exposure.

How I codified the fifth pass

I run an AI content pipeline using DeepSeek as the underlying model (chosen for cost — generation is roughly $0.20–$0.40 per long-form post). The interesting part isn't the model choice. It's the safety net wrapped around it.

The lint step lives between draft generation and publish. It's a deterministic script that fails the build if the draft contains any forbidden token from a curated list. The list is small but specific:

• Names of competitors paired with any dollar amount (regex-flagged for human review)
• A blocklist of charged metaphors known to attract legal scrutiny in comparative content
• Patterns that imply a third-party endorsement without a verifiable source
• "Always" / "never" absolutes about competitor product behaviour
• Pronoun patterns implying exclusive negative attribution ("the only", "the worst")

When the linter flags a draft, the generation step doesn't ask the LLM to retry. It exits non-zero and the article is held back. Two outcomes from there: either I rewrite the offending phrase by hand, or — if a competitor name + price combination triggered it — the build re-runs against a fresh data source (more on that next).

The crucial design choice is that the linter runs on every commit, not just before publish. The CI pipeline rejects the change. There is no way to silently merge a violating draft because someone forgot to run the script. This sounds obvious; in practice it's the difference between a safety system that works and one that's bypassed within two weeks.

Pass 2 evolution: data lookup, not LLM memory

The other thing that breaks at scale is human-paced claim verification. Once a week I used to manually re-check every cited competitor price across a couple of articles. By the third month it was eating four hours a week and I was missing things.

The fix was to stop trusting the LLM's memory for any verifiable fact. We pull live competitor pricing weekly via a Puppeteer script that scrapes each competitor's pricing page, normalises the result into a JSON file in the repo, and commits it. The article generator then references that JSON at build time. The LLM never makes the price claim — it composes a sentence around a placeholder, and the placeholder is filled in deterministically from the latest scrape.

// pseudocode of the substitution layer
const prices = readJSON('config/competitor-prices.json');
const draft = await generateDraft({
  template: prompt,
  facts: { competitorPricing: prices }
});
// the LLM produces "{{COMPETITOR_X_MONTHLY}}" placeholders;
// the build step substitutes them just before publish.

This shifts the failure mode usefully. If the scrape breaks (the competitor changes their HTML), the build fails loudly. If the price changes, the next build picks it up automatically and old articles are regenerated as part of the weekly cycle. The LLM is never authoritative on anything checkable.

The general principle: assume the model will hallucinate, and put the safety net in the data sourcing, not in editorial willpower. Static fact-checking by humans does not scale past a certain post count. You either invest in deterministic data plumbing or you accept that a percentage of your published claims are quietly wrong.

What 498 posts actually looks like operationally

A few numbers from the last six months that I find useful to share, partly because most "AI content at scale" posts hand-wave around the actual cost shape:

• Generation cost: roughly $100–$150 total in DeepSeek API calls.
• Linter false-positive rate: about 4% of drafts flagged for review where the flag was unnecessary. I leave it tuned conservative — false positives cost me a minute, false negatives could cost me a lawsuit.
• Average human edit time per article: down from ~25 minutes early on to ~6 minutes now, almost entirely because the linter and the data layer eliminated the categories of error I used to manually check.
• Net effect on traffic: marginal. The corpus matters less than I thought it would. Internal linking, GEO/AEO optimisation, and a handful of cornerstone pages are doing more work than the long tail. But that's a separate post.

The point isn't that AI content is a magic SEO lever — at DR 0 with no editorial backlinks, it isn't. The point is that if you're going to operate an AI pipeline at all, the ROI of the safety infrastructure is wildly higher than the ROI of better prompts.

A heuristic for the depth pass

One last thing, since I keep getting asked it. The cheapest signal I use during the depth review is: "Would I include this paragraph if a senior person in my category were reading over my shoulder?"

If the honest answer is "yes, but I'd sweat slightly" — that's the right depth. The reader will feel something specific is being said.

If the answer is "yes, easily" — it's category-level filler. Strip it. The reader will feel the article was written for nobody in particular, which is exactly what the four-pass framework is trying to prevent.

If the answer is "no, absolutely not" — you have either a factual problem or a tone problem. Both are easier to fix than the silent damage of bland competence.

Who this is for, and who it isn't

If you're running a small content programme — say, 5-10 articles a month, all touched by a human editor — you almost certainly don't need any of this. The four-pass framework is enough. Your bottleneck is editorial quality, not legal exposure or verification scale.

If you're publishing weekly across multiple categories with comparative content in the mix, and a non-trivial portion of your drafts are AI-assisted, the fifth pass and the data-source discipline are not optional. They're the difference between a pipeline that compounds and a pipeline that becomes uninsurable.

The setup I described is reproducible in a weekend. The lint list is the most opinionated part — it has to fit your specific competitive context — but everything else (DeepSeek + a Puppeteer scraper + a JSON file in the repo + a CI hook) is standard infrastructure. The unusual part is treating it as a safety system rather than a productivity boost. That reframe is the actual lesson.

---

Max Liao runs OwnQR, a $15 lifetime dynamic QR code tool. He writes about indie SaaS architecture, AI content pipelines, and edge-deployed cost economics. Find more posts on the OwnQR blog.