English Boss Telegram Bot

The business problem

Practice apps are opened enthusiastically for a week and then not at all. There is more good material available free than anyone can use, and almost nobody keeps a daily habit unaided. Any design that waits for the learner to initiate is competing with everything else on their phone and losing; the exercises are the easy part, and getting someone to do the fourth week is the problem worth solving. A standalone app makes that harder still, because it has to be installed, opened and remembered, and each of those is a point where the learner leaves. Delivering the practice through a chat platform removes all three, but it moves the problem: the bot has to handle updates reliably, keep per-learner state and schedule sends with no UI to fall back on.

What I delivered

• A FastAPI service receiving Telegram updates on a webhook rather than polling, so delivery is push-driven and cheap to run.
• Scheduled practice sessions and reminders that reach the learner rather than waiting to be opened. This is the mechanism the whole system depends on.
• Short exercises, including speaking exercises, sized for the gaps in a day, since a session that requires a free half hour will not happen.
• Progress tracking, streaks and gamified feedback, plus a performance review across sessions, so the practice has a visible trajectory and the streak itself becomes a reason to continue.
• IELTS-oriented routines for learners working toward a specific exam, kept apart from general practice.
• A bot layer with its own handlers, keyboards and message content, kept apart from the backend that holds state and scheduling.
• An OpenAI integration for the assessment and feedback portion, isolated behind its own module rather than called from the handlers.
• A container and process definition, so the service deploys as a unit rather than as a script somebody runs.

Technical approach

• I treat the scheduler as the core feature and everything else as content for it. That is the inversion the category usually gets wrong, and it decides the architecture.
• Webhook rather than polling. Polling burns resources continuously to discover that nothing has happened, and it scales badly for something that is idle most of the time.
• The bot layer knows about Telegram and the backend knows about learners. Keeping that boundary is what would allow a second platform without rewriting the practice logic.
• I isolated the model integration in one module, so changing provider or model is a contained edit rather than a change across every handler.
• I keep message content out of the handler logic, since copy changes constantly and the logic should not be touched when it does.
• Sessions are deliberately short. Completion rate matters more than session length, because the habit is what compounds.
• I make progress visible because the effect of practice is invisible day to day, and invisible progress looks exactly like no progress.
• I keep exam-oriented routines separate from general practice, since the two have genuinely different structures and success criteria.

Result and evidence

Practice, reminders and feedback are delivered inside Telegram through a webhook service, with the platform layer, the state layer and the model integration kept separate, and the learner can see their progress across sessions. What was verified is the delivery mechanism and the layering; no retention figure was measured for this write-up, so the fourth-week claim is the design target rather than a reported result.

Commercial value

Any product in this space competes with free content, and the differentiator is not the material but whether the learner is still using it in week four. Meeting them in an app they already use is worth more than any feature a standalone app could offer, because it removes the hardest step in the funnel.