Подготовка к проверке перед продажей продукта, созданного агентством

Почему работа агентства создаёт пробелы в проверке

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

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

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

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

Отсутствующие записи превращают простые вопросы в задержки. Покупатель спрашивает: «Кому принадлежит backend-код?», и команда начинает рыться в старых договорах, цепочках писем, выгрузках из Slack и заметках по передаче. Вопрос, который должен занимать пять минут, легко съедает неделю.

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

Простой пример хорошо показывает риск. Стартап заплатил агентству за разработку приложения, а потом выяснил, что production-сервер, аккаунт App Store и аналитические инструменты всё ещё находятся под контролем агентства. Продукт работал. Передача — нет.

Что покупатели спрашивают в первую очередь

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

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

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

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

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

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

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

Составьте карту владения

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

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

Начните с активов, которые важнее всего для покупателя: исходный код и конфигурации развертывания, дизайн-файлы и бренд-материалы, домены и DNS, базы данных и резервные копии, облачные аккаунты и аналитика, списки App Store, платёжные аккаунты и панели поставщиков.

Рядом с каждым пунктом пишите фактического владельца, а не того, кого вы считали владельцем. Если организацией GitHub владеет основатель агентства, так и укажите. Если аккаунт AWS оформлен на почту подрядчика, пометьте это. Если iOS-приложение публикуется из Apple Developer-аккаунта агентства, сразу отметьте это.

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

Стартап может фактически владеть кодом, но при этом агентство всё ещё контролирует production-сервер, регистратора домена и список в Play Store. Этого уже достаточно, чтобы затянуть сделку.

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

Соберите бумажный след

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

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

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

К каждому документу полезно добавить короткую заметку. Укажите дату, стороны, название проекта и место, где находится формулировка о передаче IP. Это сэкономит время позже, когда кто-то попросит подтверждение во время звонка по сделке.

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

Эти записи важны, потому что показывают полную цепочку: работу заказали, выполнили и приняли. Если агентство говорит: «Мы передали всё», цепочка из писем и счетов делает это утверждение реальным.

Сохраняйте чистые копии в одной папке с простыми именами файлов, например «2023-04-12_MSA_AgencyName_signed.pdf» или «2023-07-03_SOW_2_backend_changes.pdf». Храните подписанную версию и, если скан получился некачественным, ещё и читаемую копию.

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

Проверьте лицензии и аккаунты поставщиков

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

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

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

Включите open-source пакеты, платные библиотеки, шрифты, стоковые изображения, наборы иконок, плагины, шаблоны и размещённые инструменты. Затем проверьте реальные условия. MIT и Apache обычно создают меньше проблем, чем GPL или коммерческие лицензии, но не угадывайте. Прочитайте лицензию и отметьте все обязательства, такие как указание авторства, раскрытие исходного кода, лимиты на количество пользователей или ограничения на перепродажу.

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

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

Зафиксируйте, как продукт выходит в релиз

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

Начните с чёткого перечисления всех сред. У большинства команд есть development, staging и production, но работа с агентством часто оставляет лишние варианты, например demo-сервер, тестовый облачный аккаунт или второй production-сервер для hotfix. Если среда всё ещё существует, укажите её и объясните, зачем она нужна.

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

Затем опишите путь релиза простыми словами. Без жаргона. Покупатель должен понять его, даже если он никогда не видел ваш стек. Например: разработчик сливает код в main branch, CI-задача запускает тесты, сборка создаёт контейнерный образ, задача deploy отправляет его в staging, кто-то проверяет staging, и утверждённый человек выкатывает ту же версию в production.

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

Короткая заметка об откате тоже помогает. Если релиз ломается в 18:00, кому звонят, где смотрят в первую очередь и как восстанавливают последнюю рабочую версию? Даже полстраницы могут сэкономить дни вопросов от покупателя и показать, что продукт может работать без догадок.

Исправляйте пробелы в разумном порядке

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

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

Доступ агентства может исчезнуть очень быстро, иногда сразу после окончания контракта. До этого момента экспортируйте всё, что можно, из их инструментов. Сохраните журналы сборки, настройки развертывания, списки переменных окружения, записи DNS, дизайн-файлы, резервные копии, счета и историю изменений. Базовый экспорт сегодня может сэкономить дни догадок потом.

Хорошо работает простой порядок:

1. Подтвердите права собственности и право подписи.
2. Обеспечьте административный доступ к основным аккаунтам.
3. Экспортируйте записи из инструментов, которыми управляет агентство.
4. Восстановите недостающие заметки по развертыванию и восстановлению.
5. Сложите всё в одну общую папку.

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

Ошибки, которые затягивают сделку

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

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

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

Пробелы в доступах часто оказываются самой неудобной частью. Команда может контролировать репозиторий кода, но забыть про регистратор домена, DNS, почтовый сервис, аккаунт аналитики, Apple App Store, Google Play Console или владельца облачного биллинга. Эти аккаунты важны, потому что они управляют распространением, сбросом доступов, счетами и иногда самим брендом. Если они оформлены на почту агентства или логин бывшего основателя, покупатель остановится и спросит, кто вообще может передать это дальше.

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

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

Быстрый чек-лист для покупателя

Вам не нужен идеальный data room. Вам нужно чёткое подтверждение, что ваша компания владеет продуктом и сможет поддерживать его после ухода агентства.

• Договоры и описания работ должны явно передавать коды, дизайн, документацию и другие результаты вашей компании.
• У вашей команды должен быть административный доступ к репозиториям, облачному хостингу, DNS, App Store, аналитике, почте и платёжным инструментам.
• Реестр лицензий должен соответствовать продукту, который реально работает в production.
• Кто-то в вашей команде должен уметь развернуть продукт и откатить его без помощи агентства.
• В одной папке должны лежать бумажный след, список аккаунтов, заметки по развертыванию и краткое описание системы простым языком.

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

Если вы можете ответить на каждый пункт за несколько минут и сразу открыть подтверждающие файлы, процесс проверки проходит намного спокойнее.

Пример: стартап, у которого не хватало документов о передаче

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

Схема выглядела нормально, пока покупатель не начал проверку. Он задал три простых вопроса: кому принадлежит репозиторий кода, кто контролирует аккаунт AWS и где лежат исходные дизайн-файлы? У основателя были устные ответы, но не было бумажных доказательств. Агентство создало репозиторий в своём рабочем пространстве, открыло облачный аккаунт на свою почту и хранило дизайн-файлы во внутреннем инструменте.

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

Основатель исправил ситуацию за неделю, но только потому, что агентство пошло навстречу. Обе стороны подписали короткие дополнения, которые чётко зафиксировали права на код, дизайн и скрипты развертывания. Затем основатель перевёл доступы на корпоративные адреса и административные места. Репозиторий сменил владельца. Root-доступ и биллинг AWS тоже были перенесены. Дизайн-файлы оказались в рабочем пространстве, которое контролировала компания.

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

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

Что сделать до начала общения с покупателями

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

Этот первый проход должен закрыть пункты, которые быстрее всего меняют риск. Соберите подписанные передачи IP и договоры подрядчиков. Уточните, кто контролирует исходный код, домены, облачные аккаунты и аккаунты App Store. Напишите короткую заметку по развертыванию, которая показывает, как продукт выходит в релиз. Составьте список сторонних инструментов, платных сервисов и лицензий, которые нужно проверить.

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

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

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

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