python Case study
English Boss Telegram Bot
Telegram is where this audience already is, which removes the largest obstacle in the category — persuading someone to install and return to another app. The practice arrives in a conversation they have not muted.
The business problem
A practice app has to be installed, opened and remembered. Every one of those is a point where the learner leaves. Delivering the same practice through a chat platform removes all three, but moves the problem: a bot has to handle updates reliably, keep per-learner state, and schedule sends without a 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.
- A separated 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.
- Scheduled reminders and micro-sessions, which is the mechanism the whole system depends on.
- A container and process definition, so the service deploys as a unit rather than as a script somebody runs.
Technical approach
- 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.
- The model integration is isolated in one module so that changing provider or model is a contained edit rather than a change across every handler.
- Message content is separated from handler logic, since copy changes constantly and logic should not be touched when it does.
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.
Commercial value
Meeting learners in an app they already use is worth more than any feature a standalone app could offer, because the hardest step in the funnel is the one it removes.
Readable implementation brief
implementation_brief {
project: "English Boss Telegram Bot"
stack: "Python, FastAPI, Telegram Bot API, OpenAI"
delivery: "webhook, not polling"
layers: "bot (handlers/keyboards/messages) | backend
(state, scheduling) | model integration"
isolation: "OpenAI calls live in one module, not in handlers"
copy: "message content separated from handler logic"
deploy: "containerised with a process definition"
}What this project shows
The layering is what I would want reviewed: Telegram specifics, learner state and model calls are three separate concerns, and keeping them separate is what makes the thing extensible.
Choosing a chat platform over a standalone app was a distribution decision rather than a technical one, and distribution is usually the constraint that actually matters.