Building a personal feed system, part 1: drowning in the firehose

I had 47 tabs open. AWS What’s New, a couple of company blogs, three podcast feeds, two YouTube subscriptions, X bookmarks, Substacks I’d been meaning to read. None of them were going to read themselves. That’s the moment I knew I had a problem the existing tools weren’t solving.

If you work in AWS and AI right now, you have a version of this problem too. You might be coping with it. You might be ignoring it. You might have outsourced the coping to your team’s Slack channel and the team Slack channel is also drowning. Either way the maths is against you.

This is the first of two posts about what I built to solve it. This post is about the problem and the design constraints I gave myself. The next post is the AWS architecture. Aurora, Lambda, SQS, Bedrock, the whole stack. Two weekends of work, about eleven dollars a month list price and effectively zero with the credits I happen to have, running in my own account.

Let’s talk about the problem first.

The information firehose is winning

The internet has won. Not because it has the best content. Because it has more content than any one person can rationally consume.

AWS What’s New alone hits well over a thousand items a year. That’s three a day on average and ten a day during re:Invent week. Add in the AWS blogs you actually care about: Architecture, Database, Compute, ML, News, Networking, DevOps. Add the three or four company blogs you respect outside of AWS. Add a couple of podcasts, a couple of YouTube channels, a handful of X accounts that consistently produce signal, and a Substack or two. Suddenly the unread count is not a number you can read. It is a number you can survey.

That’s the situation I was in. Reading list as backlog. Backlog as background anxiety. Background anxiety as the thing I take into Monday morning.

The existing answer is “use Feedly, mark as read, move on.” That works if your goal is feed hygiene. It does not work if your goal is signal. Aggregation and reduction are different problems. Readers solve aggregation. They do not solve reduction.

The real cost is not time. It’s the gap between consuming and processing. Knowing which of two hundred items this week actually matter for what you are building. RSS readers surface the firehose. They do not reduce it.

The cognitive cost of being technically curious

Here’s the hard truth. Being curious should be the easy part of this job. The constraint is not curiosity. The constraint is bandwidth.

A normal week looks like this. Three AWS launches I genuinely care about. Four blog posts from people I respect. Two podcast episodes. Half a dozen X threads. A Substack or two. Best case I read three of them carefully. Worst case I read zero and tell myself I’ll catch up at the weekend.

The items that get dropped are not random. The high-signal stuff often demands the most thinking, which means it is the most expensive to consume. Expensive items get pushed to “later.” Later does not come. The cheap items, the announcement-shaped ones, the screenshot-friendly ones, those get read first because they cost the least. Over time you optimise for consumption efficiency, not insight.

That’s… not good. Engineers who do not keep current do not stay engineers very long. The window between “I know this space” and “I used to know this space” is shorter than it has ever been.

And it is getting worse. The pace of AWS launches is up. The pace of model releases is up. The number of credible voices producing content has gone up by a factor of something I cannot count. The noise floor is not falling. It is climbing.

What good actually looks like

Here is the output I wanted. One email. Sunday morning. The dozen items from the week that actually mattered, ranked, with one-paragraph summaries and a link back to the original.

That is the whole product. Anything more is bloat.

The items want to be tiered. S is “read this now.” A is “read this when you have a coffee.” B is archived for later search. Each tier exists because attention is bursty. Sunday morning I might have an hour. Tuesday at lunch I might have five minutes. The tiering decides what I see in those windows.

Sources want a reputation score. If a feed stops producing signal, the system should tell me. Not silently drop it, because dropping looks the same as a bug. Surface the candidate for demotion. Let me decide.

And critically: I should not have to configure it weekly. The whole thing should run whether I am paying attention or not. The day I have to babysit my reading workflow is the day my reading workflow has lost.

Why I did not just buy this off the shelf

I looked. Feedly is a perfectly good reader. It aggregates, marks as read, syncs across devices. None of that was my problem. My problem was the reduction step, and Feedly does not do reduction.

The honest objection is that plenty of newer tools now do. Readwise Reader has LLM summarisation built in. NotebookLM will ingest a pile of sources, summarise them and let you query the result. Fabric, Daniel Miessler’s toolkit, is built precisely around running LLM patterns over content like this. Off-the-shelf reduction is no longer the gap it was eighteen months ago, and if one of those fits the way you work, you should use it and skip the build entirely.

Two things kept me building anyway, and neither of them is “the tools are bad.” The first is the boundary. This system reads my interests, my sources, my attention patterns. I would rather that lived inside my own AWS account and IAM boundary than inside someone else’s product analytics. The second is control. Polling RSS is the easy part of the stack. The hard part is what you do with the items after you have them, and I wanted that part to be code I own rather than a setting I rent. So the architecture puts the reduction step at the centre and lets the polling be a thin layer at the front.

There is a longer-term reason too, and I will be honest that it is a hypothesis rather than a shipped feature. The same curated pool that feeds my Sunday digest could later seed a writing workflow, newsletter cadence and blog ideation, the inputs you cannot automate but can prepare. That is something I am building toward, not a second product I have proven. It is an easier bet to make if the engine is mine rather than sitting inside someone else’s SaaS.

The five things I wanted the system to do

I wrote this list down on day one and did not let it grow.

1. Poll the sources I trust, with priorities. Some sources get polled every thirty minutes. Most get polled once a day.
2. Summarise every item via an LLM. One paragraph. Not a bullet list.
3. Rate every item against a rubric. A numeric quality score I can filter on.
4. Route items based on score and source class. Digest, archive, or drop.
5. Digest the survivors once a week. One email. Sunday morning.

Five verbs. That’s the whole thing. Anything that did not fit into one of those five verbs got parked or rejected. Telegram pushes? Parked. Discord notifications? Parked. Mobile app? Not happening. YouTube transcripts? Future phase if I really feel the absence.

The discipline of “no new verbs” is what kept the build inside two weekends. The temptation in a project like this is to keep adding ways for the system to talk to you. Resist that temptation. The output is one email. Everything else is decoration.

Bedrock is the inspector with the magnifying glass

Two of those five verbs, summarise and rate, are the ones that did not exist as primitives until recently. Two years ago this system was not buildable for sensible money. The summarisation step would have meant a self-hosted model, or a pile of OpenAI tokens, or some clever heuristics that work for sixty percent of items and fail unpredictably on the rest.

Now Bedrock Nova Pro will do both jobs at a cost I can ignore. Throw it an article. Get back a paragraph. Throw it the same article with a rubric. Get back a numeric score. Sub-second. Sub-cent.

This is the bit that changes the maths. The reduction problem used to be hard because the reduction step was hard. Now the reduction step is a function call. The hard part is what you wrap around it: the polling, the queueing, the routing, the digest assembly, the failure modes. That is engineering. That is the part you can build in a weekend if you are disciplined about scope.

I’ll walk through the actual architecture in the next post. The headline: Aurora Serverless v2 for state, Lambda for compute, SQS for the chain between stages, Bedrock for the LLM work, SES for the digest, CloudFront and Cognito for the admin UI. All AWS-native. Everything inside one IAM boundary. No third-party SaaS in the loop.

The honest assessment

A few caveats are worth saying out loud before anyone reads this and builds the wrong thing.

This is over-engineered for some readers. If your unread count is fine and Feedly is working for you, stop here and go enjoy your weekend. I am not selling you a problem you do not have. There is no shame in being content with a good aggregator.

The system is single-user. It is personal infrastructure. It is not a SaaS, not even a prototype of one. The design favours cost and simplicity over generality. If you wanted to turn it into something other people could use, you would re-architect the multi-tenancy from scratch.

LLM-generated summaries are summaries. They compress. Important nuance gets lost sometimes, especially when the source is technical and the model has to choose what to leave out. The link to the original is non-negotiable for that reason. If a summary hooks me, I read the original. The summary is a filter, not a replacement.

I am two weekends in. The system works end-to-end. It also has bugs I have not found yet, and the routing rules are tuned on a sample size that would embarrass a statistician. This series is a snapshot, not a victory lap. Come back in three months and I will tell you what broke.

Real-world note: the first version of the routing rules sent nothing to the digest. Zero items, week one. The rubric I was using rated technically excellent content lower than expected because it was scoring for “meaning and flourishing,” not for “AWS launch announcement.” I had to drop my quality threshold from 70 to 60 just so the digest would have anything in it. That story is in part two.

The bigger picture

For the work I do, cognitive load has become the binding constraint. Not compute. Not storage. Not even attention spans. The bottleneck is what one human can think about while the surrounding world produces information faster than they can metabolise it. I do not think that is unique to me.

It is a theme Werner Vogels has been hammering for a while now, that the cognitive load on builders is increasing significantly. I am paraphrasing the gist rather than quoting him, but it matches something every senior practitioner I know is feeling.

Here is the model I keep coming back to. AI tools that reduce incoming load are the most underrated category of personal infrastructure right now. Everyone is talking about agents that do work. Far fewer people are talking about agents that protect your processing budget. Both matter. The second is what I built first.

If you want to keep up over the next five years, you will not do it by reading harder. You will do it by building layers between yourself and the firehose that handle the boring ninety percent on your behalf. Off-the-shelf where it fits. Custom where it does not. The cost has dropped to the point where “custom” no longer means “expensive.”

Next post: the AWS architecture, the gotchas, and the bit where Codex caught an IAM bug that would have cost me a CloudWatch evening. If you have built anything similar I would happily compare notes.

I hope someone else finds this useful.

Cheers.