build.allanninal.dev

Part 1 of 7 · Daily briefing bot series ~5 min read

A daily briefing bot on AWS for a few dollars a month

You want to keep up with a dozen sources without spending an hour a day reading them. Here’s how to build a small robot that reads everything for you, picks the few items worth your attention, and emails you a short digest each morning.

The whole system on one page

Before any code, here’s the shape of what we’re building.

System architecture: three outside surfaces, three inside AWS At the top, three external surfaces in a row. On the left, “The web” — the RSS feeds, public APIs, and pages where stories actually live. In the middle, “Your topic” — a short description of what you care about. On the right, “Your inbox” — where the digest arrives. Each of these connects via an arrow to a containing box labeled “AWS account”. The web feeds into the AWS account; your topic feeds into the AWS account; the AWS account sends out to your inbox. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Ingestor — reaches out, fetches new items, brings them home. In the middle, the Ranker — scores each item against your topic, keeps only the ones worth your time. On the right, the Postman — writes the digest and sends. Internal arrows flow left to right: Ingestor passes new items to the Ranker, Ranker passes top picks to the Postman. The web RSS, APIs, pages Your topic what you care about Your inbox where the digest lands fetches from your interests sends digest AWS account Ingestor walks the source list, fetches what’s new Ranker scores each story, keeps the keepers Postman writes the digest, sends it today’s items top picks The ranker is where the AI sits. Everything else is plumbing.
Fig 1. Three outside surfaces, three pieces inside AWS. One flow in, one flow out.

What you set up once (the outside)

  • A list of sources you watch — the feeds, public services, and pages you’d otherwise refresh by hand. Lives in a single file you can edit anytime.
  • A short description of your topic — a paragraph or two explaining what you actually care about. The bot reads this to decide what’s worth your attention.
  • An inbox — email, a chat channel, or a fresh doc each morning. Whichever you actually check.

What runs every morning (the inside)

  • The ingestor — wakes up on schedule, walks your source list, fetches what’s new since yesterday, drops it all in one place.
  • The ranker — reads each item, scores it against your topic description, keeps only the few worth your time.
  • The postman — takes the keepers, writes them up as a short digest, sends it.

In plain words

You list the sources. The cloud reads them every morning. A small AI sorts the noise from the signal. You get a short digest in your inbox before your first coffee.

Total cost runs a few dollars a month, not a few hundred.

Design rules that shaped every decision

  • Stay inside the AWS always-free service quotas wherever possible.
  • No always-on server. No NAT Gateway. No infinite log retention.
  • The ranker must be cheap by default — most items die at a free filter before any AI sees them.
  • Empty inboxes are a feature. If nothing scores high enough on a quiet day, no digest goes out.
  • Your source list lives somewhere you already know how to edit — so updating it never needs a deploy.

Why this shape

Most “news aggregator” tools collapse under one of three weights: a server bill that climbs every month, a noisy digest you start ignoring within a week, or a curation pipeline that costs more in AI calls than the time it saves.

The architecture above is the smallest set of moving parts I could find that solves all three at once. One way in (your sources), one way out (your inbox), a small AI in the middle making cheap decisions. Everything else is plumbing.

The next five posts walk through each piece in turn — how the ingestor works, where the AI fits, why most items never reach it, how the digest gets written and delivered, and what the whole thing actually costs. One diagram per post. A final engineering reference at the end gives engineers the dense version with precise service names and model IDs.

All posts