Как сменить разработчика: передача проекта, аудит чужого кода и доработать или переписать

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

Когда менять разработчика, а когда нет?

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

Честные поводы уйти:

• сроки срываются не первый раз, и вы узнаёте об этом сами, а не от подрядчика;
• на простые вопросы «что сделано» и «где код» нет внятных ответов;
• после каждой правки появляются новые ошибки в других местах;
• сайт лежит на сервере подрядчика, а домен оформлен на него или его сотрудника;
• задачи выросли: был сайт-визитка, нужен магазин или кабинет клиента, а у подрядчика нет таких компетенций.

Плохие поводы: «другая студия обещает дешевле», «хочется новый дизайн» (это решается редизайном у текущего исполнителя) или конфликт из-за правки, которая не входила в техзадание. Если причина в размытом ТЗ, смена подрядчика её не уберёт — сначала опишите задачу так, чтобы её можно было проверить.

Если работа ещё не сдана, у заказчика есть законное право выйти. По статье 717 ГК РФ он может отказаться от договора подряда в любой момент до сдачи результата, если договор не предусматривает иного. Но выполненную часть придётся оплатить пропорционально, а подрядчику — возместить убытки в пределах разницы между полной ценой и оплаченной частью. Поэтому до отказа важно зафиксировать, что сделано, и получить это на руки. Если повод — сорванные сроки, сначала стоит пройти шаги из статьи разработчик сорвал сроки: претензия, неустойка и расторжение.

Что	Где лежит	Зачем новому разработчику
Исходный код с историей изменений	Репозиторий (GitHub, GitLab, Gitflic) или архив	Без кода дорабатывать нечего; история показывает, что и зачем меняли
База данных — свежая копия	Сервер или панель хостинга	Заказы, клиенты, статьи; без неё сайт не поднять в тестовой среде
Загруженные файлы	Папка uploads, объектное хранилище	Фото товаров и документы обычно не лежат в репозитории
Доступ к серверу или хостингу	Панель хостинга, SSH-ключ, панель облака	Посмотреть, как сайт реально запущен, и снять копию
Регистратор домена и DNS	Кабинет регистратора, DNS-хостинг	Почта, поддомены и переезд держатся на DNS-записях
Файлы настроек и ключи интеграций	.env, конфиги, кабинеты платёжки, CRM, служб доставки	Без ключей оплата и обмен с CRM перестанут работать
Админка, Метрика, Вебмастер, почта для заявок	Сами сервисы	Чтобы не потерять статистику и заявки в день смены
Описание, как собрать и выложить проект	README, скрипты, письмо разработчика	Иначе новый подрядчик восстанавливает это вслепую

Что собрать до передачи: чек-лист доступов

Заберите всё, что нужно, чтобы поднять сайт заново без участия прошлого подрядчика: код с историей изменений, свежую копию базы, загруженные файлы, доступы к серверу, домену, интеграциям и аналитике. Делайте это до объявления о расставании — потом договориться сложнее.

Главный тест простой: новый разработчик должен развернуть копию сайта на своём тестовом сервере только из того, что вы ему передали. Если не получается — чего-то не хватает. Чаще всего забывают три вещи: загруженные файлы (фото товаров, документы), файл настроек с ключами интеграций и инструкцию, как проект собирается и выкладывается.

Правила хорошего тона при сборе доступов:

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

Что такое аудит кода и что в нём проверяют?

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

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

1. Можно ли собрать и запустить проект. Хватает ли переданного, есть ли описание сборки, совпадает ли код в репозитории с тем, что работает на сервере.
2. Платформа и зависимости. Версия CMS, фреймворка, языка; есть ли устаревшие библиотеки с известными уязвимостями; правилось ли ядро CMS вручную.
3. Безопасность. Пароли и ключи прямо в коде, открытые служебные страницы, проверка прав в админке, обработка данных из форм.
4. Структура и читаемость. Разделена ли логика на модули, есть ли повторяющиеся куски, насколько предсказуемо правка в одном месте отражается в другом.
5. Данные. Схема базы, дубли, резервные копии, где хранятся персональные данные клиентов.
6. Интеграции. Как сайт обменивается с CRM, 1С, платёжкой, доставкой; что произойдёт при сбое внешнего сервиса.
7. Развёртывание. Как код попадает на сервер: вручную по FTP или по скрипту, есть ли тестовая копия.

Как читать отчёт, если вы не программист. Смотрите не на количество замечаний, а на разметку важности. Критичные пункты — то, что может уронить сайт или привести к утечке данных; их закрывают первыми. Важные — то, что замедляет каждую будущую доработку. Остальное — косметика, её можно не трогать годами. Хороший отчёт для каждой проблемы говорит, чем она грозит бизнесу и сколько примерно стоит исправление, а не только «код плохой».

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

Почему доработка чужого кода стоит дороже?

Потому что сначала нужно понять, как всё устроено, и только потом менять. Автор кода знает, где что лежит и почему сделано именно так. Новому разработчику это приходится восстанавливать, а каждое изменение — проверять, не задело ли оно соседние части.

Из чего складывается разница:

• Вход в проект. Развернуть копию, разобраться в структуре, найти, где хранится нужная логика. Для первой задачи это часто дольше самой правки.
• Нет тестов и документации. Если нет автоматических проверок, каждое изменение приходится проверять руками по всем затронутым сценариям.
• Скрытые связи. Поле формы используется в трёх местах, о двух из них никто не знает — правка ломает обмен с CRM.
• Устаревшая основа. Новая функция требует свежей версии библиотеки, а обновление тянет за собой переделку соседних модулей.
• Риск без гарантии. Новый подрядчик отвечает за свою правку, но не за ошибки, заложенные до него. Поэтому он закладывает время на проверку.

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

Обратная сторона: после того как проект разобран, задачи дешевеют. Первые доработки самые дорогие, дальше скорость выравнивается — если код не совсем запущен.

Признак	Скорее дорабатывать	Скорее переписывать
Платформа и версии	Поддерживаемая версия CMS или фреймворка, обновляется без поломок	Версия давно без обновлений безопасности, обновление ломает сайт
Структура кода	Понятные модули, логика отделена от шаблонов	Одна правка задевает несколько мест, логика размазана по шаблонам
Ядро CMS	Ядро не тронуто, изменения в своих модулях	Ядро переписано вручную — обновить нельзя
Данные	Схема базы понятна, данные чистые	Дубли, мусор, связи держатся на ручных костылях
Задачи на год вперёд	Те же разделы, новые страницы и мелкие функции	Кабинеты, роли, интеграции, которых в архитектуре нет
Стоимость правки	Мелкие задачи делаются за часы	Каждая мелочь превращается в исследование на дни

Доработать или переписать: признаки

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

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

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

Пример из нашей практики — «СтройОко», платформа строительного контроля. Её переписали целиком: новый адаптивный фронтенд и новый бэкенд, а продукт вывели в SaaS с регистрацией компаний. Переписывание целиком оправдано, когда меняется сама модель продукта — здесь это SaaS для многих компаний, где у каждой своя изолированная база, — а не просто «код не нравится».

Если сайт простой, вопрос «переписать» часто сводится к выбору платформы и обновлению дизайна. Как решать его без потери позиций в поиске, мы разобрали в статье «Редизайн или новый сайт».

Как передать проект без простоя?

Не выключайте старый сайт, пока новый подрядчик не поднял рабочую копию и не проверил её. Порядок такой: забрать всё по чек-листу, развернуть копию на тестовом сервере, сверить с рабочим сайтом, договориться об окне, перенести свежую базу и только потом переключить DNS или выложить код.

1. Заморозка. Договоритесь с прошлым подрядчиком, что с определённой даты он больше ничего не выкладывает. Иначе код в репозитории и на сервере разойдутся.
2. Снимок. Свежая копия кода, базы и файлов в один день. Проверьте, что копия открывается, а не просто скачалась.
3. Тестовая копия. Новый разработчик разворачивает проект у себя, проходит основные сценарии: заявка, заказ, оплата, вход в кабинет.
4. Окно переключения. Выберите время с минимальной нагрузкой. Перед ним — последняя выгрузка базы, чтобы не потерять заказы последних часов.
5. Переключение и проверка. После переноса — те же сценарии на рабочем сайте, плюс почта, формы, обмен с CRM.
6. Замена доступов. Новые пароли, новые ключи API, удаление старых пользователей из админки, хостинга и репозитория.

Если сервер остаётся тот же, переезд сводится к передаче доступов и смене паролей — сайт вообще не останавливается. Самое уязвимое место при любой смене — почта на домене и DNS-записи: их нужно переписать заранее, до любых изменений.

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

Когда смена не нужна и какие ошибки самые частые?

Смена не нужна, если сайт выполняет задачи, а претензии — к цене отдельных правок или к вкусу. И она не спасёт, если проблема в задаче: размытое ТЗ и постоянная смена требований повторятся с любым исполнителем.

Ошибки, которые обходятся дороже всего:

• объявить о расставании раньше, чем получены код, база и доступы;
• забрать код, но не загруженные файлы и не настройки интеграций;
• не сменить пароли и ключи после ухода прошлого подрядчика;
• поручить новому исполнителю срочную доработку без аудита — и получить сломанный обмен с CRM;
• решить «всё переписать» без расчёта, сколько стоит перенос данных и сохранение адресов страниц;
• пускать двух подрядчиков в один и тот же код одновременно без правил, кто что выкладывает.

И одна ошибка юридическая: не прочитать прошлый договор. В нём может быть сказано, что код передаётся только после полной оплаты или что права остаются у исполнителя. Это не мешает дорабатывать сайт, если есть лицензия, но знать это нужно заранее.

Сколько стоит и как это устроено у нас?

Отдельной строки для аудита в нашем прайсе нет: его стоимость зависит от объёма проекта, поэтому называем её после брифа, когда видим репозиторий. Дальше — либо доработки, либо новый проект по тарифам из прайса с ценой и сроком в договоре.

Ориентиры по прайсу, все цены — «от»:

• редизайн сайта — от 29 000 ₽, 2–3 дня;
• поддержка и развитие по подписке — от 7 900 ₽ в месяц или разовые задачи;
• новый корпоративный сайт — от 56 000 ₽, 3–4 дня;
• веб-приложение или SaaS, если переписывается сервис с кабинетами и ролями, — от 160 000 ₽, от 10 дней.

Если проект делали мы, а дорабатывать его вы решили с другим исполнителем, это предусмотрено. По нашему типовому договору исходный код передаётся в ваш репозиторий в объёме, достаточном для сборки, развёртывания и доработки (п. 5.5). Исключительное право на код остаётся у студии, а у вас после полной оплаты — лицензия на весь срок действия права: проект можно размещать на любом сервере и дорабатывать с любым подрядчиком, сублицензию подрядчикам для обслуживания и доработки мы согласовали заранее (п. 5.4). Гарантия 30 календарных дней не распространяется на изменения, внесённые третьими лицами, — это честное условие для обеих сторон.

Обсудить передачу проекта можно на странице заказной разработки: пришлите ссылку на сайт и список того, что удалось забрать у прошлого подрядчика.

Короткие ответы на частые вопросы

Можно ли поменять разработчика сайта посреди проекта?

Можно. По ст. 717 ГК РФ заказчик вправе отказаться от договора подряда до сдачи результата, если договор не говорит иначе, но обязан оплатить выполненную часть пропорционально и возместить подрядчику убытки в пределах разницы между ценой всей работы и уже оплаченной частью. Перед отказом заберите код, базу и доступы.

Сколько стоит аудит кода сайта?

Зависит от объёма проекта и глубины проверки. В Roboweb.team отдельного тарифа на аудит в прайсе нет — стоимость называем после брифа, когда видим репозиторий и задачу.

Почему новый разработчик не берёт фиксированную цену на доработку чужого сайта?

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

Что делать, если прошлый подрядчик не отдаёт код?

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

Переписать сайт — это всегда дороже, чем дорабатывать?

На коротком отрезке — обычно да. Но если каждая правка требует дней разбора, а планы не помещаются в архитектуру, переписывание за год может обойтись дешевле, чем латание.

Услуги и кейсы по теме: заказная разработка · кейс СтройОко · цены и сроки