From Telegram Bot to Scalable Web App: The Evolution of an Internal Tool
A warehouse loss analyst faced a routine task: daily processing of multiple Excel files required 5 hours per day or 150 hours per month. This represented significant time costs. The solution was an MVP in the form of a Python Telegram bot: users sent files, the bot returned processed results. The processing logic remained under developer control, with no interface needed.
This approach worked initially: Telegram provided quick access without requiring a UI. However, as complexity grew, limitations became apparent.
Limitations of Telegram as a System Foundation
Telegram isn't designed to serve as a system's central core. Problems emerged quickly:
- The 20 MB file limit blocked large uploads.
- Processing became a "black box" with no status visibility.
- There was no proper interface for management.
- Feature development became more complicated.
- Access issues in Russia due to regulations.
Telegram worked as an entry point, but not as a core. The solution was moving the logic to a separate backend.
Gradual Transition to a Web Application
The transition wasn't a complete refactor: the bot remained as a client but delegated tasks to the backend. A web interface emerged with capabilities:
- Uploading files of any size.
- Tracking processing status.
- Managing processes.
The project gained system characteristics: separation of responsibilities simplified development. The backend handles data and business logic, the web part handles interaction, and integrations (Google Sheets, Yandex.Disk) handle storage and transfer.
Architecture: Layer Separation
The system is structured by layers:
- Backend: Data processing with pandas, business logic.
- Web Interface: API layer, frontend for users.
- Clients: Telegram bot as one interface.
- Integrations: OAuth for Yandex.Disk, Google Sheets API.
This separation allows changing interfaces independently of logic. Company policy restrictions (no direct database access without proxy) necessitated this approach.
Solving Large File Problems
The key moment was bypassing Telegram's limits. Integration with Yandex.Disk via OAuth: the bot accepts a link, the backend downloads and processes the file. This provided stability and speed without platform limitation dependencies.
UX for Internal Tools
Internal tools often ignore interface, but simple improvements are critical:
- Processing progress indicators.
- Clear buttons and forms.
- Mobile device adaptability.
This improves usability: the system becomes a tool for daily use.
Development Environment: From PyCharm to AI Agents
Development occurred in PyCharm for data research and debugging. Switching to Cursor with AI agents accelerated routine tasks:
- Generating boilerplate code.
- Simple refactoring.
- Wrapping new features.
Cursor is effective for architecture and web development. PyCharm remains for deep data analysis. A hybrid approach: AI for automation, classic tools for complex tasks. Testing Claude Code and n8n for AI integrations in data processing is planned.
Results and Savings
The system saved 150 hours monthly for the analytics team. The key shift was abandoning Telegram as the center: adding interfaces and integrations became possible without risk of breakdowns.
What matters:
- Gradually extracting the backend from the bot made the system scalable.
- Yandex.Disk integration solved file limit problems.
- Separating UI and logic simplified development.
- AI agents in Cursor accelerated boilerplate development.
- The web interface added process control.
Lessons and Development Plans
Conclusions: start with MVP, then refactor as growth occurs. Don't build perfect architecture immediately. Tools like Cursor impact productivity.
Next: BI analytics in web, dashboards, Docker containerization. This is technical material for middle/senior developers building internal systems.
— Editorial Team
No comments yet.