Питч прошёл успешно, инвестор заинтересовался. На следующем этапе он присылает своего технического специалиста: проверяют код, серверы, команду и документы. Этот процесс называется техническим due diligence — и именно здесь многие сделки замедляются или дешевеют.
Причина обычно не катастрофа: недокументированный код, зависимость от одного разработчика, сервер без резервных копий. Но для инвестора каждый такой пункт — риск, а риск означает снижение оценки.
«Инвестор вкладывает деньги не в нынешнее состояние продукта, а в то, выдержит ли он завтра рост в 10 раз».
Выдержит ли система, если число пользователей вырастет в 10 раз? Какая часть «сломается» первой?
Читается ли код, есть ли тесты, правильно ли ведётся система контроля версий (Git)? Сколько времени нужно новому разработчику, чтобы включиться в работу?
Как хранятся пароли и ключи, защищены ли данные пользователей, когда в последний раз проверяли уязвимости?
Серверы, резервные копии, мониторинг. Если система остановится, за какое время её восстановят?
Кому принадлежит код? Переданы ли права компании в договорах с фрилансерами и подрядчиками? Какие лицензионные библиотеки используются?
Систему знает только один человек? Что будет, если он уйдёт? Есть ли документация?
Когда ответы на вопросы готовы, проверка длится дни, а не недели.
Меньше рисков — меньше поводов у инвестора снижать оценку.
Проблемы, найденные во время подготовки, нужно было исправить и без инвестора.
Репозиторий кода, домен, серверы и аккаунты сервисов должны быть оформлены на компанию.
Схема архитектуры, инструкция по запуску системы и причины ключевых решений — достаточно нескольких страниц.
До встречи с инвестором попросите внешнего специалиста проверить систему и исправьте самые серьёзные проблемы.