Automotive Newsroom: It’s not 2005, so stop running publishing news like it is

What's under the hood One login · whole loop

Stack

ReactTypeScriptViteTailwind CSSNetlify FunctionsFirestoreAnthropic APIOpenAI APIAhrefs APIGoogle AnalyticsSearch ConsoleWordPress APId3-force

Key features

• News Radar
• Bubble map
• Ticker view
• Ranked list
• Latest feed
• Heat score
• 1-5 magnitude
• Coverage gaps
• Semantic clustering
• Competitor feeds
• Article generator
• House-style drafts
• WordPress push
• SEO tracker
• Keyword explorer
• Decay radar
• Refresh radar
• Image search
• License tags
• Feed health
• Mark as published
• In-app guide
• Google sign-in
• 141 tests

Poking at the research conundrum

One of the best SEOs I ever worked with always used to say this about news: “It’s either be the first, be the best or go bust.” And it’s pretty much how the news cycle works - you've got your TMZs going all-in on being the first and others battling it out to see who gives the best recap/thought piece.

It just so happened that my client had issues achieving both of these goals. Even though his website was climbing up the SERPs, his most prized section, the News Feed, was lagging behind the competition.

Not only that, but he couldn’t even decide which stories to focus on even if he got scooped, resulting in the evergreen part of the site dragging the News Feed’s lifeless body, making every campaign run at reduced effectiveness. It was what the kids call a “big yikes.”

Vroom, vroom indeed

What stuck out to me the most was that the newsroom was still finding stories the way you'd find a restaurant in 2009: open Google, type, pray, improvise. Instead of picking my jaw off the floor, I wanted to define the issue. And through a series of interviews, I got to the bottom of the issue - everyone could describe things semantically; we just needed to turn them into numbers. But first, I had to define the key metrics:

• No. of articles about the same topic
• No. of articles from the same source
• Did the competition cover the story
• No. of articles about the topic in X hours
• The importance of the story

So, my main goal was to minimize token expenditure, but still use Anthropic and OpenAI APIs for easier clustering and defining of each topic. Of course, I immediately thought of building a custom RSS reader, but I didn’t want this to be only a News Radar. I thought much bigger. Why?

The bigger you think, the more bugs you get to fix

Because when you actually look at how a newsroom works, every piece of content runs the same lap: you find the thing worth covering, you decide whether it's worth it, you write it, then you publish and track it. It’s just that we all act like a Labrador when he sees a piece of food fall on the floor whenever it comes to picking specific SaaS providers and microservices.

If that loop is the same every single time, why would I automate only one corner of it? So I pitched closing the whole thing: find, decide, create, publish and track in one hub, built on the APIs and tools he already owned, for next to nothing in tokens. One login, the entire content lifecycle.

Content should be an ouroboros

Sure, you can look at the snake devouring its own tail and immediately think of self-devourment, erasure and futility, but I prefer to look at things from a different perspective. What if we make the serpent endless - wouldn’t that technically be sustainability?

Hence, it all starts with the radar itself, because that's where most of the thinking went. Under the hood, it runs on semantic clustering. I used OpenAI's embeddings for it, the unglamorous feature nobody talks about. I didn’t dabble so much in the clustering; it was tuning the exact threshold where a match is definitely not a false positive (0.74-0.78 is the sweet spot, if you ask me).

Too loose and the net scoops up every fish in the sea; too tight and the salmon swims right through.

Get that wrong and you either splinter one story into ten bubbles or fuse two unrelated ones together, and the moment that happens, an editor stops trusting the screen. Once the logic held up to each of my benchmarks, every topic cluster becomes a circle on a map, and the size of the circle is the story's heat - a number that defines the level of popularity and urgency surrounding it.

It wasn’t time to celebrate yet, though. Next, I built out how many separate sources picked the story up, how many articles landed in the last 24 hours, and how many in the last hour. The hub is also subscribed to the competitors' RSS feeds, so their coverage pours into the same picture. I made sure to add multiple views, because a busy newsroom doesn't have time to dig for it.

Heat on its own wasn't enough, though, and that lesson came straight out of sitting with the site’s content team. They told me their real problem just wasn't finding news, but also judging how much a story actually mattered.

The million-dollar question

So, I’ll resurface this again - how do we define importance?

Picture this: If Max Verstappen signs a sponsorship with some Dutch convenience-store chain, only niche motorsports sites will cover it. If he crashes or breaks a record, even outlets that think DRS is a tax form will run it.

That proves magnitude can be defined by how much a niche story exceeds the confines of its “home niche.”

But there’s the thing: a raw heat score can't tell those two apart. So I had Haiku 4.5 do two jobs on every cluster: give it a clean, human-readable name (which matters more than it sounds, because the team has to scan and move fast), and rate its magnitude from 1 to 5. That magnitude feeds back into the heat formula, so a genuinely big event outranks a busy-but-trivial one. The bigger the bubble, the more it matters.

However, that’s when it hit me - to be the first and be the best, we shouldn’t just subscribe to the best sources’ RSS feeds, but also to those of the top 20 competitors. That’s how we surface content gaps in real time: the News Radar cross-references the competitors' feeds against the client's own coverage and surfaces the gap.

It’s a way of telling the user: here's a story that's big in the wider car world, and nobody local has touched it yet. That's a scoop the team can see coming, and because the rest of the hub is right there, they can turn it around fast and watch how it lands.

Okay, cool, we've got nets out into the water, but we’re still far from having salmon filet for lunch. So what now?

We don’t just close the loop; we slam it shut with content creation, monitoring and attribution.

Sorry Skynet, not today

Once a story's worth writing, the create step takes its core idea and writes a genuinely new article from it. This is not a content mill. The entire prompt is built around originality - it pulls from multiple sources of inspiration and is forced to differentiate hard from any one of them; the goal is a unique, multi-faceted piece, not a spun rewrite. And nothing is automatic.

Everything is human-gated: a person reviews, edits, and signs off, and the tool is deliberately built to make them think, not to take their hands off the wheel.

The draft lands directly in his WordPress as a draft, in clean HTML, so the edits are minimal. Plus, the same client runs my Citation_needed tool alongside this, so the briefs that feed the hub arrive with the SEO groundwork already in them.

Let’s just please wrangle the clanker

At times, I felt like a kid at a candy store holding a crisp $100 bill, but I had to stay disciplined with model and token choice. Since the client was already using Ahrefs, it wasn’t hard to use the API and allow for keyword research before writing the news, as well as checking the article post-publishing on demand. The keyword is on-demand because I don’t want refreshes or unnecessary queries to eat up the usage limits.

After running the comparisons for token usage, I showed the client output quality against token cost, side by side. Sonnet 4.6 with a heavy-handed system prompt was the clear winner.

Caching rates (same across models): a cache read costs ~0.1x the input rate, a cache write ~1.25x (5-min TTL). So a cached system prompt on Sonnet 4.6 reads at ~$0.30/1M instead of $3.00.

As a result, this amounted to the following daily, weekly and monthly costs at various rates of content creation. Assumes ~8k input + ~1.5k output tokens per article at Sonnet 4.6 rates ≈ $0.05 per article (caching would push it lower). Weekly = daily x 7, monthly = daily x 30.

Around the same time, I ran into a roadblock. Even though we wanted the News Radar to refresh every 5 minutes, the Firestore database started burning 50k reads a day, so I had to pivot and turn it down to 20 minutes, reducing the daily reads to ~13k. With that out of the way, the time of reckoning was at hand.

A newsroom reborn

So logically, I figured it was time to close out the final part of the loop. After publishing an article, the tracking takes care of itself. The hub subscribes to the client's own RSS feed, so the second anything goes live, it gets picked up and wired into Ahrefs, Google Analytics, and Search Console.

A story gets marked as published by a writer, tagging the cluster and associating it with a corresponding live link in the Tracking tab.

So, with the client now knowing how to find, judge, prioritize, write, and track motorsports news stories, how did they actually do with their new hub?

In just the first week of testing the beta, the entire team was already reporting the opposite of a farm: writers suddenly had hours back to chase interviews and make the coverage more exclusive. The owner was able to redirect resources into sending representatives at events, further bolstering the News Feed with visual pizzaz and exclusivity.

Time-wise, the average time-to-publish (TTP) for stories of all sizes went down by an average of 64%: