Pallavi Geethika
Building a Newsletter Feed
January 2026 Build

Building a Newsletter Feed: Why Structuring The Problem Matters

A newsletter aggregator app. What I learned about why you need to structure the problem before writing any code.

I subscribe to too many newsletters.

Not in a "humble brag about being informed" way — but more in a "my inbox is a mess, and I've missed things I actually want to read" way. The problem wasn't volume, exactly. It was that newsletters arrived scattered throughout the day, mixed with other emails, buried by the time I had a moment to read them.

What I wanted was simple: a dedicated space to read newsletters. Not my inbox. Not another tab with 50 unread items guilt-tripping me. Just a simple feed, but for all the writing I'd chosen to follow (this was critical: I only wanted to see what I had chosen).

And so, I built one.

The Problem I Thought I was Solving

I started by thinking like a reader. I wanted to organize newsletters by topic: News goes here, Tech there, Culture in another bucket. Clean categories, easy browsing. I focused on the aesthetics: warm colors, neat typography, clean organization. Anything to make it feel less like a database, more like a curated feed.

So, I made a list of my newsletters and started grouping them. I sat with a notebook and sketched out the design. Then, I tried to build it.

The Mistake I Made

I didn't structure the problem first. I just…started building. I spun up a Flask app, set up the database, started writing code to fetch RSS feeds.

Substack newsletters? Worked. Ghost sites? Yep. WordPress? Yep, worked too. This was exciting — it was progress!

But then I tried Beehiiv newsletters. Nothing. Morning Brew? Nope. The New York Times newsletters I subscribed to? Didn't work.

I kept hitting walls where I didn't expect them. And that's when I discovered the real constraint: newsletters aren't organized by what they're about. They're organized by how they're distributed.

The tags? The aesthetics? That's potentially the easy part. But, the actual capture?

Substack newsletters? They all have RSS feeds. Ghost sites? RSS. WordPress? RSS.

But Beehiiv newsletters? No standard RSS URL. Morning Brew? Email-only. The New York Times newsletters I subscribed to? Account-locked, may not be easily forwarded.

The core insight: I was thinking like a reader (content type, aesthetics) when I needed to think like a builder (understanding technical access methods).

The newsletter universe doesn't divide by topic. It divides by infrastructure:

Each bucket requires a different technical approach. And some (like account-locked emails) may be genuinely hard to solve without building full email ingestion. And had I taken the time to understand the problem space, I would've planned it differently. I learned that by building first and discovering it the hard way.

What This Meant for V1.0

That realization changed my scope entirely. I had several paths:

Path A: build for just the public RSS feeds (~50% coverage, easy)

Path B: add Kill the Newsletter support for email-only newsletters that don't require accounts (~70-75% coverage, manageable)

Path C: Build full email parsing with IMAP to capture everything (~100% coverage, may potentially take days of work, could have technical issues)

I chose Path B. Here's why:

Kill the Newsletter was a clever hack. For newsletters like Morning Brew that just need "an email address," I could give them a KLN-generated address. It converts incoming emails to an RSS feed automatically. Zero infrastructure on my end.

It expanded coverage to ~70-75% without building email parsing. Public RSS + KLN covered most of what I read.

The account-locked newsletters (NYT, WSJ) were the real holdout. Those would require proper email integration. But they were also the smallest bucket.

Shipping something useful beats building something comprehensive. I could learn what mattered in the reading experience before investing in full email infrastructure.

The constraint became the product decision. V1.0 is RSS-only by design, not limitation.

What I Built

A Flask web app with a SQLite database. The core flow:

It's not Instagram-level polish. But it works. And more importantly, I use it. Every morning, I open it on my phone, scan what came in, read a few pieces, mark them as read.

What This Project Taught Me

Infrastructure constraints aren't blockers — they're product decisions.

Knowing when to accept a constraint vs. when to fight it — that's judgment you develop by shipping, not by planning.

Backend systems think differently than frontend.

My first two projects (a private 'social network' for small groups, a gift-exchange tool) were mostly frontend with Firebase handling the backend. This was my first Flask app — server-side logic, databases, routing. It forced me to think about how data flows, where state lives, what happens when things fail.

That shift — from "what does the user see?" to "how does the system work?" — was the real learning. Not Flask syntax, but systems thinking.

Content ecosystems have invisible structure.

I thought I understood newsletters because I read them. I didn't understand how they're distributed, how access works, how technical decisions by platforms (Substack auto-publishes RSS, most legacy publishers don't) shape what's possible.

That's true for any product in a content ecosystem — streaming video, podcasts, social media. The visible product sits on top of infrastructure that constrains and enables in ways users never see.

What's Next

The app is live on PythonAnywhere. I'm using it daily. V2.0 could include:

But honestly? V1.0 solves most of my problem. I'm not drowning in newsletter clutter anymore. I have a dedicated space to read. That was the goal.

I will continue to refine this as I use and learn, but for now — cheers to a custom-built tool!

← Back to Field Notes