Детали статьи
Чек-лист технического due diligence, которым реально пользуются инвесторы
Техническое due diligence — это не оценка того, красив ли ваш код. Это ответ на один вопрос: сколько денег и времени отделяет компанию от следующего этапа её плана. Всё, на что смотрит ревьюер, — лишь индикатор этого.
Знание структуры позволяет провести проверку на себе первым — в этом и есть всё преимущество. Находки, обнаруженные внутри, остаются инженерными задачами. Те же находки, обнаруженные в ходе раунда, становятся переговорной позицией другой стороны.
Область 1 — права и лицензии
Проверяется первой, потому что при провале здесь остальное не имеет значения. Ревьюер устанавливает, что компания владеет тем, чем заявляет: трудовые и гражданско-правовые договоры с действительной передачей прав от каждого исполнителя, полный перечень зависимостей с лицензиями и отсутствие copyleft-кода внутри распространяемого коммерческого продукта.
Находка, которая бьёт больнее всего: зарубежные подрядчики с пунктом о конфиденциальности, но без передачи прав. Встречается часто, а исправление требует разыскивать бывших исполнителей — что невозможно в сроки сделки.
Область 2 — архитектура и масштабируемость
Вопрос не в том, «выдержит ли миллион пользователей» — этого никто не ждёт. Вопрос в том, достижим ли представленный вами план на этом фундаменте без переписывания. Ищут единые точки отказа, модели данных, которые не переживут следующую функцию, и связанность, делающую параллельную работу невозможной.
Находка, которая бьёт больнее всего: однотенантная архитектура у компании, продающей корпорациям. Мультитенантность, встроенная поздно, — одно из самых дорогих изменений в разработке.
Область 3 — безопасность и защита данных
Модель контроля доступа, управление секретами, шифрование при хранении и передаче, уязвимости зависимостей и то, как персональные данные хранятся, выгружаются и удаляются. Если вы продаёте в ЕС, Калифорнии или регулируемым клиентам, ревьюер сопоставит вашу реальную практику с тем, что обещает ваша политика конфиденциальности.
Находка, которая бьёт больнее всего: боевые доступы в истории репозитория. Обнаруживается мгновенно, не допускает толкований и подразумевает, что всё остальное делалось так же.
Область 4 — инженерные процессы
Практика код-ревью, покрытие тестами там, где это важно, CI/CD, соответствие окружений и история инцидентов. Ревьюеры читают ваш трекер задач и историю коммитов — это неотредактированные записи того, как команда работает на самом деле, поэтому они информативнее любого интервью.
Находка, которая бьёт больнее всего: все коммиты от одного человека. Это читается как риск ключевой персоны, каким бы сильным этот человек ни был.
Область 5 — команда и распределение знаний
Кто понимает какую часть системы, что произойдёт, если кто-то уйдёт, и позволит ли документация функционировать замене. Ревьюеры нередко просят инженера объяснить подсистему, которую он не писал. Ответ и есть оценка.
Область 6 — эксплуатация и стоимость
Стоимость инфраструктуры на клиента и то, улучшается она или ухудшается при росте. Мониторинг, оповещения, резервные копии и восстановление — с доказательством, что восстановление реально проводилось. История доступности, а не цели по доступности.
Находка, которая бьёт больнее всего: юнит-экономика, ухудшающаяся с ростом. Она превращает историю роста в историю расходов за один слайд.
Проведите проверку на себе
Возьмите неделю. По каждой из шести областей подготовьте документ с ответами на вопросы выше — с доказательствами, а не с заверениями. Вы найдёте три-четыре пробела. Исправьте то, что успеваете, и напишите честный план устранения с датами по остальному.
Раскрыть известную проблему вместе с планом — признак хорошо управляемой компании. Позволить ревьюеру найти ту же проблему — признак обратного. И разница измеряется в оценке компании, а не в инженерии.
Due diligence решает не то, хороша ли ваша технология. Оно решает, у кого будет информационное преимущество в переговорах, которые последуют.
Мы проводим такую проверку по фиксированной цене и отдаём письменный отчёт с приоритизированным планом устранения. Основатели обычно заказывают её за восемь-двенадцать недель до раунда — пока находки ещё остаются просто работой.
Наши новости
Как выбрать первый AI-процесс: оценочная карта
Шесть критериев по пятибалльной шкале. Всё, что ниже двадцати, — второй проект, а не первый.
Платный discovery за две недели, который снимает риск с крупного проекта
Бесплатные предложения делаются, чтобы выиграть работу, а не чтобы быть точными. Платный discovery — самая дешёвая страховка для основателя.
Фикс, почасовка или выделенная команда: какая модель защищает вас
Любая договорная модель куда-то перекладывает риск. Куда именно — и какие пункты договора важнее самой модели.
AI-функции, работающие с данными клиентов: базовый уровень комплаенса
До того как агент прочитает первую клиентскую запись, должны существовать семь контролей. Их сборка занимает дни, а достройка задним числом — годы.