От Telegram-бота к web-приложению: как я перестал бороться с Excel и начал строить систему

От Telegram-бота к web-приложению: как я перестал бороться с Excel и начал строить систему

Привет! Меня зовут Денис, я работаю аналитиком потерь на складе. В какой-то момент я устал от постоянной работы с Excel-выгрузками и решил автоматизировать процесс.

Всё началось с простого Telegram-бота, а закончилось полноценным web-приложением с отдельным backend, интеграциями и удобным интерфейсом.

Сегодня я расскажу, как из скрипта для одной задачи постепенно выросла целая система.

Как всё начиналось

Изначально задача была типичной: регулярно обрабатывать несколько Excel-файлов — объединять, очищать, приводить к единому виду.

Процесс был утомительным и плохо масштабировался.

В какой-то момент я понял: я работаю не аналитиком, а интерфейсом между Excel-файлами.

На рутину уходило около 5 часов в день — примерно 150 часов в месяц.

При условной ставке 500 ₽/час это 75 000 ₽ в месяц на чистую работу с файлами.

Я создал простой MVP — Telegram-бота на Python, который принимает файлы и возвращает обработанный результат.

Решение оказалось быстрым и удобным: не нужно было делать отдельный интерфейс, пользователи уже были в Telegram, а логика оставалась под контролем.

Но вскоре начали проявляться ограничения.

Почему Telegram перестал быть достаточным

Проблема была не в самом боте, а в том, что он стал выполнять функции, для которых не предназначен.

По мере усложнения логики стали очевидны следующие недостатки:

  • файлы упирались в лимиты Telegram (20 МБ)
  • обработка превратилась в «чёрный ящик»
  • не хватало нормального интерфейса
  • развитие функциональности стало сложным
  • частые проблемы с доступом в РФ из-за блокировок

Стало ясно: Telegram — отличный вход, но плохое ядро системы.

Тогда я начал выносить логику за пределы бота.

Переход к web-приложению

Я не переписывал всё с нуля. Постепенно переносил ответственность из бота в отдельный backend.

Telegram остался как один из способов взаимодействия, но теперь он просто передаёт задачи в систему.

Появился web-интерфейс, где можно:

  • загружать файлы
  • видеть статус обработки
  • управлять процессом

Впервые проект стал ощущаться как настоящая система, а не как скрипт.

Архитектура

Система разделилась на несколько уровней:

backend — обработка данных и бизнес-логика,
frontend — взаимодействие с пользователем,
интеграции — Google Sheets, Яндекс.Диск — для хранения и передачи файлов.

Telegram стал просто одним из клиентов. Это упростило развитие: можно менять интерфейс, не затрагивая логику, и наоборот.

Прямое подключение к БД невозможно из-за политик компании — доступ через Proxy недоступен на моей должности.

Работа с большими файлами

Один из переломных моментов — ограничение в 20 МБ в Telegram.

Я добавил интеграцию с Яндекс.Диском через OAuth. Теперь бот принимает ссылку, а backend скачивает файл напрямую.

Это оказалось стабильнее и быстрее, чем пересылка через мессенджер.

UX: о чём легко забыть

Когда делаешь внутренний инструмент, соблазнительно не думать об интерфейсе.

Я тоже так делал. Но после появления web-интерфейса стало ясно: даже простые вещи влияют на использование.

Индикатор обработки, понятные кнопки, адаптация под мобильные — всё это решает, захочется ли пользоваться системой каждый день.

Это не про красоту, а про удобство и мотивацию.

Среда разработки: неожиданный поворот

Раньше я использовал PyCharm — отличный инструмент для анализа данных и отладки.

Но в ходе проекта перешёл на Cursor — редактор с встроенными AI-агентами.

Это изменило процесс разработки.

Теперь я делегирую агентам:

  • генерацию шаблонного кода
  • простые рефакторинги
  • обвязку для новых функций

Это ускорило разработку. Но для анализа данных и глубокого ресёрча PyCharm пока остаётся удобнее.

Сейчас использую гибрид: рутину — через агентов, сложный анализ — в классической среде.

Планирую попробовать Claude Code и n8n — интересно сравнить подходы, особенно с добавлением ИИ в обработку данных.

Что получилось в итоге

Проект прошёл типичный путь:

сначала — инструмент «под задачу»,
потом — усложнение логики,
затем — переход к архитектуре.

Результат: команда аналитиков экономит 150 часов в месяц.

Ключевой момент — переход от Telegram как центра системы к независимому backend.

После этого стало возможно развивать продукт: добавлять интерфейсы, интеграции и новые сценарии без страха, что всё сломается.

Что я понял

Главное — не пытаться сразу строить идеальную архитектуру.

Рабочий путь:

  • сначала — быстрое решение
  • потом — постепенное выделение ответственности
  • и только потом — осознанная структура

И ещё: инструменты разработки реально влияют на скорость и подход. Переход к AI-агентам оказался не хайпом, а практичным шагом.

Что дальше

Планирую двигаться в сторону:

  • аналитики поверх данных
  • BI-отчётов в web-интерфейсе
  • контейнеризации через Docker
Читать оригинал