Due diligence фракционного CTO: что нужно подготовить инвесторам

Почему due diligence идет не по плану

Инвесторские созвоны редко сбиваются с курса из-за того, что продукт слишком сложный. Обычно проблема в том, что простые факты не готовы к моменту вопроса.

Основателю задают базовый вопрос о правах на код, договорах с подрядчиками, доступе к облаку или о том, кто контролирует production-аккаунты. Если ответ идет из памяти, а не из документов, тон разговора быстро меняется. Инвесторы перестают слушать историю бизнеса и начинают проверять, действительно ли компания контролирует то, что создала.

Это дорого обходится. Созвон, который должен быть сосредоточен на росте, марже, найме и направлении продукта, превращается в поиск недостающих документов. Люди начинают спрашивать, где подписанные документы о передаче IP, кому принадлежит домен, почему у бывшего фрилансера все еще есть доступ или совпадает ли основной репозиторий с юрлицом компании.

Проблема усугубляется, когда команда рассказывает разные версии одной и той же истории. Один основатель говорит, что первый релиз собрали агентство и потом передали все права. Инженер говорит, что в истории коммитов до сих пор видны два внешних разработчика, а бумаги по ним неясны. Кто-то из ops говорит, что облачный аккаунт сначала был на личной карте, а потом его перевели. Каждый ответ по отдельности кажется мелким. Вместе они создают впечатление, что компания неорганизованна.

Небольшие пробелы вызывают сомнения быстрее, чем многие основатели ожидают. Инвесторы знают, что молодые стартапы не бывают идеальными. Их беспокоит то, чего можно было избежать. Если команда не может четко и последовательно ответить на вопросы о правах и поставке, инвесторы могут решить, что за кулисами скрываются более серьезные риски.

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

Плохой ответ может стоить пяти минут в календаре. А вот уверенности он может стоить гораздо больше.

Что хотят увидеть инвесторы

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

Сначала — права собственности. Инвесторы хотят знать, кто написал код, кто придумал продукт и принадлежит ли эта работа компании. Если на раннем этапе помогали фрилансеры или агентства, подписанные документы о передаче IP важнее длинных объяснений. Неровная история здесь сразу заставляет людей думать, что неясностей больше.

Им также нужен правдоподобный след релизов. Это не значит красивые слайды. Это значит показать, как команда выпускала продукт со временем. Заметки о релизах, история задач, pull request’ы, краткие итоги спринтов или даже простой changelog могут подойти. Инвесторы ищут закономерность: команда выпускала продукт стабильно или прогресс зависел от нескольких авральных рывков перед встречами?

Недавние релизы особенно важны, потому что показывают продукт таким, какой он есть сейчас, а не полгода назад. Основатель должен уметь объяснить, что изменилось, зачем это было нужно и как это повлияло на пользователей или выручку. Если был большой переписанный кусок, скажите об этом прямо. Если команда заменила модуль, который сделал подрядчик, тоже скажите.

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

Такая заметка экономит время, потому что показывает здравый подход. Хороший фракционный CTO обычно готовит этот материал до того, как его кто-то попросит, чтобы основатели отвечали фактами, а не памятью.

Наведите порядок в правах собственности заранее

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

Начните с репозиториев. Каждый активный репозиторий должен быть привязан к реальному человеку или компании: сотруднику, основателю, подрядчику или агентству. Если в репозитории есть коммиты с неизвестного аккаунта, старого фрилансера или личной почты, которую никто не может объяснить, разберитесь с этим сейчас. Инвесторы не любят загадочных авторов в production-коде.

Чаще всего это проблема документов, а не кода. Программное обеспечение может работать отлично, но если стартап не может доказать права собственности, риск из технического становится юридическим.

Базовая проверка должна включать список репозиториев и текущих владельцев, подписанные договоры с сотрудниками и подрядчиками, формулировки о передаче IP для всех, кто работал над продуктом, заметки по агентствам и бывшим поставщикам, а также короткий список кода, происхождение которого вы пока не можете подтвердить уверенно.

Не думайте, что старые договоры автоматически покрывают IP. Во многих это не так. Счет от подрядчика — не то же самое, что подписанная передача прав. Если кто-то сделал ключевую функцию еще до создания компании, проверьте, перешла ли эта работа в компанию на бумаге.

Внешний код требует такого же внимания. Составьте простой список платных компонентов, библиотек с открытым исходным кодом, шаблонов, SDK и любых повторно использованных внутренних инструментов из прошлых проектов. Для каждого укажите лицензию. Большинство инвесторов не паникуют из-за обычного использования open source. Их насторожит ситуация, когда никто не может объяснить, откуда взялась важная часть продукта.

Если найдете что-то проблемное, отметьте это прямо, а не прячьте. Можно написать, что ранний прототип мобильного приложения делало небольшое агентство, компании еще нужна подписанная передача IP, и команда либо заменит этот код, либо получит подпись до закрытия сделки. Четкие заметки успокаивают. Отсутствие фактов — наоборот.

Хороший фракционный CTO может разобрать это за несколько сфокусированных сессий. Цель проста: ни один инвестор не должен тратить созвон на выяснение, кому принадлежит кодовая база.

Покажите, как команда выпускает продукт

Инвесторам не нужна идеальная история. Им нужно подтверждение, что команда умеет планировать работу, выпускать изменения и реагировать, когда что-то идет не так.

Простая временная шкала релизов здесь очень помогает. Одна страница с датами, версиями и короткими примечаниями о том, что было выпущено, часто уже достаточно, чтобы сделать due diligence спокойнее. На практике такой документ обычно отвечает на большее число вопросов, чем красивая дорожная карта.

Если ваш стартап работает спринтами, держите записи простыми и удобными для просмотра. Сохраняйте важные задачи, заметки по спринтам и записи changelog, связанные с каждым релизом. Не нужно сохранять каждый комментарий по каждой задаче. Но нужно достаточно, чтобы показать: работа двигалась от идеи к задаче и дальше к релизу нормальным, повторяемым способом.

Обычно достаточно небольшого набора записей: даты релизов с короткими примечаниями, несколько примеров задач, которые прошли путь от планирования до выпуска, changelog, совпадающий с этими релизами, заметки по спринтам или еженедельные сводки, а также логи деплоя или CI, которые показывают, когда код ушел в продакшн.

Тестирование и выпуск тоже важны. Инвесторы часто спрашивают об этом простыми словами: как вы не даете плохим изменениям попасть к пользователям? Дайте прямой ответ. Покажите, где происходит code review, какие тесты запускаются перед релизом, кто утверждает изменения в production и как команда откатывает неудачный деплой.

Крупные инциденты должны быть в файле, а не в чьей-то памяти. Если у продукта был сбой, запишите, когда это случилось, что почувствовали пользователи, что стало причиной и что команда изменила после этого. Короткая заметка вроде «не удалась миграция базы данных, checkout был недоступен 18 минут, добавили проверку на staging и шаг отката» показывает зрелость быстрее, чем длинные оправдания.

Если команда уже использует такие инструменты, как GitLab, Sentry, Grafana или CI/CD-пайплайны, опытный фракционный CTO обычно может собрать эти подтверждения без лишней работы. Часто именно это и отличает напряженный инвесторский созвон от спокойного.

Пишите заметки о рисках, которые экономят время

Инвесторы не ждут, что стартап будет без рисков. Они ждут, что команда понимает, что может сломаться, насколько это серьезно и что будет дальше. Короткая заметка о риске помогает удержать разговор в нужном русле и не уводит его в 15-минутный обход по кругу.

Делайте каждую заметку короткой. Трех-четырех строк обычно хватает. Используйте простые слова, без внутреннего жаргона, и не драматизируйте. Фраза «в форме сброса пароля нет ограничения по частоте» говорит куда больше, чем расплывчатый комментарий об уровне безопасности.

Хорошая заметка о риске отвечает на четыре вопроса: в чем проблема, кого или что она затрагивает, каков текущий статус и какое следующее действие и кто за него отвечает.

Проблемы безопасности и операций тоже относятся сюда. Если бэкапы выполняются, но никто не проверял восстановление, так и напишите. Если у одного старшего инженера до сих пор единственный production-доступ к сервису, так и напишите. Если логирование есть, но алерты не покрывают неудачные платежи или неудачные деплои, тоже скажите об этом.

Тон имеет значение. Когда возможно, описывайте влияние в бизнес-терминах. «Может задержать корпоративное подключение» или «Может вызвать несколько часов простоя во время релиза» говорит инвесторам больше, чем плотная техническая заметка.

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

Простой пример хорошо показывает разницу. Представьте, что стартап зависит от одного облачного аккаунта, который все еще оформлен на бывшего подрядчика. Это не вопрос хозяйственного порядка. Это риск доступа, биллинга и непрерывности. Заметка может быть короткой: передача прав в процессе, простоя сегодня нет, целевая дата — следующая пятница, ответственны основатель и CTO.

Хорошие заметки о рисках делают команду спокойной и честной. Они показывают контроль без притворства, что все идеально. Обычно этого достаточно, чтобы разговор с инвестором оставался о бизнесе, а не о хаосе вокруг него.

Как это готовит фракционный CTO

Хороший фракционный CTO начинает с самых скучных, но важных подтверждений. Инвесторы хотят понять бизнес, но разговор быстро уходит в сторону, если никто не может показать, кому принадлежит код, у кого есть доступ к production и как команда выпускает изменения.

Обычно работа идет в пять проходов.

1. Собрать исходные материалы в одном месте. Сюда входят репозитории, договоры с сотрудниками и подрядчиками, облачные аккаунты, записи о доменах, списки доступа к поставщикам и логи деплоя. Если что-то лежит в почте одного из основателей, перенесите это сейчас.
2. Разделить все на три группы: права собственности, релизы и риски. Права собственности включают передачу IP, контроль над аккаунтами и админские права. Релизы включают историю релизов, трекинг задач, записи тестов и то, кто утверждал изменения. Риски включают открытые проблемы безопасности, single point of failure и слабые места, которые команда планирует исправить.
3. Закрыть простые пробелы до первой встречи. Удалить устаревшие админские аккаунты, исправить отсутствующий доступ к репозиториям, собрать неподписанные бумаги и записать, кто контролирует каждый сервис. Небольшие исправления сейчас избавляют от неловких пауз потом.
4. Назначить одного человека, который будет отвечать на технические вопросы. Инвесторам не нужны три основателя, которые дают три разных ответа. Фракционный CTO может делать ответы короткими, фактологичными и последовательными.
5. Подготовить резервные файлы. На первом созвоне вам могут не понадобиться все счета, экспорты доступа или записи коммитов, но вы должны быстро отправить их, когда появятся уточняющие вопросы.

Смысл не в том, чтобы сделать компанию идеальной. Смысл в том, чтобы сделать записи понятными и легкими для проверки.

Хорошо работает простой тест: если новый инвестор спрашивает «Кому это принадлежит, кто это менял и что может сломаться?», ваша папка должна отвечать на все три вопроса за несколько минут. Тогда разговор останется о продукте, рынке и плане, а не о предотвратимой путанице.

Простой пример из процесса привлечения инвестиций

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

Ничего не выглядело подозрительно. Просто все было неаккуратно. У двух подрядчиков договоры были подписаны в разное время, один делился работой через личный репозиторий до переноса, а основатель не мог быстро достать все бумаги о передаче прав из одной папки.

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

Именно тут помогает проверка фракционного CTO. Исправление было не драматичным. Это была короткая уборка.

Сначала команда сопоставила каждого, кто касался кода, с договором и историей репозитория. Они нашли одну подпись, которой не хватало, отправили документ на подпись и подшили подписанную копию вместе с остальными. Затем они создали простой реестр прав собственности, который показывал, кто что сделал, когда над этим работал и где лежат подписанные документы.

Потом они восстановили историю релизов. Они собрали даты релизов из git tags, issue-задач и заметок по деплою, а затем свели все в одну временную шкалу с короткими комментариями. Никакой красоты. Просто достаточно, чтобы показать стабильный выпуск, реакцию на баги и то, какие релизы были важны.

Они также добавили короткую заметку о рисках. В ней простым языком было сказано, что компания привела в порядок документы подрядчиков, централизовала записи и не нашла споров по правам на код. Там же был указан один небольшой пробел, который уже закрыли.

К тому моменту, когда начались разговоры с инвесторами, неудобные вопросы стали короче. Никто не тратил двадцать минут на выяснение, кому принадлежит функция или может ли подрядчик потом заявить права. Разговор вернулся к продукту, росту и тому, что команда планирует делать дальше.

Именно в этом часто и есть разница между напряженным due diligence и спокойным. Компания не изменила бизнес. Она просто убрала лишние сомнения.

Ошибки, которые создают лишние сомнения

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

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

Сырые проектные данные тоже могут сыграть против вас. Папка, полная задач, логов коммитов и выгрузок из чатов, выглядит очень занято, но не отвечает на главный вопрос: может ли эта команда планировать работу и доводить ее до конца? Если отправить 400 задач Jira без сводки, без заметок о релизах и без пометок, что дошло до production, читателю приходится гадать. А догадки обычно превращаются в сомнения.

Известные проблемы создают еще больше проблем, когда компания пытается их скрыть. Проверяющие все равно часто находят их. Они видят устаревшую зависимость, неустойчивый логин-флоу, отсутствие теста восстановления или одного инженера, который пока слишком много знает один. Если они обнаружат это раньше, чем вы сами упомянете, проблема кажется больше, чем есть на самом деле. Короткая заметка, которая говорит, в чем проблема, кто за нее отвечает и когда вы планируете ее исправить, обычно воспринимается лучше.

Записи, которые противоречат друг другу, — еще один тревожный сигнал. В cap table может быть указан бывший сооснователь, а в репозитории видно, что он писал часть billing-системы, но в папке нет подписанной передачи прав. Или файл HR говорит, что инженер ушел в марте, а логи доступа показывают активные учетные данные в апреле. Именно такие несоответствия уводят разговор от роста, клиентов и продукта.

Расплывчатые ответы о собственности быстро делают все хуже. «Компания владеет этим» — недостаточно. Люди хотят знать, какой код написали сотрудники, какой — подрядчики, как учитывается open source и не создает ли работа с клиентами проблем с повторным использованием.

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

Быстрая проверка перед созвоном с инвестором

Последняя проверка перед созвоном с инвестором должна казаться скучной. Это хороший знак. Если людям приходится судорожно искать ответы на базовые вопросы о правах собственности или релизах, разговор быстро уходит от роста и продукта к лишней путанице.

Обычно короткий финальный проход находит большую часть проблем:

• У каждого репозитория есть один указанный владелец, и команда согласна, кто это.
• У каждого подрядчика, который работал с кодом, дизайном или продуктом, есть подписанная передача IP в файлах.
• Последние релизы совпадают с тем, что стартап показывает в демо, презентациях и заметках для инвесторов.
• По известным рискам есть короткие письменные заметки с датами, статусом и тем, кто ими занимается.
• Один человек отвечает за папку для due diligence и может достать любой документ за секунды.

Последний пункт важнее, чем думают многие основатели. Инвесторы не ждут идеала, но ждут четких ответов. Если три человека считают, что папкой занимается кто-то другой, простые запросы превращаются в длинные цепочки писем.

Недавние релизы тоже стоит быстро проверить на соответствие реальности. Если в презентации написано, что продукт поддерживает определенную функцию, это должны подтверждать release notes, changelog или внутренние записи о поставке. Несоответствие не всегда разрушает доверие, но очень быстро рождает сомнения.

Заметки о рисках должны быть короткими. Одна-две строки на проблему достаточно, если они отвечают на очевидные вопросы: что произошло, когда команда это заметила, на что это влияет и что дальше. Инвесторы нормально воспринимают риски. Их тревожит, когда команда удивляется собственным системам.

Если основателю нужен один принцип на день перед созвоном, пусть это будет такой: никаких неотвеченных вопросов о правах собственности. Фракционный CTO может быстро сделать этот финальный проход и убедиться, что встреча будет о бизнесе, а не о недостающих бумагах.

Что делать дальше

Выделите одну сессию и вместе с человеком со стороны основательской команды разберите материалы для due diligence. Основатели часто заполняют пробелы из памяти, даже не замечая этого. Сторонний человек остановится на каждом неясном месте, и именно этого вы и хотите до того, как это сделает инвестор.

Начните с прав собственности. Проверьте договоры с подрядчиками, бумаги о передаче прав на разработки, доступ к репозиториям, использование open source и любой код, который пришел от прошлых агентств или фрилансеров. Исправьте недостающие подписи до начала активного общения. Когда компания начинает метаться за бумагами уже во время раунда, маленький пробел может выглядеть как более глубокая проблема.

Потом превратите историю разработки в короткий рассказ, который людям легко понять. Держите его простым и фактическим: что команда построила, кто это поддерживал, как выходят релизы, что ломалось раньше и что изменилось после этого. Хорошие заметки не пытаются никого впечатлить. Они помогают инвестору понять бизнес, не застревая в грязных деталях.

Простой порядок работает хорошо. Попросите внешнего человека прочитать data room и отметить все места, где что-то непонятно. Соберите и подпишите недостающие документы о правах собственности. Напишите одностраничную сводку по процессу релизов, системам и известным рискам. Потом потренируйте прямые ответы вместе с основателями и техническим лидом.

На это не нужны месяцы. Часто хватает одной сфокусированной недели, чтобы привести большую часть в порядок. Один стартап может выглядеть неорганизованным из-за неаккуратной папки с договорами и разрозненных ответов в Slack, а через несколько чистых документов и понятную временную шкалу — уже готовым к due diligence.

Если команда маленькая или уже перегружена, внешняя помощь может ускорить процесс. Oleg Sotnikov на oleg.is делает такую работу как Fractional CTO для стартапов — от наведения порядка в правах собственности и инфраструктурных записях до подготовки команды к техническим вопросам инвесторов. Это помогает держать разговор о traction, продукте и планах, а не о предотвратимой путанице.