Технический due diligence: что инвесторы проверяют в стартапе
Продвинутое2 минРедакция Innovialabs
Коротко
Инвесторы проверяют, можно ли масштабировать продукт и не скрыты ли в нём риски: качество кода и архитектуры, безопасность, чистоту прав на код, зависимость от ключевых людей и наличие документации.
Короткий ответ
Технический due diligence отвечает на два вопроса: выдержит ли продукт рост и нет ли в нём рисков, которые обесценят сделку. Проверяют шесть областей: код, архитектуру, безопасность, права на интеллектуальную собственность, зависимость от людей и документацию. Цель — не найти идеальный код, а понять, сколько стоит исправить проблемы и насколько они критичны.
Что проверяют
Качество кода
- Читаемость и единый стиль, наличие code review.
- Автотесты на ключевую логику и их реальный запуск в CI.
- Технический долг: устаревшие зависимости, заброшенные модули, «временные» решения.
- История в Git: регулярные осмысленные коммиты или редкие огромные изменения.
Архитектура и масштабируемость
- Можно ли выдержать рост нагрузки без полной переписи.
- Как устроены база данных, очереди, кеши, внешние сервисы.
- Есть ли единые точки отказа.
- Сколько стоит инфраструктура и как растёт с числом пользователей.
Безопасность
- Хранение паролей и секретов (не в коде, не в открытом виде).
- Права доступа сотрудников к продакшену и данным.
- Обработка персональных данных и соответствие требованиям законодательства.
- Резервные копии и проверенное восстановление.
- Известные уязвимости в зависимостях.
Права на интеллектуальную собственность
Один из самых чувствительных пунктов:
- Переданы ли компании права на код от всех сотрудников, фрилансеров и подрядчиков.
- Какие open-source библиотеки используются и совместимы ли их лицензии с бизнес-моделью.
- Не написан ли код основателем до создания компании без последующей передачи прав.
Пробел здесь может остановить сделку, даже если технически продукт отличный.
Зависимость от людей
- Сколько человек понимают ключевые части системы.
- Что будет, если уйдёт технический сооснователь или единственный бэкенд-разработчик.
- Кто владеет доступами к доменам, облаку, репозиториям — компания или частные лица.
Документация и процессы
- Описание архитектуры и как развернуть проект с нуля.
- Процесс релизов, мониторинг, реакция на инциденты.
- Roadmap и понимание техдолга командой.
Как подготовиться
| Шаг | Что сделать |
|---|---|
| Доступы | Перевести все аккаунты на корпоративные, убрать личные |
| Права | Собрать договоры и акты передачи прав со всеми авторами кода |
| Лицензии | Составить список зависимостей с их лицензиями |
| Безопасность | Убрать секреты из репозитория, обновить уязвимые пакеты |
| Документация | Описать архитектуру, деплой и ключевые решения |
| Техдолг | Честно перечислить известные проблемы и план их решения |
Частые ошибки
- Скрывать известные проблемы: они всё равно найдутся, а доверие будет потеряно.
- Хранить исходники или облако на личных аккаунтах основателей.
- Не иметь подписанных документов с фрилансерами, которые писали ранние версии.
- Готовиться в последнюю неделю перед сделкой.
Частые вопросы
Нет. Инвесторы понимают, что у стартапа есть техдолг. Важнее, что команда его осознаёт, а критических рисков в безопасности и правах нет.