Фраза «проще переписать с нуля» обладает удивительной хозяйственной силой. Она одним движением отменяет уже написанный код, работающие кнопки, привычки пользователей и деньги, которые в проект вложили раньше. Иногда переписать действительно проще. Но если такой диагноз поставлен до просмотра кода, это не диагноз, а рефлекс нулевого километра: всё чужое объявить старым и немедленно начать своё.
Я начинаю с другого конца — смотрю, что уже работает.
Готовый бот редко состоит из одной большой поломки. Он может отвечать на `/start`, показывать меню и принимать часть данных, но не отправлять заявку. Может выполнять прежний сценарий, хотя владельцу уже нужны другие тексты, кнопки или порядок действий. На моём сайте в разделе доработки эти задачи разделены прямо: исправить ошибку, добавить функцию или переделать то, что ведёт себя не так, как требуется. Сваливать все три случая в мешок с надписью «старый код» удобно только тому, кто не хочет развязывать узел.
Авторство здесь вообще не медицинский показатель. Другой разработчик, фрилансер, сам владелец проекта — код от этого не становится автоматически ни хорошим, ни плохим. В FAQ на сайте вопрос сформулирован без дипломатических кружев: «Возьмётесь за проект, который писали не вы?» Да. Бот, сайт или mini-app можно дорабатывать независимо от того, кто и на чём их писал.
Дальше начинается скучная часть, которая как раз и бережёт деньги. Сначала стоит отделить исправное от неисправного. Я бы прошёл основной пользовательский путь и отметил границу: до какого действия всё идёт как задумано, после какого появляется ошибка, что должно было произойти вместо неё. Если задача не в поломке, а в новой функции, я бы так же отметил существующий маршрут, куда эту функцию предстоит встроить. Не «сделать оплату вообще», а понять, после какой кнопки она нужна и что бот должен показать после подтверждения.
Это советы, не рассказ о тайном ритуале с обязательным набором доступов. До просмотра конкретного проекта я не знаю, как он устроен, где запущен и какие сервисы с ним связаны. Знаю только, что оценивать доработку по одному сообщению «бот не работает» — занятие сродни гаданию по корпусу выключенного компьютера. Поэтому оценка начинается с кода, а не с прайса новых ботов.
На 2 ноября 2026 года на сайте такая оценка стоит 0 ₽. Я смотрю код и называю цену до начала работы. Это принципиальная граница: бесплатна именно оценка, а не обещание бесконечно чинить неизвестный проект. После просмотра должно появиться понятное решение — что сохраняем, что меняем и сколько стоит согласованная работа.
Для первого обращения не требуется превращать историю проекта в археологический отчёт. Стоит назвать наблюдаемую границу: вот это действие проходит, вот на следующем бот молчит; эта кнопка нужна, а после неё сейчас открывается не тот экран; прежний сценарий устраивает, добавить требуется только один новый шаг. Если точную причину вы не знаете, так и лучше написать. Причину ещё предстоит выяснить, а описание владельца нужно прежде всего для сравнения ожидаемого поведения с нынешним.
И здесь полезно не смешивать поломку с переделкой. «Бот перестал отвечать» и «бот отвечает, но мне нужен другой порядок кнопок» звучат похоже лишь на расстоянии. В первом случае ищут причину отказа. Во втором согласуют новое поведение. На сайте рядом с ними есть третий вариант — добавить функцию, например запись, оплату, выгрузку в таблицу или связь с сервисом. Названия знакомые, но цена доработки появляется после просмотра конкретного проекта, не из соседнего прайса.
Цену я фиксирую до начала и не меняю без согласия заказчика. У доработки нет честной универсальной суммы, которую можно снять с калькулятора нового бота. В одном проекте нужная часть может быть отделена аккуратно, в другом изменение затронет несколько связанных мест. Назначать обоим одну цену только потому, что функция называется одинаково, было бы тем же рефлексом нулевого километра, только уже бухгалтерским.
Есть и обратная ловушка. Сохранить всё написанное прежде любой ценой — тоже не добродетель. Если просмотр покажет, что изменение старой части опаснее и запутаннее её замены, я скажу об этом до работы. Но решение «оставить или переписать» должно следовать из кода и согласованной задачи, а не предшествовать им. Иначе заказчик платит не за исправление своего проекта, а за любовь нового программиста к чистому листу.
Проверку результата я бы тоже не сводил к картинке «готово». Если менялась конкретная ветка, стоит пройти её в Telegram от начала до конца и посмотреть новое действие вместе с соседними старыми. Бот принял данные, вернул нужный текст, передал результат туда, куда договорились, — тогда изменение можно проверять предметно. На сайте общий порядок работы именно такой: я показываю результат в Telegram, заказчик проверяет и просит поправить то, что не так.
Платить нужно после этой проверки. Не после обещания посмотреть, не после сообщения о количестве переписанных файлов и не после торжественного слова «релиз». На странице доработки условие сформулировано короче: оплата — когда проверите результат. Правки по согласованной задаче входят в цену, а ошибки после сдачи я исправляю без доплаты 14 дней.
Отдельно мне нравится практическое следствие чужого авторства. Оно не мешает начать работу и не должно привязывать владельца к следующему исполнителю. По условиям сайта бот работает под токеном заказчика, код и инструкция остаются у него, продолжить работу может любой программист. Старый автор не ставит шлагбаум новому; новый тоже не должен увозить шлагбаум с собой.
В запросе «доработка телеграм бота» мне интересна прежде всего та часть, которую заказчик хочет оставить. Если прежний сценарий его устраивает, это уже условие задачи, а не помеха для нового исполнителя. Переписать знакомые кнопки можно, но объяснять пользователям, почему они теперь в другом месте, придётся владельцу.
А кнопку «переписать всё» я бы пока оставил неактивной. Она ещё ничем не заслужена.