I built an AI news aggregator for Telegram in 2 weeks — here's how it works
I was spending an hour every morning switching between 20+ browser tabs to monitor energy news from sources in Russian, English, Arabic, and Chinese. I wanted everything filtered, translated, and delivered automatically to Telegram.
So I built it.
The hardest part wasn't the AI — it was not losing a single article
Different sources update with different delays — some RSS feeds update instantly, others lag by 40-50 minutes. If you just grab "everything new since last check" you miss articles that fall outside the window.
My solution: a buffer system that looks back a fixed time window every cycle. Articles already sent are deduplicated by URL and content hash. Result: the system catches 93-94% of delayed articles without sending duplicates.
How the filtering works
Two stages:
1. Keyword pre-filter — eliminates 80-90% of irrelevant content instantly, no AI needed
2. LLM classifier — processes the grey zone with a 5-provider fallback chain (Groq → Gemini → Mistral → OpenRouter)
Plus a semantic filter using fastembed (ONNX, CPU-only) that understands meaning, not just keywords.
Results so far
- 100,000+ articles processed
- 300+ sources in 22 languages
- Running without interruption since moving to VPS
What it does beyond just sending news
- /search — full-text archive search with FTS5
- /alert — personal keyword notifications
- /top — trending topics of the day
- /source — digest by specific publisher
- Sentiment on every post (📈📉😐)
Now offering it as a done-for-you service
You tell me your niche, I configure the sources and AI filter, your Telegram bot is live in 96 hours.
Currently onboarding first clients at early pricing.
Demo bot (energy news archive): t.me/ainewsdemobot
Landing: lively-rabanadas-3c1f0a.netlify.app
Happy to answer any questions about the tech or the business!
informative
This is strong technically, but distribution is doing almost all the heavy lifting here and it is still invisible outside a niche builder circle. Telegram bots can scale quietly, but they rarely build perceived authority unless there is a clear “this is the default for X niche” signal.
Also the real constraint is not filtering or pipelines, it is whether users trust the selection layer enough to replace their own scanning habit. That switch usually takes more credibility than infra.
Both points land.
On distribution — you're right, it's invisible outside builder circles right now. That's partly intentional: I'm starting with niche Telegram channel owners who already have the audience and just need the feed. The "default for X niche" signal has to come from somewhere, and I'm betting it comes from one visible channel per niche that everyone else watches.
On trust — this is the harder problem and I don't think infra solves it. What I'm actually selling is my curation judgment baked into the filter config. The first few clients will either trust that or they won't. If they don't, no amount of pipeline reliability will compensate.
Honestly still figuring out how to make that trust legible before someone tries it. Open to thoughts if you have them.
this feels less like a news bot and more like a trust system for filtering reality per niche
distribution will decide if it becomes infra or just another tool
Two weeks is impressive.
Looking back, was building the product actually the hardest part, or getting people to consistently use it every day?
Honestly, building was the easier part — two weeks of clear technical problems with clear solutions.
Getting consistent usage is harder because the feedback loop is slower and the signals are noisier. You don't know if someone stopped using the bot because the filter was wrong, the topic was too niche, or they just got busy.
The one thing I've learned so far: the filter quality determines everything. If someone gets 3 irrelevant posts in a row on day 2, they mute the bot silently and you never know why. Getting the filter right for a specific niche takes iteration with real users — which you can't do until someone actually uses it daily.
So the honest answer: building was hard but finite. Getting consistent usage is an ongoing problem I haven't solved yet.
That really resonates.
One thing I've started noticing is that retention often tells you whether you're surfacing the right signal, not just whether you've built a useful product. If someone keeps coming back, it's usually because the product consistently helps them notice something they would have missed on their own. Once that value becomes predictable, the habit starts forming naturally.I'm curious, have your most active users ended up refining the filters in similar ways, or does each niche seem to develop its own definition of what's actually "relevant"
"optimizing who I was talking to" - that's the reframe that unlocks a lot. most builders iterate on the pitch and wonder why conversion stays flat. the person who does the work every morning doesn't need convincing, they're already sold by the problem.
Exactly — and it's a reframe that's easy to miss because iterating on the pitch feels like progress. You're writing, testing, adjusting. It looks like work.
Figuring out who actually feels the pain is less visible but does more.
The tell for me was the block rate. Ad managers blocked immediately — no amount of better messaging would have changed that. The author who replied didn't need convincing at all, just needed to know the tool existed.
Right contact beats right message. I've pitched internal tools where we started with legal and got nowhere. Same pitch to the team actually doing the broken workflow, sold in a week. Pain-feeler and gatekeeper don't often overlap.
"Pain-feeler and gatekeeper don't often overlap" — that's the clearest version of this lesson I've seen.
The blocks I got were from ad managers who feel zero pain from manual news monitoring. The one reply came from the author who does it every morning.
Same product, same message, completely different outcome based on who received it. I was optimizing the pitch when I should have been optimizing the recipient.
Right contact beats right message. I've pitched internal tools where we started with legal and got nowhere. Same pitch to the team actually doing the broken workflow, sold in a week. Pain-feeler and gatekeeper don't often overlap.
really cool project
thanks
Nice build. How are you pulling the sources — RSS/APIs or scraping the sites directly? If it's direct scraping, the thing that bites at volume is anti-bot (Cloudflare/DataDome) blocking the aggregator's IP once it ramps up, and you get silent gaps in the feed without errors. Worth checking early which sources actually challenge you.
Mix of both — RSS where available (majority of sources), direct scraping for sites that don't publish feeds.
The silent gap problem is real and something I've already hit. A source just stops delivering without throwing an error, and you only notice when a reader asks "why no news from X lately."
Current mitigation: sources_health.json tracks per-source success rates across cycles. Anything that drops below threshold gets flagged. Not perfect but catches most silent failures before they become reader-visible gaps.
Cloudflare/DataDome at scale is the next wall I haven't hit yet — rotating user agents and request timing helps for now, but I know that breaks down at volume. Any patterns you've seen work longer-term?
The sources_health.json approach is the right instinct — I'd just split "blocked" from "genuinely quiet" in it. A challenge page often comes back as a 200 with challenge HTML, so a naive success check counts it as alive while the feed silently dries up. Logging the response signature (status + a marker for challenge HTML / DataDome JS) lets health tracking flag a block separately from a slow news day.
On the longer-term wall: UA + timing stops working because the heavy fingerprinting isn't in the headers. The two that actually move the needle:
- TLS/JA3 fingerprint. A default Python or Go HTTP client has a handshake that screams "not a browser" no matter what UA you send — Cloudflare reads that before anything else. Switching to curl-impersonate (or a tls-client that mimics a real Chrome handshake) buys you far more than any UA list.
- IP type per source. Datacenter IPs get challenged regardless; residential/mobile clear most of it. But you don't need residential everywhere — only the sources that actually challenge. That maps onto what you already do: add an "anti-bot type" field per source, route just the hard ones through the expensive path, keep the RSS/easy ones on plain requests.
DataDome is the nastier of the two — it leans on TLS plus behavioral signals and usually wants a cookie from a real challenge solve, so for those few sources a headless browser ends up cheaper than fighting it.
I actually built a small tool around that first step — detecting which anti-bot a source sits behind — since deciding the route is the annoying part. Happy to go deeper on any of it.
The "200 with challenge HTML" blind spot is exactly what I suspected was happening but hadn't pinned down. Logging response signature alongside status code is the obvious fix I missed — adding that to sources_health.json this week.
The TLS/JA3 point is new to me and explains a lot. I've been treating headers as the main fingerprint surface when apparently Cloudflare reads the handshake before it even looks at headers. curl-impersonate is going on the list immediately.
The per-source routing idea maps cleanly onto what I already have — sources are individually tracked, so adding an anti-bot type field and routing accordingly is straightforward. Most of my sources are RSS anyway, so the expensive path would only apply to maybe 10-15% of them.
DataDome I've only hit once so far. Headless browser as a last resort for those specific sources makes sense — fighting the cookie challenge programmatically sounds like diminishing returns.
I'd genuinely be interested in the detection tool you built. Knowing which anti-bot sits in front of a source before deciding the route would save a lot of trial and error. What does the detection output look like?
Honestly it's less clever than that — it's just a request tester. You give it a URL, set the method/headers, and send. You can route the request either through the proxies the site has built in, or paste your own list and run through those.
If the target has anti-bot in front, it'll highlight which one it spotted. It doesn't cover every protection yet — I keep adding them as I hit new ones — but it catches the common Cloudflare / DataDome / PerimeterX cases.
The part that's actually useful day to day: fire the same request through different proxies and see which ones come back clean and which one trips the protection. That alone solves a chunk of the problem — half the ypass, you just need the proxy the site doesn't botherchallenging.
Free, runs in the browser: parsistent.com (Request Tester).
What sites are fighting you the most right now? Drop a couple and I'll run them through with you — half the battle is just finding which proxy they don't challenge.
With AI today, our lives are much easier; we just need the ability to choose the tool that truly solves our problem. Congratulations on the tool and best of luck on the journey that is now beginning...
Exactly — the hard part isn't building AI tools anymore, it's finding the specific workflow where they actually replace real daily pain instead of adding another tab to manage.
Thanks for the kind words, appreciated.
Two weeks to launch is insane velocity. The distribution via Telegram is smart — no App Store gatekeeping. How are you thinking about retention? Day 1 to Day 7 drop-off is brutal for aggregators. What keeps people coming back?
Retention lives or dies on filter quality. If someone gets 3 irrelevant posts in a row on day 2, they mute the bot and never come back.
What I think helps: /alert turns passive readers into active users with a reason to stay. And if your bot is the reason you knew about something before your competitors — that becomes a habit fast.
Don't have week 1 data from paying customers yet. What signals would you watch specifically?
Mute rate (week 1) is the real leading indicator. If >30% mute by day 3, your filter is broken. Click-through lag matters too — if users take >2hrs to click, they've moved on. And repeat clickers: same 5 users engaging multiple times means the core is sticky, but you're not expanding. Frequency sweet spot wins the retention game.
You already broke the cold-start loop and missed it: you run a working energy-news channel built on this bot, so that channel is your credibility, not a landing page. Grow it in public as the default feed for that one niche and channel owners will come asking how you do it instead of blocking your DMs. Stop cold-messaging strangers and let your own output be the proof, because nobody trusts a curator they have never watched curate.
This reframe landed hard.
I've been treating the energy channel as a legacy project separate from the business, when it's actually the only proof-of-work I have that anyone can watch in real time.
The difference between "trust me, my bot works" and "you've been reading my bot's output for 3 months" is the entire credibility gap I've been trying to close with cold messages.
Growing it deliberately as a public demo makes more sense than anything else I've tried this week.
This is a strong shift — you stopped “selling” and started targeting real pain.
What worked is specificity. When you name their actual sources, it shows you understand their workflow, not just sending a generic pitch.
Your signals are good, but the strongest one is repeated manual work (daily translating, aggregating). That’s where real pain is.
And yes, contact point matters a lot. You need to reach the author, not the ad manager — they’re the one who feels the problem.
Next step is scaling this: finding clusters of channels with the same workflow instead of analyzing each one manually.
Exactly — the shift from "here's my product" to "I see your specific workflow" changed everything. Naming their actual sources wasn't a trick, it was proof that I understood what their morning actually looks like.
The repeated manual work signal is the one I'm now prioritizing. High post frequency + low forward ratio (tip from another commenter here) + foreign sources in recent posts = someone who's translating and rewriting every day. That's the pain.
On scaling — this is the next real problem. Right now I'm analyzing each channel manually which doesn't scale past 20-30 prospects. The cluster idea is interesting: if I can find one channel with this workflow, there are probably 5-10 more in the same niche with identical pain.
Do you have a mental model for how to identify those clusters without going channel-by-channel? Whether it's cross-referencing sources, tracking who cites who, or something else entirely.
Interesting idea and execution
One thing I'd be curious about is whether the valuable thing you've discovered is the system itself or the ability to configure it for a specific niche.
Reading this, I found myself noticing a shift from product to service near the end, and those can end up implying very different things about where the value actually lives.
That's the part I'd be most interested in learning from the first clients.
Great observation — I'm still figuring this out myself.
My gut says the system is the foundation, but the niche configuration is where the real value lands. A generic news feed is noise. Tuned to your exact industry and sources — that's signal.
Honestly, I'm offering it as a service right now specifically to learn from the first clients what they actually value most. The first 3-5 will tell me more than any theorizing.
What's your intuition on it?
That's actually where I'd be hesitant to assume the first few clients will necessarily resolve it.
Sometimes the same client outcome can support very different explanations for where the value is actually coming from.
A founder sees a client succeed and concludes it was the system.
Another sees the same outcome and concludes it was the configuration.
The visible result looks similar. The next decision doesn't.
I've got a few thoughts on that, but it's probably more than I'd try to unpack properly in a thread.
What's the best email to reach you on?
That's a fair point — the same outcome really can support opposite conclusions, and I'd probably need several clients with different contexts to start separating signal from noise. Would genuinely enjoy unpacking that further. You can reach me at i9859093395@gmail . com
Appreciate it. Just sent over a note.