Case Study: How We Built A Production AI News Bot Serving Thousands
This is the story of how we built a production AI news aggregator on Telegram that processes content from 11 sources and 6 social media accounts, delivers personalized news to thousands of users, and runs on lean infrastructure. No theoretical framework. No hypothetical scenarios. Real metrics from a real bot we built and operate.
- 11 news sources aggregated automatically
- 6 social media accounts monitored continuously
- 260+ articles processed per cycle
- 59+ curated social posts delivered per cycle
- 90%+ read rate on delivered content
- Lean infrastructure — kept hosting costs minimal
- $1.99/month pro tier with 3–4% free-to-paid conversion rate
- Went from concept to live users in under 24 hours
The Challenge
AI news moves fast. Professionals following the space — developers, founders, researchers, investors — spend 30–60 minutes daily scanning multiple sources: tech blogs, research papers, social media accounts, newsletters, and aggregators. The signal-to-noise ratio is terrible. Most content is recycled, low-quality, or irrelevant to any given reader's interests.
The challenge: build a system that automatically aggregates content from diverse sources, filters for quality and relevance, categorizes by topic, and delivers a personalized digest to each subscriber via Telegram. It needs to work reliably, scale with the user base, and cost virtually nothing to operate.
The constraints we set:
- Speed: From idea to live users in under 24 hours (we hit it)
- Quality: AI-powered filtering, not just keyword matching
- Reliability: Runs autonomously with minimal human intervention
- Cost efficiency: Lean infrastructure that doesn't scale linearly with users
- Personalization: Each user gets content relevant to their interests, not a firehose
The Solution
We designed a three-stage pipeline: aggregate, enrich, deliver.
Stage 1: Aggregate
The bot pulls content from 11 distinct sources — a mix of RSS feeds, social media accounts, and curated publication lists. Each source has its own ingestion schedule based on how frequently it publishes. High-frequency sources get checked more often. Low-frequency sources get checked less often to avoid wasted processing.
Social media integration monitors 6 specific accounts that consistently surface high-quality AI content. This isn't just link scraping — the system captures the context and commentary that makes social posts valuable, not just the URLs they share.
Stage 2: Enrich
Every piece of content passes through an AI enrichment pipeline. The AI evaluates each item for: relevance to AI/ML topics, quality and depth of analysis, novelty (is this saying something new or recycling?), and appropriate categorization.
This is where most "news aggregator" bots fail. They dump everything into a channel and let the user sort through it. We flip that: the bot does the sorting so the user only sees what matters. The enrichment step is the difference between a useful tool and a noise machine.
Enrichment runs on a managed AI API, processing articles one at a time to stay within strict compute budgets. The AI call takes roughly 3 milliseconds of compute per article — fast enough to process hundreds of items per cycle without blowing past platform constraints.
Stage 3: Deliver
Delivery happens in two channels: a public channel for broad distribution and individual user chats for personalized content. The delivery pipeline handles deduplication (don't send the same story twice), formatting (clean, scannable messages with proper structure), and personalization (each user's digest reflects their subscribed topics).
A critical design decision: delivery runs before enrichment in the pipeline priority order. If the enrichment step fails or times out (which happens under load), users still get their previously enriched content delivered on time. The expensive AI step is important but not time-critical — delivery is.
The Results
After months of continuous operation, here's where the numbers stand:
| Metric | Result |
|---|---|
| Articles processed per cycle | 260+ |
| Social posts curated per cycle | 59+ |
| Content read rate | 90%+ |
| Infrastructure cost | Lean — minimal hosting spend |
| Pro tier pricing | $1.99/month |
| Free-to-paid conversion | 3–4% |
| Time from concept to live | Under 24 hours |
| Time to production-grade | ~2 weeks (iterating on onboarding, delivery, error handling) |
The 90%+ read rate is the headline number. Compare it to industry benchmarks: email newsletters average 15–25% open rates. Twitter impressions are a fraction of followers. Even push notifications on mobile apps see 40–60% delivery rates. Telegram's direct message format, combined with content that's genuinely relevant to each user, produces engagement numbers that other channels can't match.
The 3–4% free-to-paid conversion rate at $1.99/month indicates that users find enough value to pay, and the freemium model gives them enough utility to stay engaged before converting. This conversion rate is healthy for a content product — most news apps and newsletters convert at 1–2%.
Architecture Overview
The system runs on edge hosting — the same infrastructure that powers web applications globally, repurposed for bot operations. The architecture is deliberately simple:
- Ingestion layer: Scheduled tasks pull content from all sources at their configured intervals. Each source has its own adapter that normalizes the content format.
- Processing layer: AI enrichment runs on a managed AI API. Articles are processed one at a time to maintain strict compute budgets. The enrichment result is stored in a managed database alongside the original content.
- Delivery layer: A separate delivery pipeline pulls enriched content, formats it for Telegram, and sends it to subscribers. Delivery runs independently of enrichment — if the AI is slow, delivery isn't blocked.
- User management: Subscription preferences, topic selections, and delivery schedules are stored per-user in the managed database. Users configure their preferences directly through the bot interface.
- Monitoring: Automated alerting on delivery failures, processing errors, and performance degradation. When something breaks, we know before users complain.
The entire stack — ingestion, processing, delivery, database, monitoring — runs on lean infrastructure. We're not spending hundreds on cloud services. The architecture is designed to scale efficiently, and it does.
Lessons That Apply To Every Bot
Building and operating this bot taught us things that apply to any Telegram bot project, regardless of use case.
The Prototype Is Fast. The Polish Takes Time.
We went from idea to live users in under 24 hours. But the bot wasn't production-grade for another two weeks. The last 20% — onboarding flow, error handling, edge case testing, delivery reliability, monitoring — takes as long as the first 80%. Budget for it.
Delivery Before Enrichment.
In any pipeline where an expensive step (AI processing, data enrichment, image generation) feeds into a time-sensitive delivery, run delivery first with cached results. If the expensive step fails, users still get served. If delivery waits for enrichment, failures cascade and users see nothing.
Read Rates Matter More Than User Counts.
A bot with 10,000 subscribers and a 10% read rate reaches 1,000 people. A bot with 1,000 subscribers and a 90% read rate reaches 900 people — with much higher engagement per user. Optimize for engagement, not vanity metrics.
Lean Infrastructure Is An Architecture Decision, Not An Afterthought.
We didn't accidentally end up with low hosting costs. We designed for it from the start: edge hosting, managed database on a free tier, efficient AI processing, and a pipeline that avoids unnecessary compute. Lean infrastructure is the result of deliberate architecture choices, not luck.
Maintenance Is Non-Negotiable.
Content sources change their format. APIs get updated. Edge cases surface under load. User behavior shifts. Our bot requires ongoing maintenance — roughly 2–4 hours per week of monitoring, fixing, and improving. Any production bot does. If you're not budgeting for maintenance, you're budgeting for decay.
Frequently asked questions
What does a production Telegram bot architecture look like?
A production Telegram bot typically uses a serverless backend (like Cloudflare Workers or AWS Lambda), a database for user preferences and content, an LLM API for content enrichment, and cron-based scheduling for automated delivery. The architecture is designed for reliability, low cost, and horizontal scaling.
How do you measure the success of a Telegram bot?
Key metrics include read rate (percentage of delivered messages that are opened), conversion rate (free to paid), daily active users, message delivery reliability, and user retention over time. A well-run content bot typically achieves read rates above 80%, significantly higher than email newsletters.
Can a Telegram bot handle thousands of users on a small budget?
Yes. Serverless infrastructure keeps costs extremely low because you only pay for actual compute time. A bot serving thousands of daily users can run on under USD 10 per month in infrastructure costs. The key is batching expensive operations like LLM calls and running them once rather than per user.
What are common pitfalls when building a Telegram bot at scale?
Common pitfalls include race conditions in cron-based delivery pipelines, silent failures in serverless cron triggers, bot token revocations that go unnoticed, and caching issues that bloat server storage. Robust monitoring, error alerting, and staging environments are essential to catch these before users do.
Ready To Build Your Telegram Bot?
Tell us about your idea. We'll scope it and give you an honest timeline.
Let's Talk →or message us on Telegram