Content Systems

Building a Content Engine from RSS Feeds

A working operator's pipeline for turning twenty subscribed feeds into a calendar of original content.

Published 2026-02-04 · By Claire Miller

RSS is unfashionable. It is also the only content-aggregation protocol that has remained stable for twenty years, costs nothing, and does not require anyone's permission. For a small business that wants to stay current on its industry without spending an hour a day reading, RSS plus a small processing pipeline is still the highest-leverage move available in 2026.

Why RSS still earns its cost

Modern content surfaces such as Twitter timelines, LinkedIn feeds, Substack recommendations, and Reddit threads are optimized for the platform, not for the operator. The operator's actual job is to know "what happened in my industry this week" without performing engagement on a platform that wants them to. RSS solves that problem cleanly. A feed reader with twenty subscribed sources, refreshed once an hour, gives an operator a steady diet of their industry without the engagement tax.

The friction that has kept RSS out of small-business workflows is that the consumption UX is bad. Most operators do not want to read 200 articles a week. They want a weekly digest, the top five to ten things they missed, and a flag when one of their competitors publishes something. A small pipeline produces that.

The pipeline shape

For a small business in 2026, the working RSS pipeline looks like this:

Inputs. Twenty to forty RSS feeds: industry publications, competitors, niche newsletters that publish via RSS, regulatory bodies, the local newspaper, Wikipedia "current events" for the industry vertical.

Ingest. Every hour, a job pulls the new entries. Each entry gets a UUID, a source, a publish timestamp, a body, and a link. Stored in a database or, frankly, in a directory of JSON files keyed by date. Volume is small: maybe 1,500-5,000 entries per week for an operator-curated set.

Score. Each entry gets three signals: did a keyword match (configurable per feed), did the entry come from a flagged competitor, did any model classify it as in-scope? The keywords and the competitor flag carry more weight than the model classification. The model classification is the tie-breaker for entries that have neither signal.

Cluster. Roughly once a day, the in-scope entries are clustered. The cluster key is something like a normalized entity name plus a date range. The output is "this set of ten articles is all about the same thing." Clusters are how a digest becomes readable rather than a firehose.

Draft. Once a week, an agent produces a digest from the week's clusters: top five to ten items, a short summary of each, one to two sentence "what this means for our business" annotations. Draft only; never auto-published.

Review. A human reviews the draft for an hour on Monday morning. Edits in three dimensions: things to drop (irrelevant noise the model accepted), things to add (the operator remembered something they read off-RSS), things to escalate (regulatory change, competitor move, anything that needs a response this week).

That is the whole pipeline. It runs on a small VM, costs nothing in SaaS, and replaces what an editorially-staffed publication would do to track a beat.

What to skip

Three things are tempting and worth skipping:

Skipping entity extraction. A small business does not need a Named Entity Recognition pipeline with custom models. Pattern matching on keywords and clustering on shared tokens is good enough at twenty-feeds-of-four-thousand-entries scale. The model is overkill; the structure is right.

Skipping sentiment analysis. The whole point of the digest is for a human to interpret. Sentiment analysis is a layer that adds cost and confuses the "things to escalate" signal without giving the operator anything they would not have gotten from reading.

Skipping auto-posting. The pipeline is most valuable as an internal operating tool. Posting the digest to LinkedIn or to a public blog post is a second workflow with a different cost structure. Build the internal pipeline first. Add the publication layer only if the internal pipeline actually gets read every week.

Practical configuration

For a small business starting from zero in 2026, the working minimum-viable version is:

FreshRSS or Miniflux running on a cheap VPS, exporting OPML and an API. A daily cron job that pulls new entries. A SQLite database or a folder of JSON files. A weekly cron that builds the digest draft as Markdown. The whole thing fits in 200 lines of Python or Node, runs in under a minute, and produces a 600-1500 word weekly digest for one operator's review.

That is the build. The harder part, the part that actually drives value, is choosing the right twenty feeds. A bad feed list is a bad pipeline, no matter how clean the code is.