Первое, что нужно сделать сегодня
Раньше поиска подрядчика идёт спасение активов. Логика простая и она определяет весь порядок: код почти всегда можно написать заново, а утраченные данные и доступы восстановить невозможно. Переписать бота — это дни работы и понятные деньги. Потерять базу клиентов за два года или домен, оформленный на постороннего человека, — это потеря, которую не закрывают никакой сметой.
Поэтому сначала пять пунктов, и лучше сегодня.
1. Забрать доступы, пока диалог ещё возможен
Пока с исполнителем есть хоть какая-то связь — переписка, общий чат, ответ раз в неделю — просите доступы немедленно, одним коротким сообщением, без выяснения отношений. Список:
- Токен бота — выдаётся в @BotFather, там же его можно перевыпустить, если аккаунт создателя бота ваш
- Доступ к серверу или хостингу — панель управления, SSH-ключи, аккаунт в облаке
- Репозиторий с кодом — GitHub, GitLab или архив с файлами
- Доступ к базе данных — адрес, логин, пароль; либо выгрузка, если базу отдать нельзя
- Платёжные ключи — эквайринг, кассовый сервис, все API-ключи сторонних сервисов
Запрос доступов читается спокойнее, чем претензия, и чаще получает ответ. Это не отказ от требований по работе — это то, что делается в первую очередь.
2. Сделать резервную копию данных прямо сейчас
До любых экспериментов, перезапусков и попыток «просто перезагрузить сервер». Выгрузите базу, скачайте Google Таблицы в файл, сохраните экспорт из CRM. Пять минут работы закрывают самый дорогой из возможных сценариев. Копию положите туда, куда имеете доступ только вы.
3. Проверить, на кого оформлены хостинг и домен
Это важнее кода. Если сервер оплачивается с чужой карты и привязан к чужой почте, а домен зарегистрирован на исполнителя — вы не владеете инфраструктурой, на которой всё работает. Отключение произойдёт молча, в момент, когда закончится оплаченный период. Проверяется быстро: письма от хостера приходят на почту владельца, данные о домене видны через whois.
4. Ничего не удалять и не «чистить»
Соблазн навести порядок в чужих файлах возникает почти у всех, кто впервые заходит на сервер. Папка old, файл backup_final_2.py, непонятный архив на 200 мегабайт — то, что выглядит мусором, регулярно оказывается единственной копией рабочей версии. Не удаляйте ничего, включая логи и старые файлы конфигурации: часто именно в них лежат ключи и настройки, которых больше нигде нет.
5. Сохранить всю переписку с исполнителем
Экспортируйте чат в Telegram, сохраните почту, выгрузите переписку с биржи. Там лежит техническое задание — обычно в виде разбросанных сообщений, но это единственная существующая документация проекта. Новому подрядчику эта переписка сэкономит дни, а вам — деньги за эти дни.
Почему боты ломаются
Практика показывает: подавляющее большинство поломок банальны, не связаны с качеством кода и чинятся быстро. Первый день после падения ощущается как катастрофа, а по факту это чаще всего одна из семи причин ниже.
| Причина | Как выглядит | Время починки |
|---|---|---|
| Закончились деньги на хостинге | Бот молча перестал отвечать в конкретный день | Минуты после оплаты |
| Процесс упал и не перезапустился | Работал месяцами, потом резко замолчал | 1–3 часа с настройкой автоперезапуска |
| Поменялось API стороннего сервиса | Одна функция сломалась, остальное работает | 2 часа – 2 дня |
| Изменилась вёрстка сайта-источника (парсинг) | Бот отвечает, но данные пустые или неверные | 2 часа – 1 день |
| Истёк токен или сертификат | Ошибки авторизации, вебхук не приходит | 1–3 часа |
| Кончилось место на диске от разросшихся логов | Бот работает нестабильно, отвечает через раз | 1–2 часа с ротацией логов |
| Выросла нагрузка | Тормозит в часы пик, таймауты | 1–3 дня |
Четыре причины из семи вообще не про код. Если бот работал год и внезапно перестал — вероятность того, что дело в оплате, диске или упавшем процессе, выше, чем вероятность серьёзной архитектурной проблемы. Это стоит знать до того, как соглашаться на смету «перепишем всё с нуля за 200 000 ₽».
Отдельный случай: проект, собранный через ИИ
Всё чаще к нам приходят с прототипами, сделанными в Lovable, Cursor или Replit. Сразу скажем прямо: собрать прототип через ИИ-конструктор — нормальный и разумный способ проверить идею. Это быстро, дёшево и позволяет понять, нужен ли продукт вообще, до того как в него вложены сотни тысяч. Проблема возникает не от метода. Проблема в том, что рабочий прототип понравился, показал первые заявки — и его пустили в продакшен без доводки, потому что «оно же работает».
Что в таких проектах ломается предсказуемо:
- Секреты и ключи прямо в коде. Токен бота, пароль от базы, ключ эквайринга лежат текстом в файле. Достаточно один раз выложить проект в публичный репозиторий.
- Нет обработки ошибок. Внешний сервис не ответил — приложение падает целиком вместо того, чтобы повторить запрос.
- База в файле рядом с приложением. Работает до первого передеплоя, после которого данные исчезают вместе со старым контейнером.
- Нет миграций. Любое изменение структуры данных превращается в ручную операцию с риском потерять всё.
- Всё в одном файле на 3000 строк. Правка в одном месте ломает три других, потому что связи не видны.
- Нет тестов и логов. Понять, что именно сломалось у конкретного клиента, невозможно.
- Работает на «счастливом пути». Пока пользователь нажимает кнопки в задуманном порядке — всё хорошо. Реальные люди так не делают.
Хорошая новость: такие проекты доводятся до продакшена быстрее, чем пишутся с нуля. Логика уже сформулирована, сценарии проверены на живых пользователях, спорные вопросы сняты. Остаётся инженерная часть — вынести секреты, поставить нормальную базу, добавить обработку ошибок, логи и мониторинг. Это работа на 3–10 дней, а не переизобретение продукта.
Чинить или переписывать
Ответ «зависит от ситуации» бесполезен, поэтому вот рабочее правило:
Порог не универсальный: для системы, которая писалась год, три дня разбора — это нормально и дёшево. Но для бота приёма заявок, который пишется за неделю, тратить три дня на археологию бессмысленно.
В пользу переписывания:
- Нет истории git — только финальные файлы, непонятно, что и зачем менялось
- Нет ни одного человека, который понимает, как это устроено
- Стек мёртвый: устаревшая версия языка, библиотеки без обновлений несколько лет
- Одна и та же логика дублируется в пяти местах — правка потребует найти все пять
- Данных мало или их легко перенести
В пользу починки:
- Код читаемый: понятные имена, разбит на файлы, есть комментарии по делу
- Есть структура — видно, где обработчики, где бизнес-логика, где работа с данными
- Проблема локализована: сломалась одна функция, остальное работает
- Данные в порядке и в нормальной базе
- Проект большой, и переписывание займёт месяцы
Отдельно: переписывание не означает потерю данных. База переносится, история клиентов сохраняется, для пользователей бот остаётся тем же самым.
Как выбрать второго подрядчика, чтобы не повторить
Прошлый опыт даёт понятный список требований. Шесть пунктов, которые обсуждаются до начала работ, а не после.
- Код в вашем репозитории с первого дня. Не «передадим при сдаче», а ваш GitHub или GitLab, куда подрядчик получает доступ. Тогда исчезновение исполнителя перестаёт быть катастрофой в принципе.
- Все доступы оформлены на вас. Аккаунты, ключи, токены — на вашу почту и ваш телефон. Подрядчику выдаются права, а не владение.
- Хостинг на ваш аккаунт и вашу карту. Пусть подрядчик настроит сервер, но платите за него вы. Это несколько сотен рублей в месяц и полная независимость.
- Понятный README с инструкцией запуска. Файл, по которому любой сторонний разработчик поднимет проект у себя. Проверяется просто: попросите показать README до оплаты финального этапа.
- Мониторинг с уведомлением при падении. Об остановке бота вы должны узнавать от системы, а не от клиента, который третий день не может оставить заявку.
- Договор с описанием, что происходит при прекращении сотрудничества. Кому принадлежат права, в какой срок передаются доступы, что входит в передачу дел. Один абзац, который снимает большую часть будущих проблем.
Как мы это делаем
Этап 1. Аудит, 1–2 дня, от 12 000 ₽
Платный и всегда первый. На выходе — письменный отчёт: что именно сломано и почему, оценка «чинить или переписывать» с обоснованием, смета на приведение в рабочее состояние и список рисков, включая инфраструктурные и связанные с безопасностью.
Отчёт принадлежит вам. С ним можно уйти к любому подрядчику или к штатному разработчику — это не крючок и не способ привязать к себе. Смысл платного аудита в другом: оценка чужого проекта «на глаз» по описанию проблемы всегда оказывается неправдой, и именно из таких оценок вырастают сметы, которые удваиваются в процессе.
Этап 2. Стабилизация
Приводим в рабочее состояние по согласованной смете: чиним поломку, выносим секреты, ставим нормальную базу, добавляем обработку ошибок и логи, заводим код в ваш репозиторий и пишем README.
Этап 3. Сопровождение
Мониторинг с уведомлением при падении, реакция в оговорённый срок, плановые доработки. От 8 000 ₽ в месяц. Этап необязательный — если после стабилизации вы хотите вести проект сами или силами своего разработчика, всё для этого будет передано.
| Задача | Цена | Срок |
|---|---|---|
| Экстренная починка (бот лежит прямо сейчас) | от 8 000 ₽ | от нескольких часов |
| Аудит проекта с письменным отчётом | от 12 000 ₽ | 1–2 дня |
| Стабилизация и доводка прототипа до продакшена | 40 000 – 150 000 ₽ | 1–4 недели |
| Сопровождение с мониторингом | от 8 000 ₽/мес | — |
Если по результатам аудита окажется, что проект дешевле переписать — скажем это прямо и покажем расчёт. Если поломка мелкая и чинится за час — тоже скажем прямо.
Вопросы, которые задают чаще всего
Разработчик не отдаёт код, что делать?
Сначала спокойно и письменно запросите то, что важнее кода: токен бота у @BotFather, доступ к хостингу, базе данных и домену. Эти вещи передаются одним сообщением и почти всегда отдаются без спора. Код — вторая по важности позиция: если он не передан, бота обычно дешевле переписать, чем добиваться исходников. Права на разработку по договору принадлежат заказчику, если в договоре не написано иначе, но судебный путь по проекту за 40 000 ₽ почти никогда не окупается.
Можно ли починить бота, если нет исходников?
Иногда да: если есть доступ к серверу, код чаще всего лежит там в открытом виде — Python и Node.js не компилируются. Тогда работа сводится к тому, чтобы забрать файлы и завести их в репозиторий. Если нет ни кода, ни сервера, восстанавливать нечего, и бот пишется заново. Для простого бота это обычно 2–5 дней — дешевле, чем месяц переговоров.
Сколько стоит аудит чужого проекта?
От 12 000 ₽ за 1–2 дня работы. На выходе письменный отчёт: что сломано и почему, оценка «чинить или переписывать» с обоснованием, смета на приведение в рабочее состояние и список рисков. Отчёт принадлежит вам, с ним можно идти к любому подрядчику.
Возьмётесь ли вы за чужой код?
Да, это отдельное направление работы. Единственное условие — сначала аудит, а не оценка «на глаз» по описанию проблемы. Без аудита любая названная цифра будет неправдой, и через неделю смета вырастет вдвое. Отказываемся редко: когда доступов нет вообще и восстанавливать физически нечего.
Что делать, если код писала нейросеть?
То же самое, что с любым другим кодом. Прототип, собранный в Lovable, Cursor или Replit, — разумный способ быстро проверить идею. Проблема возникает не от метода, а от того, что прототип попал в продакшен без доводки: ключи в коде, нет обработки ошибок, база лежит файлом рядом с приложением. Это чинится за 3–10 дней и стоит дешевле, чем разработка с нуля, потому что логика уже описана и проверена на живых людях.
Как быстро можно поднять упавшего бота?
Если есть доступ к серверу — часто в тот же день, иногда за час-два. Больше половины падений вызваны банальными причинами: закончились деньги на хостинге, кончилось место от разросшихся логов, процесс упал и не перезапустился. Экстренная починка стоит от 8 000 ₽. Дольше всего занимает не сама починка, а получение доступов — начните с них.