Продаёте компанию? Что найдёт технический дью-дилидженс покупателя и что исправить в первую очередь

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

КОРОТКО

Что на самом деле проверяет покупатель

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

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

Мы смотрим на это глазами тех, кто проводит такие проверки. В Peretz Agency технический дью-дилидженс ведёт Валерия Чумаченко, у которой больше десяти лет опыта в технологических M&A, а код, хостинг и данные проверяют наши разработчики. Версия этого списка для покупателя есть в статье Как провести аудит сайта или цифрового продукта перед покупкой. Здесь мы разворачиваем её и спрашиваем, с чего начать вам, владельцу.

Почти любую находку дешевле исправить, пока вас никто не ждёт.

МЕХАНИКА

Как находка доходит до цены

Самый известный пример настолько велик, что описан в публичном документе. В феврале 2017 года, когда Yahoo уже раскрыла свои утечки данных, Verizon и Yahoo договорились снизить цену на $350 млн, и сделка стала стоить около $4,48 млрд. Кроме того, Yahoo осталась ответственной за половину части денежных обязательств, связанных с этими утечками, уже после закрытия.

Marriott показывает обратный порядок, когда находка приходит после сделки. Атака на системы Starwood началась в 2014 году, до предложения Marriott о покупке, и оставалась незамеченной до сентября 2018 года. Британский регулятор оштрафовал Marriott на £18,4 млн, и унаследованная проблема стала его собственной.

Это гиганты, но механика работает и на меньших масштабах. В частной сделке среднего размера сомнение обычно превращается в удержанные деньги. Исследование SRS Acquiom за 2026 год охватывает более 2 300 сделок с частными компаниями, преимущественно с покупателями из США. По обзору юридической фирмы Fasken, медиана всех эскроу в 2025 году составила 10% стоимости сделки, а при страховании заверений и гарантий 2,8%. Средний размер эскроу вырос по сравнению с 2024 годом. В том же обзоре сказано, что в 22% сделок продавец не давал заверений о кибербезопасности, тогда как в 2024 году таких было 5%. Продавцы стали осторожнее с обещаниями, а у покупателя, который обещания не получил, появляется повод смотреть внимательнее.

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

ПРАВА НА КОД

Оплатить код ещё не значит владеть им

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

Циркуляр 30 Бюро авторских прав США ставит четыре условия, при которых заказанная работа считается служебной: она входит в один из девяти перечисленных видов, есть письменный договор, договор прямо это оговаривает, и его подписали все стороны. В перечне переводы, сборники, тесты и атласы. Обычный код приложения плохо вписывается в этот список, поэтому в договоры, как правило, добавляют прямую передачу прав.

В ОАЭ действует Федеральный закон № 38 от 2021 года, в котором появилось понятие служебного произведения. Как объясняет юридическая фирма Gowling WLG, автор, создающий работу для другого лица, оставляет права за этим лицом, если не договорились иначе, а передача будущих произведений ограничена и личные неимущественные права передать нельзя. Значит, договор с разработчиком всё равно стоит проверить, особенно если компания, подрядчики и покупатель находятся в разных странах. Покажите эту главу своему юристу по сделке: мы инженеры, а не адвокаты.

Пробелы обычно находятся в одних и тех же местах:

• Код, который основатель написал до создания компании и который компания формально никогда не получала.
• Первый фрилансер, с которым договорились устно или парой строк в письме.
• Договор с агентством, где ничего не сказано о правах на результат.
• Собственная библиотека подрядчика, которая попала в ваш продукт без письменных условий.

Есть первый взгляд, который можно бросить уже сегодня, и он лишь подскажет, где задавать вопросы. В репозитории команда git shortlog -sne --all выводит всех, кто отправлял код, с количеством коммитов и адресом почты. Положите этот список рядом с трудовыми договорами и договорами с подрядчиками. Каждое имя без подписанного документа становится вопросом к юристу. Git не покажет код, загруженный одним большим коммитом, и сотрудников агентства под общим аккаунтом, поэтому о них спросите отдельно. Чистый список сам по себе ничего не доказывает: выяснить, кто что писал, входит в работу специалистов.

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

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

Счёт доказывает, что вы заплатили. Владение доказывает только подписанный документ.

КОД ОТ ИИ

Новый вопрос на переговорах

Обычно в договоре покупатель просит подтвердить, что компании принадлежит её код. Подписать такую фразу стало сложнее. В отчёте Бюро авторских прав США за январь 2025 года сказано, что при нынешних технологиях одни только промпты не делают пользователя автором результата. Защита остаётся там, где ИИ служит инструментом, а выразительные элементы определяет человек, и ИИ-материал внутри большей человеческой работы не лишает защиты её человеческую часть. Решения принимаются в каждом случае отдельно.

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

Вторая половина вопроса касается лицензий. В отчёте Black Duck о рисках открытого кода в M&A за 2026 год сказано, что ИИ-ассистенты всё чаще вставляют в код фрагменты чужого кода, а лицензионные обязательства распространяются на фрагменты любого размера. Если первая версия вашего продукта сделана в основном с помощью ИИ и скоро её будут смотреть инвесторы, для этого у нас есть оценка MVP. Отдельный вопрос, действительно ли «ИИ» из вашей презентации принадлежит вам, разобран в статье Проблема AI Wrapper.

ОТКРЫТЫЙ КОД

Что напишут в отчёте аудита

Покупатели компаний с большой долей софта часто платят внешней фирме за проверку кода, в том числе потому, что продавцы, как правило, не передают код потенциальным покупателям напрямую. Аудитор видит то, чего покупатель не видит. Black Duck продаёт такие аудиты, так что учитывайте её интерес и то, что проверяет она в основном софтверные компании. Данные охватывают аудиты с ноября 2024 по октябрь 2025 года:

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

Ещё в отчёте сказано, что 16% найденных компонентов потребовали более глубокого анализа, потому что попали в код в обход менеджеров пакетов: скопированные папки поставщиков, вставленные фрагменты, код от ИИ-ассистентов. Их ваша быстрая проверка и пропустит.

Важность конфликта зависит от того, как бизнес зарабатывает. В отчёте условия copyleft описаны как проблема компаний, которые распространяют софт, поэтому о загружаемом продукте и о сайте, который вы только размещаете у себя, юрист может сказать совсем разное. Начните со списка. В PHP-проекте команда composer licenses выводит все зависимости с их лицензиями, для npm есть похожие инструменты. Уберите неиспользуемое, замените конфликтное и запишите, почему остальное допустимо. Такая команда видит только объявленные зависимости и не поймает скопированный код, о котором шла речь выше. Для этого нужны специальные сканеры и люди, которые умеют читать их результаты.

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

СТАРЫЙ СТЕК

Старая версия превращается в цифру

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

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

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

ПРОШЛЫЕ ИНЦИДЕНТЫ

Что вы не можете доказать

Ждите простых вопросов. Были ли инциденты безопасности за последние годы? Уведомляли ли клиентов? У кого сегодня есть доступ администратора? Когда кто-то в последний раз восстанавливал резервную копию и проверял результат? Самый трудный ответ звучит как «кажется, нет», ведь компания без логов не может показать, что ничего не случилось. История Marriott хорошо напоминает, как долго вторжение может оставаться незамеченным.

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

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

КЛЮЧЕВЫЕ ЛЮДИ

Что живёт в двух головах

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

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

НАСТОЯЩАЯ ПРОВЕРКА

Что владелец не проверит сам

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

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

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

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

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

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

ПИТЧ-ДЕК

Слой, который продаёт

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

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

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

Сильный дек хорошо делает несколько вещей:

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

Затем сверьте каждую техническую строку с комнатой данных. Если они расходятся, покупатель перестаёт верить деку:

Проверка защищает цену. Питч-дек её обосновывает.

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

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

ГРАФИК

За год до комнаты данных

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

Если вы ещё не решили, продавать ли вообще, начните на шаг раньше с услуги Сессия готовности к продаже бизнеса: сессия стоит $1 500, программа подготовки от $5 000. Речь там о решении владельца насчёт будущего, а не об оценке стоимости. Как и проверка, она даёт оценку и вектор, а сами исправления это отдельная работа. Если сделка не планируется и нужно понять, чем компания владеет и что арендует, подойдёт Аудит цифрового владения и долга: от $1 000, для крупного бизнеса от $3 000.

Продавец может заказать и ту же проверку, что и покупатель, через Сессию технического дью-дилидженс за $1 500 или полную проверку от $7 500. Цену работы, которая идёт дальше, мы можем назвать только после того, как увидим продукт. Вы получаете письменный отчёт и сессию, на которой мы разбираем его с вами и вашими консультантами. Каждая проверка начинается с того, как зарабатывает именно этот бизнес: конфликт лицензий, серьёзный для компании, поставляющей софт, у владельца магазина может оказаться сноской.

ВОПРОСЫ

Часто задаваемые вопросы

Что проверяет технический дью-дилидженс при продаже компании?

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

Стоит ли продавцу проводить проверку раньше покупателя?

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

Можно ли подготовиться к техническому дью-дилидженс самостоятельно?

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

Сколько времени занимает подготовка компании к продаже и сколько она стоит?

Идеально около года. От четырёх до шести месяцев это минимум для небольшого продукта и сделки на несколько миллионов, и команда порой нужна большая. Оценка занимает от пяти до десяти рабочих дней: сессия стоит $1 500, полная проверка от $7 500. У работы, которая идёт дальше, честной стартовой цены нет, потому что она зависит от продукта.

Когда писать питч-дек?

После технической проверки и основных исправлений, чтобы его утверждения выдержали аудиторов покупателя. Каждая техническая строка дека должна вести к документу в комнате данных. Дек, написанный первым, обычно обещает то, что проверка потом опровергает. Питч-деки мы делаем сами, когда продукт готов.

Могут ли технические находки сорвать сделку?

Могут, хотя чаще они меняют условия: снижается цена, растёт эскроу, появляются условия до закрытия или перенос сроков. Black Duck называет это обычными последствиями лицензионных проблем. Verizon и Yahoo снизили цену на $350 млн после утечек и довели сделку до конца.

Покупатель увидит мой исходный код?

Обычно не напрямую. Black Duck отмечает, что продавцы, как правило, не передают код потенциальным покупателям, поэтому его смотрят независимые аудиторы под NDA и передают покупателю выводы. Условия доступа согласуйте с юристом до того, как кто-то получит копию.

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

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

Проблема ли код, написанный с помощью ИИ, при продаже?

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

Источники

• Пресс-релиз Yahoo и Verizon о новых условиях сделки, документ SEC, 21 февраля 2017
• Black Duck: 2026 Open Source Risk in M&A by the Numbers
• Бюро авторских прав США: Circular 30, Works Made for Hire
• Бюро авторских прав США: Copyright and Artificial Intelligence, Part 2, январь 2025
• Fasken: выводы из исследования SRS Acquiom об условиях сделок за 2026 год, 7 мая 2026