Техническая проверка продуктов, сделанных фрилансером

Почему передача ломается после сделки

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

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

Пробелы в доступах встречаются ещё чаще. Покупатель может получить исходный код, но так и не получить облачный аккаунт, доступ к регистратору домена, аккаунт в app store, почтовый сервис, систему отслеживания ошибок или секреты CI. Какое-то время продукт с такими пробелами ещё работает. Потом истекает SSL-сертификат, для мобильной сборки нужен новый релиз, или ломается платёжный webhook после изменения API. И вдруг команда уже владеет бизнесом, но не может выкатить исправление.

Вот почему проверка продуктов, сделанных фрилансером, должна выходить за пределы репозитория. Рабочее приложение — это не то же самое, что приложение, которое можно передать.

Короткие сроки сделки делают ситуацию хуже. При спешке покупатели часто смотрят демо, бегло просматривают код и спрашивают: «Всё ли задокументировано?» Продавец отвечает «да», и процесс идёт дальше. Но это не показывает реальный риск. Непрерывность нельзя узнать по обещаниям. Её видно только тогда, когда проверяешь, может ли другой человек войти в систему, выкатить релиз, сделать откат и восстановить работу без исходного разработчика.

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

Что должен ответить короткий аудит

Короткий аудит должен ответить на один практический вопрос: сможет ли покупатель владеть продуктом и управлять им на следующий день после закрытия сделки, даже если исходный фрилансер перестанет отвечать?

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

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

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

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

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

Если продавец не может доказать эти базовые вещи за короткое время, риск не абстрактный. Он операционный, и обычно проявляется сразу после закрытия.

План аудита на 3 дня

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

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

В первый день соберите все репозитории, облачные аккаунты, логины у регистратора домена, список в app store, почтовый сервис, инструмент аналитики, платёжный аккаунт и систему ошибок. Сопоставьте каждый из них с указанным владельцем, администратором и контактным лицом по оплате. Если продавец говорит: «это ведёт фрилансер», считайте это риском, пока не увидите доступ.

Во второй день пройдите один реальный релиз от изменения кода до продакшена. Спросите, кто утверждает merge, кто запускает деплой, где лежат секреты и кто может откатить неудачный релиз. Потом передайте заметки по настройке другому разработчику и посмотрите, сможет ли он поднять приложение, прогнать тесты и пройти деплой без помощи. Это одно упражнение быстро показывает слабые места передачи.

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

Небольшой SaaS может выглядеть аккуратно в демо и при этом провалить такой аудит. Один частый сценарий легко пропустить: код лежит в GitHub, но продакшен-сервер работает из личного облачного аккаунта фрилансера, домен продлевается с его карты, а iOS-приложение опубликовано через его личный Apple ID. Покупатель не владеет бизнесом, пока не контролирует эти точки.

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

Проверяйте владение до того, как читать код

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

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

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

Затем сопоставьте юридического владельца со всеми аккаунтами, которые держат продукт живым. Проверьте хостинг кода, пакетные репозитории, секреты сборки, регистратора домена, DNS, SSL-сертификаты, облачные аккаунты, почтовые инструменты, систему ошибок и данные по оплате платных сервисов.

Здесь важны имена. Если продавец — компания, а счёт AWS, организация GitHub и регистратор домена находятся на трёх разных личных аккаунтах, у вас не аккуратная передача. У вас набор одолжений и старых логинов.

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

Проверяйте и сторонний код с той же тщательностью. Open source-библиотеки обычно несложны, но шаблоны, UI-kit'ы, наборы иконок и коммерческие компоненты могут ограничивать перепродажу, сублицензию или передачу. Если в продукте есть такой актив, читайте условия лицензии, а не предполагаете, что покупка всё покрывает.

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

Проследите путь релиза

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

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

Запишите каждую систему, которая хранит доступ или доверие на этом пути релиза. В небольших продуктах, сделанных фрилансером, секреты часто оказываются разбросаны по личным ноутбукам и старым аккаунтам. Здесь важны система контроля версий, CI/CD-инструменты, облачные серверы, репозитории пакетов, DNS, CDN, доменные аккаунты, хранилища секретов, файлы окружения, API-токены, ключи подписи и аккаунты app store для мобильных приложений.

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

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

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

Если продукт выпускается как iPhone- или Android-приложение, заранее проверьте контроль над аккаунтами Apple и Google. Покупатель может владеть кодом и всё равно застрять, если обновления зависят от личного developer-аккаунта или сертификата подписи фрилансера.

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

Проверьте, сможет ли новая команда взять продукт на себя

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

Попросите этого разработчика сделать три вещи по порядку:

1. Запустить приложение локально или в тестовой среде.
2. Изменить один безопасный параметр, например имя отправителя письма или feature flag.
3. Выкатить маленькое исправление через реальный путь деплоя.

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

Записывайте каждый вопрос, который он задаёт. Отсутствующие переменные окружения, непонятные секреты, неизвестные плановые задачи и комментарии вроде «спроси у фрилансера» показывают скрытую зависимость от памяти одного человека. Это не менее важно, чем качество кода.

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

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

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

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

Простой пример из небольшой SaaS-сделки

Покупатель смотрит на небольшой SaaS-продукт, который один фрилансер делал два года. У продукта есть платящие пользователи, демо выглядит гладко, а код в GitHub кажется достаточно чистым. На первый взгляд сделка выглядит малорискованной.

Но потом аудит выходит за пределы репозитория. Приложение читает и пишет в продакшен-базу, которая лежит в облачном аккаунте фрилансера. Бэкапы идут в тот же аккаунт. DNS и почтовые уведомления тоже живут там, поэтому покупатель может смотреть код, но всё равно не может самостоятельно запустить сервис.

С деплоем тоже всё выглядит нормально, пока кто-то не спрашивает, кто сможет выкатить исправление в пятницу вечером. Пайплайн релиза работает через приватную CI-систему, которой владеет фрилансер, и использует personal access tokens, созданные на имя этого человека. Если передача сорвётся, покупатель получит продукт, который работает, но не меняется.

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

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

Чистый код помогает, но чистый код не даёт вам фактическое владение бизнесом. Если один человек по-прежнему владеет базой данных, пайплайном и учётными данными, этот человек всё ещё контролирует продукт.

Ошибки покупателей в спешке

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

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

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

Спешка также заставляет игнорировать системы вокруг приложения. Именно там ломается много сделок. Продукт может зависеть от аккаунта app store, Stripe или другого платёжного сервиса, DNS, транзакционной почты, SMS, аналитики или support inbox, привязанного к личной почте фрилансера. Если хотя бы один из этих элементов остаётся не у того владельца, новый собственник может потерять продажи, сброс пароля или право на обновления.

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

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

Быстрая проверка перед подписью

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

Начинайте с владения. Git-репозиторий должен принадлежать компании, которая продаёт продукт, а не личному аккаунту фрилансера. Тот же стандарт применяйте к облачному аккаунту, регистратору домена, почтовому сервису, аккаунтам app store и платёжным инструментам. Если что-то из этого сидит внутри личного логина, вы ещё не контролируете продукт полностью.

Короткая проверка перед подписью может быть простой:

1. Подтвердите, что владелец репозитория совпадает с продавцом и что админский доступ можно передать покупателю.
2. Проверьте, где живут доступы к облаку, домену и оплате. Личные карты и приватная почта — плохой знак.
3. Попросите другого разработчика, не исходного фрилансера, поднять проект с нуля и отправить небольшое изменение.
4. Убедитесь, что бэкапы, логи и шаги отката работают не только в презентации и не только на словах.
5. Получите письменный список передачи, где указаны каждый владелец системы, аккаунт и шаг переноса.

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

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

Письменный список передачи закрывает разрыв между «у нас есть доступ» и «мы можем управлять этим в первый день». Имена, роли, аккаунты и даты переноса должны быть на одной странице. Если продавец сопротивляется такой ясности, считайте это риском сделки, а не бумажной формальностью.

Что делать, если нашли пробелы

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

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

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

Делайте задачи конкретными. Попросите создать новый админский аккаунт в системе контроля исходников, облаке, доменах, app store, мониторинге, бэкапах и почте. Попросите свою команду выполнить один реальный деплой до полного закрытия денег. Если они не могут безопасно выкатить маленькое изменение, вы всё ещё не контролируете продукт.

После закрытия первые 30 дней должны быть коротким планом, а не огромным проектом по зачистке. Решите, кто отвечает за поддержку, кто следит за оповещениями, кто может откатить плохой релиз и где будут жить секреты и биллинг-доступ. Небольшому SaaS не нужен идеальный процесс в первый день, но ему нужен хотя бы один путь релиза, который команда может пройти без помощи бывшего разработчика.

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

Если картина всё ещё кажется неясной, поможет точечная внешняя проверка. Oleg Sotnikov на oleg.is делает именно такие узкие проверки непрерывности, владения и деплоя для стартапов и небольших компаний — этого часто достаточно, чтобы увидеть реальный риск передачи до подписания.