Подхват проекта — после фрилансера
Заберём проект у одиночного разработчика или небольшой команды: код, доступы, инфраструктуру, релизы, документацию и накопленный контекст. Начинаем с аудита, дальше — стабилизация, поддержка или развитие по согласованной модели.
Что мы понимаем под подхватом
Одиночная разработка часто держится на одном человеке, поэтому при передаче появляются риски. Это не вопрос плохого исполнителя — это естественное свойство формата. Подхват — это сделать так, чтобы проект перестал зависеть от одного человека и его памяти, а перешёл в режим, где его может вести команда или новый разработчик по документам и понятному процессу.
Разбор кода, инфраструктуры, доступов, релизного процесса и интеграций. Сбор и фиксация знаний, которые были только в голове исполнителя: архитектурные решения, спорные места, временные обходы. Письменный отчёт с приоритезированными рисками и план стабилизации. Передача в управляемый формат — поддержку или развитие по согласованной модели.
Новый проект с нуля без разбора текущего. Разовая мелкая правка без аудита и без ответственности за релиз. Работа без подтверждённых прав на код, сервер, домены и данные. Юридические переговоры с прежним исполнителем — это зона юриста, не подрядчика. До юридической ясности по спорным частям мы туда не заходим.
Когда нужен подхват
Если совпали два-три пункта — пора смотреть, что на самом деле под капотом.
Исполнитель вышел в долгую паузу, сменил приоритеты или больше не работает с проектом. Вопросы остаются без ответа.
Новый человек открывает репозиторий и не может найти, где живёт ключевая логика, почему так сделано и что можно трогать.
Деплой — это одна локальная машина, одна последовательность команд, один человек. Без него релиза в этот период нет.
Сервер, домен, репозиторий, база, платёжные сервисы или аналитика зарегистрированы на личные аккаунты исполнителя, а не на ваши.
README устарел или его нет вовсе. Архитектурные решения, спорные места и временные обходы не записаны никуда.
Каждая новая правка задевает что-то старое. Регрессии видны не сразу, разбор инцидентов затягивается.
У продукта появились реальные пользователи, оплаты и ответственность, а разработка и релизы остались как в стартовый период.
Без карты сложно завести новых людей. Каждый новый разработчик заново проходит путь автора и совершает те же ошибки.
Кому не подойдёт
Называем заранее, чтобы не тратить ваше время и не вводить в заблуждение.
Если задача — собрать новый продукт без сохранения текущего, это не подхват, а разработка с нуля. Это отдельный формат работы.
Если у вас нет подтверждённого доступа хотя бы на чтение к коду, серверу, доменам и данным, и получить его невозможно — мы не работаем. Это вопрос юридической чистоты и нашей репутации.
Одна задача, один эндпоинт, одна форма без понимания контекста — это та же история, которая привела проект в текущую ситуацию. Мы заходим минимум через короткий аудит.
Если права на код, лицензии или аккаунты оспариваются — сначала юрист, потом аудит. До юридической ясности мы не заходим.
Что проверяем в первые дни
Сразу не лезем чинить. Сначала проходим по списку и фиксируем состояние, чтобы дальше работать с фактами, а не с предположениями.
Состояние веток, актуальность кода, последние коммиты, что входило в последние релизы, где живут хотфиксы.
Что и где развернуто, как обновляется, совпадает ли версия на проде с тем, что в репозитории, есть ли вообще тестовый контур.
Кто владелец аккаунтов по документам и кто фактически имеет доступ — это могут быть разные люди. Где хранятся ключи и пароли.
Версии языка и framework, состояние зависимостей, где лежат env-файлы, есть ли секреты в коде или в личных заметках исполнителя.
Состояние базы, история миграций, регулярность и восстанавливаемость бэкапов, наличие тестовых копий данных.
Как собирается и выкатывается код, что делается руками по SSH, есть ли rollback и кто им владеет на практике.
Какие обмены критичны, где видны разрывы, какие интеграции сделаны без логов и ретраев, кто владелец внешних кабинетов.
Что задокументировано, что устарело, что живёт только в переписке. Кто из людей со стороны исполнителя может ответить на вопросы.
Что вы получаете после аудита
Артефакты остаются у вас даже в случае, если дальше работаете не с нами.
Письменный разбор кода, инфраструктуры, доступов, релизов, интеграций и документации с приоритезированными находками и рисками передачи.
Что есть на руках, чего не хватает, кто владелец, что оформлено не на вас и что нужно переоформить в ближайшее время.
Что копит риск и может стать аварией: ручные деплои, секреты в коде, отсутствующие бэкапы, забытые миграции, нелогируемые интеграции.
Что где развёрнуто, какие сервисы участвуют, какие обмены идут, где живут данные. Опорная схема для любых дальнейших решений.
Список работ после старта подхвата с оценкой трудоёмкости. Цель — снять зависимость от одного человека и закрыть критичные риски.
Сгруппирован по приоритету: что в ближайший релиз, что в следующий, что в долг, что — обсудить с владельцем продукта перед началом.
Поддерживать текущую архитектуру, стабилизировать, частично переписать или выделить проблемные модули — обоснованное решение по итогам аудита, а не «нам не нравится текущий код».
Первый месяц
В первый месяц не пересобираем продукт. Снимаем зависимость от одного человека и закрываем риски, которые могут привести к новому инциденту.
Снимаем baseline: что в репозитории, что на проде, какие версии и зависимости работают сейчас. Это точка, к которой можно вернуться при неудачной правке.
Архитектурные решения, спорные места, временные обходы, владельцы аккаунтов, контакты по интеграциям — всё это превращается в короткие документы и схемы, а не остаётся в переписке.
Передаём владение репозиториями, серверами и сервисами на ваши учётные записи там, где это возможно. Ревизуем секреты в env, репозитории и мессенджерах.
Бэкап считается рабочим только после успешного восстановления на отдельной среде. Миграции описываем и проверяем на копии. До этого массовые операции на проде не запускаем.
Описываем сборку, выкатку и откат. Если деплой делался руками с локальной машины — фиксируем повторяемую процедуру, доступную не одному разработчику.
Точечные фиксы, не задевающие соседние модули. Каждое изменение — отдельно, с проверкой и возможностью отката. Без «заодно поправим вот это».
Что считается рабочим состоянием, как выкатывается релиз, как откатываются изменения, как поддержка решает типовые ситуации. Это база для команды, а не для одного человека.
Чего не ломаем при переходе
Эти ограничения мы соблюдаем сами, чтобы переход был предсказуемым, а проект — не пострадал.
Без отдельного решения по итогам аудита архитектура и стек остаются теми же, что были до нас. Решения по архитектуре — отдельный разговор после стабилизации.
Замена языка, фреймворка или платформы «потому что нам так привычнее» в переходный период — способ удлинить нестабильность. Стек обсуждаем позже и отдельно.
Доступ закрывается только по вашему решению и после письменного акта передачи. До этого момента возможна параллельная работа в режиме чтения и консультаций.
Перенос регистратора, DNS, хостинга или платёжного кабинета идёт по плану с предварительным бэкапом, подтверждением владельца и согласованным окном переключения.
Релизы по стабилизации и по новым функциям разнесены. Это снижает риск, что новая фича уронит то, что только что починили, и упрощает разбор инцидентов.
Стек и типовые ситуации
Заходим в проекты, с которыми работают наши команды. Если вашего стека нет в списке — спросите, честно скажем, готовы ли подхватить или лучше начать с узкой диагностики.
Сайты, личные кабинеты, админки, лендинги со сложной логикой.
Python, Node.js, PHP, Go там, где он уместен.
React, Next.js, Vue, кастомный JS поверх простых шаблонов.
Flutter, React Native, нативные iOS и Android.
CRM, 1С, платежи, Telegram, email, внешние API.
VPS или cloud, Docker, nginx, БД, очереди, cron.
Если стека нет в списке — спросите, честно скажем, готовы ли подхватить или лучше начать с узкой диагностики.
Частые проблемы
Это не претензии к исполнителям. Это набор паттернов, которые регулярно встречаются в проектах, сделанных одним человеком, и которые становятся рисками при передаче.
Локальная настройка живёт в голове и в личных конфигах. На чужой машине проект не поднимается без длинного разбора.
README устарел, в нём команды, которых уже нет, или его нет вовсе. Новый человек тратит дни на то, чтобы понять, как собирать и запускать проект.
На проде живут правки, которых нет в репозитории. Любое обновление через сборку из репозитория откатывает эти правки незаметно для всех.
API-ключи и пароли закоммичены в репозиторий или хранятся в личных файлах исполнителя. После ухода человека ротация становится отдельной задачей.
Заход на сервер, ручная сборка, ручной рестарт. Никакого CI/CD, история деплоев не записана нигде, кроме как в командной строке.
Любая правка катается сразу на прод. Проверить поведение перед релизом негде, ошибки видны только пользователям.
«Бэкапы есть» часто означает «настроены, но никто никогда не восстанавливался». В критичный момент оказывается, что восстановиться нельзя или нечем.
Регистратор домена, хостинг, аналитика, платёжный кабинет — на личной учётной записи исполнителя, а не на вас как владельца проекта.
Webhooks не доходят, обмены теряются, ошибки возвращаются молча. Восстановить путь события почти невозможно — логов нет.
Временные решения из стартового периода живут рядом с долгоиграющей логикой. Какие из них «настоящие», а какие — обход на пару недель, помнит только автор.
Чек-лист передачи доступов
Часть пунктов выглядит банально, но именно они срывают подхват чаще, чем сложный код.
Типы проектов после фрилансера
Если ваш случай — в списке ниже, опишите его в заявке. Обсуждаем по существу: что досталось, какие риски, с чего начнём.
Корпоративный сайт, лендинг со сложной логикой, веб-сервис.
Стартовый продукт, у которого уже есть пользователи или клиенты.
Кабинет пользователя поверх backend и API проекта.
API для сайта, мобильного клиента, интеграций или внешних потребителей.
Бот, Mini App или внутренний бот команды на одном разработчике.
Обмены с CRM, 1С, платежами, маркетплейсами и внешними API.
Кастомные обработчики, виджеты, приложения поверх CRM.
Многопользовательский продукт с подписками и тарифами.
iOS, Android, кроссплатформенные приложения на одном разработчике.
Операционный инструмент команды поверх backend и базы.
Шире разбора после фрилансера
Если нужно забрать не только код, но и backend, интеграции, сайт, SaaS, CRM или срочно стабилизировать продакшен — начните с общей страницы подхвата проекта.
Если уже понятно, в какой части проекта горит, у нас есть отдельные страницы про срочный подхват проекта, подхват Python-проекта, подхват интеграций и API, подхват сайта или веб-сервиса, подхват SaaS-продукта и подхват CRM-системы.
FAQ
С короткой стартовой сессии и заявки на аудит. Обсуждаем, что за проект, какие сценарии критичны, какие доступы уже на вашей стороне, что произошло с исполнителем. По запросу подписываем NDA. Дальше — аудит репозитория, продакшена, инфраструктуры, базы, интеграций и документации. Цель — за несколько дней получить честную картину состояния. Условия дальнейшего подхвата обсуждаем после отчёта, а не до.
На аудите фиксируем, что нужно для запуска: версия языка и фреймворка, env-переменные, локальные файлы конфигов, секреты, инфраструктурные зависимости. Дальше — план собрать воспроизводимую сборку: Dockerfile или эквивалент, описание команд, минимальная инструкция по разворачиванию для нового разработчика. До этого момента проект остаётся «коробкой одного человека», и любая смена исполнителя становится отдельным риском.
Работаем с тем, что есть на вашей стороне как владельца проекта: ссылки на репозиторий, описание задачи, история переписки, скриншоты, выгрузки логов, доступы к аккаунтам, оформленным на вас. Параллельно вы как заказчик восстанавливаете владение через консоли провайдеров и регистраторов, где аккаунты оформлены на вас. Если ситуация острая и продакшен под угрозой — отдельный формат описан на странице срочного подхвата. Юридические переговоры с исполнителем — зона юриста, не подрядчика.
На аудите фиксируем, что и на чей аккаунт оформлено: сервер, домены, DNS, SSL, БД, платёжные сервисы, репозиторий, аналитика. Дальше — план перевода на ваши учётные записи без потери данных и без обрыва интеграций. Перенос идёт по окнам, с предварительным бэкапом и проверкой каждой части. Мы не обещаем «забрать» аккаунт, оформленный не на вас — это решается на стороне провайдера и в рамках законных процедур владельца аккаунта.
Это типовая ситуация после одиночной разработки — знания держались в голове одного человека. Документацию собираем сами по ходу аудита: схема инфраструктуры, описание ключевых сценариев, карта интеграций, регламент сборки и релиза, список владельцев аккаунтов. Цель — перенести проект из режима «работает, пока работает автор» в режим, где новый человек или команда может разобраться по документам.
Да. MVP — это нормальный исходный материал для подхвата, если есть продукт, у которого есть пользователи или клиенты. На аудите отделяем временные MVP-решения от долгоиграющей бизнес-логики, выделяем критичные модули и предлагаем план: что оставить, что стабилизировать, что переписать выборочно. Полный rewrite на этапе подхвата не предлагаем — это почти всегда длиннее и дороже, чем кажется.
Часто лучший сценарий — оставить исполнителя в проекте на согласованный период как носителя контекста: он отвечает на вопросы по архитектуре, помогает с передачей доступов, подтверждает решения по спорным местам. Параллельно мы заходим в режиме чтения и собираем картину в документы. Доступы и владение закрываются по письменному акту, а не «в фоне». Такой формат снижает риск конфликтов и потерь.
Иногда это правда. В отчёте честно скажем: точечный рефакторинг, поэтапная замена или переписывание выбранных частей. Решение принимаете вы, исходя из бизнес-приоритетов. Переписывание ради переписывания не предлагаем — оно почти всегда длиннее и дороже, чем кажется, и в первые месяцы продукт работает на старом коде, который кто-то всё равно должен поддерживать.
Да, и это часто лучший сценарий. Исполнитель остаётся в проекте носителем доменного знания на согласованный период: отвечает на вопросы по архитектуре, помогает с передачей доступов, подтверждает решения по спорным местам. Параллельно мы заходим в режиме чтения и собираем картину. Доступ прежнего исполнителя закрывается только по решению владельца проекта и письменному акту передачи, а не «в фоне».
В первую очередь имеет смысл забрать то, что блокирует работу нового исполнителя: репозитории и ветки на чтение, доступ к серверу и базе, env и секреты, домены и DNS, кабинеты платёжных сервисов, владение аккаунтами по документам. Документация и переписка важны, но второстепенно — их можно собирать по ходу. Чек-лист по приоритетам — отдельный артефакт аудита.
Заказать аудит проекта после фрилансера
Опишите проект, стек, какие доступы есть, что произошло с исполнителем и что сейчас нужно стабилизировать. Вернёмся с конкретикой и предложим стартовую сессию.
Подхват после фрилансера
Поля помечены под подхват после одиночного исполнителя: что за проект, какой стек, какие интеграции и доступы.
Заявка придёт на hi@khaiam.ru. Можно написать сразу в Telegram .
Заявка отправлена
Если задача срочная, можно сразу написать в Telegram .