2 мин чтения

Технический due diligence: на что смотрит инвестор

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

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

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

Архитектура и способность к росту

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

Технический долг и его реальная цена

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

Команда

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

Процессы и инфраструктура

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

Соответствие заявленному

Отдельно проверяется, действительно ли построено то, что продаётся. Расхождение между презентацией и реальным состоянием системы — частая и дорогая находка.

Какой получается вывод

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

Типичные тревожные признаки

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

В итоге

Цель технического due diligence — не найти идеальный код, которого не бывает, а дать инвестору ясное понимание рисков и потенциала, чтобы сделка совершалась осознанно, а не на доверии к презентации.