Dozens of Articles a Day. Your Readers Only Want the Lines About Their Players
Fantasy football news moves faster than any editor can write it up, and a reader chasing one player does not want the whole news cycle. We built the layer that reads every incoming article for DynastyPulse.com and turns it into a short player update, tailored to what that reader follows, the moment it publishes.
Manual drafting drops out; only review and QA time remains
A webhook fires on arrival, against a multi-hour manual cadence
Ingestion is automated, so a heavy news day costs nothing extra
Short, personalized updates against one generic column for everybody
The problem
Player News Was Arriving Fast and Landing Generic.
The site did not need more content. It needed the same content cut down to the players a given reader actually cares about.
Kodexo Labs project team
DynastyPulse.com runs on player content, and player content has a shelf life measured in hours. Writing it up by hand meant every update arrived late and arrived the same for everybody: one article, one length, one angle, whether the reader had that running back on three rosters or had never heard of him.
The cost was engagement. A reader who has to open a 900-word column to find one line about their player stops opening columns. The brief was to keep the editorial sources exactly as they were, and change only what the reader receives: personalized to their interests, short enough to read on a phone between meetings, and current the moment the source publishes.
Updates written by hand, one version for every reader.
No tailoring to interests, and nothing that kept pace with the feed.
Short, personalized player summaries, generated as articles land.
What we built
A Summarization Service That Sits Between the News and the Website.
Nothing about how Dynasty Pulse publishes had to change. We added one service alongside the site, made of five parts: the thing that writes summaries, the feeds that supply it, the trigger that wakes it, the instructions that make it useful, and the place it runs.
01Claude Writes the Short Version.+
The core of the build: a tool that takes a full fantasy football article and returns an accurate, relevant summary of it. Claude does the writing; everything else in this list exists to feed it well.
02The Articles Arrive on Their Own.+
Publisher feeds are processed automatically, so the source material shows up without anybody pasting a link. Real-time updates come from the feed itself.
03New Content Starts the Work Itself.+
A new article on the feed triggers summarization, later moved onto webhooks so the process fires on arrival rather than waiting for the next check. No queue to run, no editor to press a button.
04Custom Instructions, Not a Generic Summarizer.+
Prompts written specifically for this content, so a summary keeps the fact a fantasy reader came for. This is the part that decided whether the feature was useful or just shorter — more on it below.
05It Runs Beside the Site, Not Inside It.+
Summarization is hosted on Render as its own service, on backend infrastructure built to scale and to support later expansion. The WordPress site keeps doing what it already did.
Claude Writes the Short Version.
The core of the build: a tool that takes a full fantasy football article and returns an accurate, relevant summary of it. Claude does the writing; everything else in this list exists to feed it well.
The Articles Arrive on Their Own.
Publisher feeds are processed automatically, so the source material shows up without anybody pasting a link. Real-time updates come from the feed itself.
New Content Starts the Work Itself.
A new article on the feed triggers summarization, later moved onto webhooks so the process fires on arrival rather than waiting for the next check. No queue to run, no editor to press a button.
Custom Instructions, Not a Generic Summarizer.
Prompts written specifically for this content, so a summary keeps the fact a fantasy reader came for. This is the part that decided whether the feature was useful or just shorter — more on it below.
It Runs Beside the Site, Not Inside It.
Summarization is hosted on Render as its own service, on backend infrastructure built to scale and to support later expansion. The WordPress site keeps doing what it already did.
Why the prompts were the product
Anything Can Shorten Text. Very Little Keeps the One Fact a Fantasy Manager Needs.
A generic summarizer will happily give you the first three sentences of a column and call it a summary. For fantasy football that is worthless: the sentence that matters is usually buried, and it is a snap share, a practice status, or a depth-chart move.
So the real work went into the instructions, not the plumbing. We wrote prompts for this specific content, then fine-tuned them against a wider spread of articles until the summaries stayed relevant and readable no matter what the feed sent through.
The instructions name what a fantasy reader is looking for, so the summary is built around that instead of around sentence order.
A second pass sharpened the prompts so the summary that comes back is both the right fact and a readable sentence.
Long columns, short blurbs, and everything the feeds send in between hold up, so quality does not depend on what published today.
The solution
Three Phases, Nine Deliverables, One Live Feature.
Each phase had its own objective and shipped something usable, so the feature was never one long build waiting on a launch date.
Get a Real Summary Out of a Real Article.
Build the summarization tool on Claude with a first prompt strategy, automate article intake from RSS, and stand the service up on infrastructure that can take what comes next.
- Summarization tool with prompt engineering in place
- Automated RSS intake with real-time article summarization
- AI microservice deployed on Render
Make It Good, and Make It Instant.
Sharpen the prompts until summaries hold up across the full range of articles, and replace waiting on a schedule with a webhook that fires as content lands.
- Enhanced prompts for accurate, useful summaries
- Webhook integration for real-time RSS updates
- First test results on accuracy and system behaviour
Put It on the Site and Prove It Holds.
Wire the summarization function into WordPress, write test cases for the conditions that actually occur, and check the system against rising content volume before calling it done.
- Summarization fully integrated into the website
- Test cases completed and the system validated
- Final optimizations for scalability and performance
Three Things, Live on the Site.
- An AI summarization feature running on dynastypulse.com
- Automated real-time updates via RSS feeds and webhooks
- A scalable system built to meet the business and technical requirements
How it works
Somebody Else Publishes. Your Site Answers.
A relay, not a workflow. One lane is the news world doing what it always did. The other is the service we added, reacting to it.
A writer somewhere publishes a story about your reader's player.
Nine hundred words, one useful sentence, and no idea who is reading.
The feed pings us, so nothing has to be noticed by hand.
A webhook off the RSS feed starts the work on arrival, instead of a schedule catching it later.
The article is stripped back to its text and handed to Claude.
Page furniture out, repeats skipped, then the prompt written for fantasy football goes on top.
The summary comes back, gets checked, and is kept with the article.
Formatted and validated before anyone can read it, and stored so the same piece is never summarized twice.
The site updates itself, with no editor in the loop.
WordPress picks the summary up as dynamic content. Nobody republishes a page.
The reader opens the site and finds four lines about their player.
Same news, cut to their interests, while it still matters.
The Service Just Waits.
There is no batch window and no nightly job to miss. The feeds are polled and the webhooks are listening, so a quiet Tuesday costs nothing and a Sunday full of injury news is handled the same way, one article at a time, as each one arrives.
System architecture
The Whole System on One Page.
Read it top to bottom: news comes in at the top, a summary reaches a reader at the bottom, and the box in the middle is the only new thing we added.
Fantasy football publishers
Their articles arrive as RSS feeds — the same feeds a news reader app would use
Feed watcher
Checks the feeds and gets pinged the second something new publishes
Tidy up the article
Strips the page furniture and skips anything already seen
Write the instructions
Adds the purpose-built prompt that says what to keep
Check the summary
Formats it and validates it before anyone can read it
Its own service, separate from the website — busier news days mean more capacity here, not a slower site
Content store
Keeps each article next to its finished summary, so nothing is written twice
Claude
The model that actually writes the short version, from Anthropic
The summarizer reads from and writes back to the content store, and calls Claude for the summary itself.
dynastypulse.com
The existing WordPress site — summaries appear as normal, updating content
Under the hood
The Tools We Used, and What Each One Does.
Articles are pulled from RSS, cleaned, summarized by Claude behind a purpose-written prompt, and handed to WordPress. The summarizer runs as its own service so it can scale apart from the site.
Six pieces, one job each
Claude
The modelWrites every summary, working from the prompt we wrote for fantasy football content.
Render
Where it runsHosts the summarization microservice, separate from the website it feeds.
RSS
How content arrivesCarries publisher articles in automatically, with no link-pasting or copy-paste step.
Webhooks
What starts the workFire the moment new content lands, so summarization starts on arrival rather than on a schedule.
Prompt engineering
Our work, not a vendor'sCustom instructions, then fine-tuned ones, deciding what a summary keeps and what it drops.
WordPress
Where readers see itThe site the client already had. Summaries publish into it as dynamic content.
Personalized by interest
Summaries are shaped around what a reader follows, not around what the article led with.
Real-time by default
Webhooks off the RSS feeds start the work as content lands, with no scheduled run to wait for.
Separate from the site
Summarization runs as its own service on Render, so it scales without touching WordPress.
Validated before launch
Test cases covered summary accuracy, webhook behaviour, and performance as volume rose.
The outcome
The Same Team, Publishing Faster, for Less per Article.
Nothing about the editorial voice changed. What changed is where the hours go: writing the first draft of a routine player update is no longer a person's job, and adding a new source is no longer a project.
Manual drafting comes out of the per-article cost, net of what the summarization service costs to run.
A new feed plugs into the prompts and pipeline that already exist instead of getting its own workflow.
Better-engaged readers stay on the page longer and come back, and that carries through to revenue.
Editors review instead of draft
The summary is written by the time anybody opens it, so the editorial job on a routine update is a read-through, not a write-up.
The reader gets their player, not the column
Updates are cut to the players somebody actually rosters, short enough to read on a phone between meetings.
A heavy news day costs nothing extra
Ingestion and summarization are automated and were tested for volume, so a busy week does not need a bigger team.
Frequently asked
Common Questions About a Build Like This
Where do the summaries come from?
From the articles arriving on the site's RSS feeds. Each one is cleaned up, passed to Claude with a prompt written for fantasy football content, and returned as a short player update.
How quickly does a summary appear?
The work starts when the feed reports new content, not on a schedule. A webhook triggers summarization as the article arrives, so the update is generated in real time.
Did the website have to be rebuilt?
No. The summarization function was integrated into the existing WordPress site, and the AI service itself runs separately on Render.
What makes a summary relevant rather than just shorter?
The prompts. They were written for this content, then fine-tuned so summaries stay clear and relevant across a wide variety of articles.
What happens on a heavy news day?
The service was tested for scale with increased content volume and user activity, and it runs apart from the site, so more articles mean more capacity there rather than a slower website.
How was it tested before launch?
Detailed test cases covered summarization accuracy, webhook behaviour, and performance under varying conditions, with final optimizations made afterwards.
Could this work for a site that isn't about football?
The pattern is content-agnostic: a feed, a prompt written for your subject, and a service that publishes back into your site. What changes is the instructions, not the architecture.
Who owns the service once it ships?
It was built to be handed over: one microservice, its prompts, and its feed configuration, deployed on infrastructure the client controls.
Sitting on a Content Firehose Your Readers Can't Drink From?
30 minutes, and you'll know whether feed-triggered summarization fits your publishing setup.
Related work
