Every morning at 06:49 IST, a scheduled job on our product site researches a topic, drafts an article, translates it into twelve Indian languages, runs it through a set of automated checks, and — only if it passes all of them — opens and merges a pull request that publishes it.
Nobody reads it first. That last sentence is either the interesting part or the alarming part, depending on how the gate is built.
The naive version, and why it fails
The obvious implementation is a cron job that calls a model and commits the output. It works for about a week.
Then one of these happens: the model returns something subtly wrong about tax law. A translation renders into a script that breaks the layout. Two articles get generated about the same topic because nothing checked what already existed. A post publishes with a missing meta description and quietly sits there, unindexed. The frontmatter parses but the date is in the future, so the post never appears.
None of these are model failures exactly. They are pipeline failures — the absence of anything standing between generation and production.
The gate is the product
The generation step is the easy half. The half that matters is a set of checks that a draft must pass before it is allowed to merge:
- Schema validation. Title length, description length and shape, a real date, valid tags. A post that fails the schema fails the build rather than publishing malformed.
- Duplicate detection against every existing slug and title, so the pipeline cannot rediscover a topic it covered in March.
- Link checking. Every internal link resolves; every external link returns a 200.
- Language verification. The Hindi version is actually in Hindi. This sounds absurd until a translation step silently returns English and you publish twelve identical articles.
- Build success. The site must compile with the post in it. Nothing merges that breaks the build.
If any check fails, the pull request stays open and a human looks at it. The automation’s default outcome on uncertainty is stop, not publish.
Why it publishes to a pull request, not to the server
The pipeline never writes to production. It writes a branch, opens a PR, and the merge is what deploys. That gives you three things almost for free: a complete history of every published word, a one-click revert, and a place for a human to intervene that does not require anyone to be watching at 06:49.
It also means the “kill switch” is not a special feature. It is turning off a workflow.
What it is worth
Twelve languages, daily, unattended. In search terms, the Indian-language versions are the whole point: the English article competes with everything on the internet, while the Tamil and Malayalam versions compete with almost nothing and are what the actual buyers type.
The honest caveat is that this is a long game. Content pipelines do not produce traffic in month one, and anyone who tells you otherwise is selling something. What they produce is a compounding surface area that costs almost nothing to maintain once built, in languages your competitors are not writing in.
Where the money actually goes
Model API usage, and nothing else worth mentioning. The pipeline runs on GitHub Actions’ free minutes, publishes to a static site on a CDN, and needs no server. The recurring cost of running this is measured in hundreds of rupees a month, not thousands.
That ratio — near-zero running cost, meaningful build cost, compounding output — is why we build these for other people now. The build is the hard part, and it only has to be done once.