Building an AI Telegram Bot That's Helped 10,000 Students: Lessons Learned

When I started EnrollAI in 2023, I had a simple problem to solve: India's 16 million NEET and JEE aspirants were drowning in expensive coaching classes, fragmented resources, and the inability to get instant feedback on their doubts. After 14 years of mentoring students directly, I knew exactly what they needed. So I built a Telegram bot.

Today, EnrollAI has 10,000+ active users solving curated MCQs and getting AI-powered explanations for their doubts. But the journey to get here wasn't straightforward. Let me share the technical and strategic lessons that shaped this product.

Why Telegram? Why Not a Native App?

My first instinct was to build a web or mobile app. But after talking to 200+ students, I realized they already lived on Telegram. It's where they connect with peer groups, share resources, and spend hours daily. Building on Telegram meant zero friction for onboarding — no app store approval, no installation barriers, just one tap to start.

The technical decision paid off. We achieved 8,000+ users in 4 months without a single dollar spent on acquisition. Peer-to-peer sharing did the heavy lifting.

Architecture: Simplicity at Scale

Our tech stack is deliberately lean:

Python with Telegram Bot API (using python-telegram-bot library)
SQLite for question storage and user progress tracking
spaCy and NLTK for NLP-based doubt classification
FastAPI for backend services running on a single Ubuntu server

We deliberately chose SQLite over PostgreSQL initially. Was this a mistake? Partially. At 10,000 users with ~50,000 queries/day, SQLite started showing its limitations around concurrent writes. But the lesson here is important: start simple, scale when you hit real bottlenecks, not imagined ones.

In month 8, we migrated to PostgreSQL. The migration took 2 weeks because our data model was clean and our ORM queries were straightforward. Premature optimization would have cost us months of engineering time we didn't have.

The Question Bank: Quality Over Quantity

We launched with 2,000 MCQs. Today we have 10,000+. But the real differentiator isn't the number—it's the metadata.

Each question is tagged with:

Topic and subtopic (e.g., "Organic Chemistry > Alkanes > Nomenclature")
Difficulty level (beginner, intermediate, advanced)
Success rate (what % of users answer correctly)
Common misconceptions (extracted from user responses)
Detailed explanations (written by subject matter experts, then validated by AI)

This taxonomy took 3 months to build properly. We use a PostgreSQL jsonb field to store tags, enabling fuzzy matching for NLP queries. When a student asks "Why do benzene rings not undergo addition reactions?", our NLP engine classifies it under Organic Chemistry > Aromatics > Stability, then retrieves the 3-4 most relevant MCQs and written explanations.

# Simplified NLP classification logic
def classify_doubt(user_query):
    doc = nlp(user_query)
    entities = extract_entities(doc)
    topic_vector = encode_topic_context(entities)
    closest_topics = find_nearest_topics(topic_vector, threshold=0.75)
    return closest_topics

The Doubt-Solving Engine: Where NLP Met Reality

Our initial NLP pipeline was overly complex. We tried fine-tuning a BERT model on our question dataset. It took 2 weeks to set up, consumed 60% of our server resources, and improved accuracy by only 3% over a simpler TF-IDF + cosine similarity baseline.

The lesson: Occam's Razor applies to ML too. We reverted to a hybrid approach:

TF-IDF vectorization on question text and tags (fast, interpretable, 87% accuracy)
Fallback to keyword matching for edge cases
Manual curation for the remaining 5% of queries that need human review

This stack processes doubts in under 200ms, costs next to nothing to run, and is easy for anyone to understand and debug.

Scaling Challenges We Actually Hit

Challenge 1: Telegram API rate limits. We were hitting rate limits at 3,000 concurrent users. Solution: Implement a message queue (Bull.js initially, now Redis) with workers processing messages asynchronously. Doubled our throughput overnight.

Challenge 2: Cold start latency. Users asked "How long for an answer?" The first 10,000 queries took 5-8 seconds. We were loading the entire question bank into memory on every request. Solution: Cache the top 500 questions + implement lazy loading. Now average response time is 400ms.

Challenge 3: Misinformation. A user pointed out a factually wrong explanation in our chemistry section. We had no validation workflow. Now every explanation is reviewed by at least 2 subject experts before being pushed live.

What Actually Drove Growth

It wasn't the fancy tech. It was:

Word of mouth from actual students (72% of new users)
Free access (no paywall or freemium trap)
Speed (instant doubt-solving beats waiting for a tutor reply by hours)
Accountability (showing students their progress over time)

Our best feature? A simple dashboard showing "You've solved 342 questions this month. Your accuracy in Biology improved from 68% to 74%." Data-driven feedback works.