Консалтинг
Технический due diligence перед инвестициями или покупкой бизнеса
Red flag в кодовой базе не всегда убивает сделку — чаще он меняет цену, эскроу или обязательства после закрытия. Разбираем, что проверяется и почему спешка под давлением сроков сделки вредит именно находкам.
Коротко
Технический due diligence — разовая, привязанная к срокам сделки проверка технического состояния компании перед инвестицией или покупкой: кодовая база, архитектура, bus factor, безопасность, инфраструктура и реальная стоимость дальнейшего развития продукта. В отличие от обычного код-ревью, цель — не стиль кода, а риск для сделки: находка не всегда убивает сделку, чаще она меняет цену, эскроу или обязательства по устранению после закрытия.
Кому это нужно и когда
Три типичных заказчика: инвестор перед раундом финансирования, который хочет понять, во что реально вкладывается технически, а не только в презентацию; покупатель бизнеса или продукта, для которого техническое состояние напрямую влияет на цену сделки; и, реже, сам фаундер перед привлечением инвестиций, который предпочитает найти проблемы сам и исправить их заранее, а не узнать о них от инвестора в неудобный момент.
Это принципиально разовый, привязанный к срокам сделки формат — не ongoing-консалтинг. Отчёт готовится под конкретное окно принятия решения, а не в спокойном темпе обычного технического аудита.
Что именно проверяется
| Область | Что проверяется |
|---|---|
| Кодовая база | Качество, тестовое покрытие критичной логики, накопленный технический долг |
| Архитектура | Способность масштабироваться, единые точки отказа |
| Bus factor | Сколько людей понимают систему целиком, что будет при уходе ключевого разработчика |
| Безопасность | Базовые проверки: хранение паролей, секреты в репозитории, права доступа |
| Инфраструктура и зависимости | Актуальность, лицензии, зависимость от конкретного вендора |
| Стоимость развития | Реальная оценка, во что обойдётся продолжать развивать продукт после сделки |
Red flags, которые встречаются непропорционально часто
Некоторые находки повторяются от проверки к проверке настолько часто, что их стоит перечислить конкретно, а не абстрактно. Вся система понятна одному человеку, который не остаётся в компании после сделки, — это не гипотетический риск, а прямая угроза непрерывности бизнеса в первые же недели после закрытия. Полное отсутствие тестов на платёжной или другой критичной для бизнеса логике — означает, что любое изменение в этой части системы вносится вслепую.
Активно неподдерживаемые зависимости с известными уязвимостями — тихий риск, который не проявляется, пока кто-то не воспользуется известной дырой. Недокументированные «временные» архитектурные решения трёхлетней давности, которые давно стали несущими, — классический признак системы, устройство которой уже никто полностью не помнит, включая тех, кто её строил.
Как находки превращаются в условия сделки
Это часть, которую стоит понимать и фаундеру на другой стороне стола: red flag почти никогда не означает автоматический провал сделки. Гораздо чаще он превращается в конкретный, обсуждаемый пункт условий: корректировку цены, отражающую реальную стоимость устранения проблемы; часть суммы, удерживаемую на эскроу до момента, пока конкретная находка не будет закрыта; или обязательство продавца устранить проблему в оговорённый срок после закрытия сделки.
Понимание этого механизма снимает часть тревоги у обеих сторон: цель проверки — не найти повод отказаться от сделки, а дать обеим сторонам точную картину риска, чтобы условия сделки эту картину честно отражали.
Что нужно от целевой компании и сколько это занимает
Для полноценной проверки нужен доступ к репозиторию с полной историей коммитов, логам деплоя, инцидентам за последние 6–12 месяцев и, желательно, короткому разговору с текущей технической командой. Реалистичный срок — 1–2 недели, синхронизированный с общим графиком сделки, а не с темпом обычного консалтинга.
Спешка под давлением сроков сделки — прямая угроза качеству находок. Проверка, сжатая до двух-трёх дней под давлением закрытия сделки, физически не успевает дойти до менее очевидных проблем — она находит только то, что лежит на поверхности, а самые дорогие риски почти никогда там не лежат.
Чем это отличается от обычного код-ревью
Обычное код-ревью спрашивает «хорошо ли написан этот код». Технический due diligence спрашивает «какой риск для этой конкретной сделки несёт состояние этой системы». Разница не терминологическая: due diligence может признать код стилистически несовершенным, но низкорисковым для сделки, если, например, эта часть системы будет полностью переписана в первый год после закрытия в любом случае — и, наоборот, отметить формально аккуратный код как высокий риск, если весь он понятен одному уходящему разработчику.
Частые вопросы
Технический red flag всегда убивает сделку?
Почти никогда автоматически. Находка обычно превращается в конкретное, обсуждаемое условие: корректировку цены, часть суммы на эскроу до устранения проблемы, или обязательство продавца исправить её в оговорённый срок после закрытия. Цель проверки — дать обеим сторонам точную картину риска, а не найти повод отказаться от сделки.
Сколько времени занимает технический due diligence?
Реалистично — 1–2 недели, синхронизированные с общим графиком сделки. Для этого нужен доступ к репозиторию с полной историей коммитов, логам деплоя и инцидентам за последние 6–12 месяцев. Сжатие проверки до двух-трёх дней под давлением сроков сделки напрямую снижает качество находок — обнаруживается только то, что лежит на поверхности.
Чем это отличается от обычного код-ревью или аудита?
Обычное код-ревью и общий технический аудит оценивают качество кода и системы саму по себе. Due diligence оценивает риск конкретно для этой сделки: находка может быть некритичной для продолжения работы продукта, но критичной для инвестора именно в контексте сделки — например, если весь код понятен одному уходящему после продажи разработчику.
Кто обычно заказывает технический due diligence?
Чаще всего инвестор перед раундом финансирования или покупатель перед приобретением бизнеса или продукта. Реже — сам фаундер перед привлечением инвестиций, чтобы найти и исправить проблемы заранее, а не узнать о них от инвестора в неудобный момент переговоров.
Нужна помощь с этой задачей?
Мы делаем это на практике, а не только пишем об этом. Опишите задачу — разберём и пришлём смету по этапам.
Услуги по теме
- CTO на аутсорсСтартапу на ранней стадии часто не по карману штатный технический директор, но без технического голоса в решениях компания рискует выбрать не тот стек, нанять не тех людей или неверно представить продукт инвестору. CTO на аутсорс закрывает эту роль на частичной занятости — ровно в том объёме, который нужен сейчас.
- IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
Читать дальше
- CTO на аутсорс: когда стартапу нужен технический директорНетехнический фаундер регулярно принимает технические решения без права на ошибку. CTO на аутсорс — не роскошь для стадии roundА, а способ не платить за эти ошибки позже.
- Как выбрать подрядчика на разработку: чек-лист вопросов и красные флагиПрактическое руководство по выбору подрядчика: кому подходит фрилансер, а кому интегратор, какие 25 вопросов задать на первом созвоне, как проверить кейсы в портфолио и что обязательно должно быть в договоре.
- Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.