Automating a Twice-Daily AI News Briefing Without Slop

I wanted a developer briefing that ended with a useful next step, not another open tab. ViralVault became an experiment in automating the repeatable work while keeping the editorial decision visible.

One person runs it. Mostly, a pipeline runs it, and I run the pipeline. Here is how it works, and the one problem that turned out to matter more than all the automation.

ViralVault uses a few direct HTTP integrations to keep the implementation small. Skipping an SDK removes a dependency, not the credentials or security work the integration requires. I treat that trade differently for a simple data request and a payment webhook.

The site uses Next.js 16, React 19, and Tailwind v4, with Motion and Lenis for the reading treatment, deployed on Vercel.

Nothing about it is heavy, and that is on purpose.

That table describes implementation choices, not blanket advice to hand-roll security-sensitive code. A custom webhook verifier still needs raw-body handling, signature comparison, replay checks, and tests against the provider's contract. It is the same instinct behind building AbleMakers on a deliberately boring, swappable stack: when you are the entire team, every dependency is one you debug alone.

The most important decision in ViralVault is that an edition is a JSON file committed to git. The homepage always renders the latest one, every past edition is a permalink that lives in the archive forever, and the commit that adds the file is the deploy that ships it.

That single choice cascades into everything else. The site is fully static and cacheable. The archive is permanent and version-controlled.

The scheduled workflow is a GitHub Action because the content already lives in git. Checkout, generation, validation, and commit belong in the same job. A serverless function could also write through the GitHub API; it simply was not the workflow I chose.

The ViralVault pipeline runs in three phases, scrape, then rank and edit, then publish, and each phase has one thing it flatly refuses to do. It fires from a scheduled GitHub Action and ends by committing a file like content/editions/2026-07-01-pm.json.

The editor's instructions are the actual product thesis, in one line: bias toward actionable. The audience is software developers, so at least half the stories should be something a developer can use or has to react to. Excitement plus actionability beats raw size.

Every story ends with a "why you care" and a next step, because a headline you can't act on is just noise with better typography.

ViralVault treats model output as a draft that needs evidence. Validation can catch malformed editions and invented embed identifiers; re-fetching selected URLs can check what the draft is based on. Neither step proves a story is accurate, fairly framed, or cleared for republication.

An early version replaced summaries with extracted source paragraphs. That improves traceability but is not a complete editorial solution: copying a publication's text is not the same as adding analysis, and access to a page does not grant permission to republish it. The standard is concise attributed coverage with an original, reviewable point of view.

That is the same line I drew for Ember Coast, where the itinerary is assembled by deterministic code instead of written by a language model, and the same reason ResolveMesh refuses to invent a flattering score for a capability it has never observed. Fluent output is not evidence of anything.

There is also a fallback chain across several models with retries, because free-tier providers pin to overloaded routes and return truncated JSON under load. It is the scrappy cousin of Codelit's bounded multi-provider fallback.

Production runs on Gemini through an OpenAI-compatible endpoint; my local runner prefers my Codex login and falls back to Gemini if it can't reach it. A failed or truncated draft should stop publication, not become invisible just because another provider is available.

The ViralVault prototype used a small Supabase counter and Resend subscription state to meter five free email editions. It was a compact way to test the model without building a separate entitlement service. The tradeoff is that billing eligibility and consent must not be confused.

When you subscribe, your email goes into a Resend audience and a Supabase row that starts at zero editions received, and you get a one-time welcome email. There is a hidden honeypot field on the form so bots unsubscribe themselves silently.

After each broadcast, a Supabase function bumps every free reader's count and hands back anyone who just hit five. Those readers get flipped to unsubscribed in Resend, so future sends skip them. Pro readers are never counted.

Editorial judgment is the part an automated briefing cannot delegate away. A complete JSON file can still contain a weak selection, misleading emphasis, or derivative commentary. The pipeline needs a review decision, not only a schema check.

YouTube's channel monetization policies identify repetitive or mass-produced material as inauthentic content and separately address reused content. That is a reason to review the actual output and channel, not evidence that all automated channels are banned.

The fix is not technical. It is a genuine, recurring editorial point of view. Not headline read-outs, but an actual take on each story, the kind of thing a person who ships software would say out loud.

The reader should be able to tell why this edition exists and what it adds. That is the part I do not want to automate away. The AI does the grunt work: scraping, ranking, drafting, even generating the video and the kinetic captions from a per-word timing track. The point of view stays mine.

The build produced a scheduled edition workflow, web permalinks, social cards, RSS, and a Remotion video pipeline with long-form and vertical outputs. This is an architecture retrospective, not a claim that every scheduled edition or upload is currently completing. The intended video workflow is private-first review before publication.

It started, embarrassingly, as a page I would literally screen-record by opening a hidden URL that auto-scrolled the edition at a cinematic pace. That still works. It just grew a real render pipeline around it.

For a similar project, I would automate retrieval, drafting, and rendering while keeping a clear editorial review step. The decision is not whether a video file exists. It is whether the edition adds enough useful context to deserve a reader's time.

The reusable lesson is to make publication an explicit decision. Fetching, drafting, and rendering can be automated; accountability for what a reader receives cannot.