Как принять сайт или приложение от другого разработчика: что забрать в первую очередь

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

КОРОТКО

Как принять проект от другого разработчика

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

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

Мы принимаем проекты на Laravel, PHP, WordPress, Magento, React и Next.js, а также мобильные приложения, и каждый раз идём в одном порядке: доступы, рабочие резервные копии, понимание того, как изменения попадают в продакшен, затем аудит и только потом решения. В статье мы проходим этот порядок на трёх наших проектах: дважды правильным ответом оказалось обновление и один раз полная переработка.

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

ПОЧЕМУ СРЫВАЕТСЯ

Пять причин, почему передача ломается

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

Доступы у одного человека. Домен лежит в личном аккаунте разработчика у регистратора, хостинг оформлен на реселлерский аккаунт агентства, а Search Console подтверждён личным токеном разработчика. Для .com и других общих доменов регистратор по правилам ICANN (Transfer Policy) обязан выдать код переноса владельцу домена по записи в течение пяти календарных дней после запроса. Если владелец по записи ваш бывший подрядчик, код получит он.

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

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

Неизвестные версии. Никто не может сказать, какая версия PHP работает в продакшене и когда в последний раз обновляли фреймворк. При этом даты публичны. PHP 7.4 перестал получать исправления безопасности 28 ноября 2022 года, PHP 8.1 31 декабря 2025 года, а PHP 8.2 потеряет их 31 декабря 2026 года (php.net, октябрь 2026). Laravel даёт каждой мажорной версии два года исправлений безопасности, и Laravel 11 лишился их 12 марта 2026 года.

Забытые интеграции. Задача по расписанию, которая каждую ночь отправляет прайс, вебхук в CRM, адрес обратного вызова платёжного провайдера, форма, которая до сих пор копирует заявки человеку, ушедшему два года назад. Всё это работает, пока не перестанет, и до этого момента никто не знает, что оно существует. Как владение проектом утекает задолго до того, как разработчик на самом деле уходит, мы писали в статье Ваш сайт не падает в день, когда уходит разработчик.

ПЕРВАЯ НЕДЕЛЯ

Чек-лист на первую неделю

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

Три пункта из этого списка создают больше всего проблем, поэтому на них стоит посмотреть внимательнее.

Репозиторий. Просите передать репозиторий, а не скачать его. На GitHub переданный репозиторий сохраняет задачи, pull request и вики, история коммитов остаётся на месте, а ссылки на старый адрес автоматически ведут на новый (документация GitHub, октябрь 2026). История объясняет, почему код выглядит именно так, а архив файлов это объяснение выбрасывает.

Резервная копия. Руководство CISA по защите от программ-вымогателей требует регулярно проверять доступность и целостность резервных копий в сценарии аварийного восстановления. Копию, которую ни разу не восстанавливали, мы считаем предположением. Восстановление одной копии в отдельном окружении отвечает сразу на два вопроса: полная ли она и сколько часов займёт настоящее восстановление.

Пароли и ключи. Рекомендации OWASP по секретам сформулированы прямо: если секрет больше не нужен или мог быть скомпрометирован, его нужно отозвать, и никогда не должно быть одного пароля на всех администраторов. На практике это значит заменить все пароли и ключи, которыми пользовалась прежняя команда, после того как доступы перешли к вам, и в тот же день. Для Search Console нужен ещё один шаг: по справке Google, чтобы удалить подтверждённого владельца, нужно удалить и его токены подтверждения, иначе он сможет подтвердить сайт заново.

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

РАССТАВАНИЕ

Как вежливо расстаться с прежним подрядчиком

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

1. Составьте список того, что у вас есть, до любых объявлений. Пройдите таблицу первой недели самостоятельно. Пункты, которые вы не можете открыть сами, нужно запросить в первую очередь.
2. Прочитайте договор вместе с юристом. Ищите срок уведомления, обязательства по передаче и то, кому принадлежат код и аккаунты. Юридических консультаций мы не даём, но подскажем, какие технические пункты должны быть закрыты этими условиями.
3. Просите доступы ради непрерывности работы, а не ради ухода. Добавить компанию владельцем у регистратора, хостинга и в репозитории считается нормальной просьбой на любом этапе сотрудничества.
4. Отправьте один письменный список, через себя. Мы готовим его: репозиторий с историей, как изменение попадает в продакшен, настройки окружения и задачи по расписанию, сторонние аккаунты, известные ошибки и всё, что вам обещали.
5. Предложите оплатить созвон по передаче. Один или два часа, за которые прежний разработчик проведёт нас по системе, часто экономят дни чтения кода.
6. Закройте доступы в день, когда они переходят. Пароли и ключи заменены, старые аккаунты удалены, токены подтверждения удалены, и то же правило действует, когда позже уходит кто угодно, включая нас.

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

Холодный старт бывает, когда никто не отвечает. Тогда мы начинаем с того, что бизнес контролирует сам, выясняем, что можно вернуть через регистратора, хостинг-провайдера и каждый сервис с подтверждением владения, а остальное восстанавливаем по серверу и коду. Холодный старт занимает больше времени и стоит дороже, и это ещё одна причина забрать доступы, пока отношения хорошие.

АУДИТ

Что проверяет аудит перед приёмом

Когда доступы у вас, аудит в рамках услуги приёма проекта от другого подрядчика выясняет, что на самом деле работает. Он стоит от $2 500, и цена фиксируется до начала аудита. Цена растёт с размером проекта, количеством интеграций и серверов, состоянием документации и объёмом доступов, которые нужно восстановить: проект с прежней командой на связи и рабочим репозиторием принять дешевле, чем холодный старт с доменом на чужом имени.

На проект смотрят три человека с разных сторон:

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

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

Аудит ищет и сбои, которые ничего не показывают на экране. Форма может благодарить посетителей, а письмо при этом не приходит. Переезд на другой хостинг может потерять записи SPF и DKIM и отправить заявки в спам. Настройка хостинга по умолчанию может закрыть сайт от ИИ-краулеров. Поэтому каждый аудит включает реальную тестовую заявку и проверку почтовой аутентификации, robots.txt и доступа краулеров.

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

Аудит перед приёмом нужен, когда не хватает сразу двух вещей: людей, которые знали систему, и ясной картины того, что вы контролируете. Если все доступы у вас и устарели только версии, дешевле начать с аудита в рамках модернизации сайта: от $300 для небольшого сайта и от $1 000 для крупного.

ОСТАВИТЬ ИЛИ ПЕРЕПИСАТЬ

Оставить, обновить или переписать

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

Порог в 60% мы используем как эмпирическое правило, а не как закон. Когда безопасное обновление приближается к этой доле стоимости чистой разработки того же самого, мы показываем оба варианта рядом, с их рисками, и решение принимает владелец. Полный метод обновления, с рыночными ценами и инструментами, описан в статье Обновление старого сайта на Laravel или PHP в 2026 году.

За каждым вердиктом стоит один и тот же вопрос: соответствует ли структура системы тому, как бизнес работает сегодня? Версии можно исправить. Модель данных, построенная под бизнес, которого уже нет, переносит каждое старое решение в новую версию, каким бы аккуратным ни было само обновление.

ТРИ ПРОЕКТА

Что мы решили на трёх реальных проектах

Обновление: шесть версий Laravel на работающем сайте. Один из наших проектов, который не был в приоритете, трёхъязычный сайт со своей админкой и системой заявок, работал на Laravel 7 и PHP 7.4 и каждый день делал своё дело. Мы перевели его на Laravel 13 и PHP 8.4 примерно за три дня разработки, один день приёмочного тестирования и пять минут запланированного простоя. Три урока из этого проекта применимы к любому приёму. За более чем 200 полями форм в 29 шаблонах стоял заброшенный пакет форм; вместо того чтобы переписывать админку, разработчик написал небольшой слой совместимости. Исходный план отката указывал на тег версии, созданный до нескольких дней посторонней работы, так что откат отменил бы и её; точку отката перенесли на точный коммит продакшена. А кеширование маршрутов, обычная оптимизация скорости, превратило каждую страницу тестовой копии в 404, потому что этот сайт строит языковые префиксы из базы данных; правило «никогда не кешировать маршруты» записали в письменные инструкции проекта, чтобы его не повторил ни один будущий разработчик или ИИ-агент. Вся история в статье Шесть версий Laravel за три дня.

Обновление: сайт и магазин медицинского института. На сайте Института трихологии мы довели старую сборку OpenCart до 3.0.5.1, последнего релиза линейки OpenCart 3, а PHP до 8.3. Магазин института «Трихокосметика» был закончен много лет назад на PHP 5.6 и так и не запущен. Его дизайн по-прежнему смотрелся достойно, а структура была здоровой, поэтому мы сохранили и то и другое, перевели магазин на OpenCart 3.0.5.1 и PHP 8.4 и обновили модули и интеграции. Оба сайта стали заметно быстрее, а вложения в магазин удалось использовать вместо того, чтобы их выбросить.

Обновляйте то, что бизнес сделал правильно. Переписывайте то, из чего он вырос.

Переработка: большая самописная система на PHP 5.3. У одного из наших клиентов большая самописная система на PHP 5.3 с большой и постоянно меняющейся базой. Поддержка безопасности PHP 5.3 закончилась 14 августа 2014 года (php.net). Система работает, но многие её связи держатся на обходных решениях, которые добавлялись по одному на протяжении лет. Обновление перенесло бы каждое из них в новую версию, поэтому мы отговорили от него и подписали договор на полную переработку. Сейчас мы прорабатываем документацию вместе с архитектором клиента, чтобы бизнес-процессы с самого начала были смоделированы правильно, а новая система была выстроена вокруг того, как компания работает сегодня, а не тогда, когда писалась первая версия.

Почему тот же старый стек блокирует и ИИ-проекты и как это меняет вопрос об обновлении, мы разобрали в статье ИИ-проект застрял на старой системе? Если доставшуюся вам систему собрали с помощью ИИ-инструментов владелец или небольшая команда, у решения своя логика, о ней статья Вы собрали MVP с помощью ИИ. Оставить, доработать или переписать?

ПЕРЕДАЧА

Что должно входить в передачу проекта

Передача, которая заканчивается фразой «вот пароли», не завершена. Принимаем ли мы проект или отдаём его, мы ждём один и тот же пакет, и именно его сами передаём по договору:

• Код в виде репозитория с полной историей, чтобы причины изменений можно было отследить.
• Команды выкладки: точные шаги, по которым коммит попадает в продакшен, включая миграции базы и правила работы с кешем.
• Требования к серверу: версия PHP и расширения, версия базы данных, задачи по расписанию, очереди и названия настроек окружения (названия, а не значения в документе).
• Процедура отката: как вернуться к предыдущему релизу, с привязкой к точному коммиту и проверкой на копии: так мы учитываем урок неверного тега из примера выше.
• Файл AGENTS.md: короткое, написанное человеком описание структуры, команд и жёстких правил проекта.

Файл AGENTS.md читают ваши разработчики, другой подрядчик и ИИ-агенты для написания кода. Строки из наших собственных файлов показывают, что в нём должно быть: никогда не менять адрес существующей страницы без 301-редиректа; никогда не удалять код, который выглядит неиспользуемым, не проверив содержимое базы, скрипты по расписанию и интеграции; на одном проекте никогда не кешировать маршруты. Зачем нужен такой файл и почему короткий лучше длинного, мы объясняем в статье Вашему коду нужна инструкция для ИИ.

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

Документация остаётся единственной частью передачи, которая работает после ухода всех.

ДАЛЬШЕ

Как продолжается работа

Большинство проектов после аудита переходят на поддержку и обслуживание сайта от $1 000 в месяц: обновления PHP, фреймворка и пакетов по графику, ежедневные резервные копии вне сервера с проверкой восстановления, мониторинг и небольшие изменения на всех языках, с обновлением документации после каждого изменения.

Новые функции и крупные изменения оцениваются и получают цену до начала работы. На Laravel и PHP это разработка на Laravel: $75 в час или проект от $15 000. Продукту, который меняется каждую неделю, подходит выделенная команда разработки от $8 000 в месяц, собранная из пула проверенных людей, которых мы знаем лично. Серверы, конвейеры релизов, переезд в облако или дежурный инженер вне рабочего времени относятся к работе по DevOps и облачной инфраструктуре по ставке от $50 до $70 в час.

Если главный вопрос в том, каким должен стать продукт, а не в том, у кого ключи, сначала проводится стратегическая сессия. Она длится от двух до трёх часов и готовится заранее; её стоимость $500 засчитывается в проект, который делаем мы. Всё дальнейшее строится вокруг того, как работает ваш бизнес: одно решение вместо дизайна, разработки и хостинга по отдельности. Код и развёртывание передаются вам по договору. Все наши цены собраны на странице цен, оплата банковским переводом по договору.

FAQ

Источники

• PHP: Supported versions
• PHP: Unsupported branches
• Laravel: Release notes and support policy
• ICANN: Transfer Policy
• GitHub Docs: Transferring a repository
• OWASP: Secrets Management Cheat Sheet
• CISA: #StopRansomware Guide
• Справка Google Search Console: владельцы, пользователи и разрешения