ViktorIvanov
New member
Недавно я заканчивал четвёртый технический аудит стартапа за последние два года, и каждый раз убеждаюсь в одном: инвесторы часто смотрят на цифры и рынок, но забывают про код. А код — это фундамент, который может рухнуть в любой момент. Однажды я зашёл в репозиторий «обещанной платформы с архитектурой микросервисов», а там оказался монолит на PHP 5.6 с комментариями вроде TODO от 2017 года. Инвесторы чуть не вложили семизначную сумму в проект, который нужно было переписывать с нуля. С тех пор я всегда держу под рукой свой чек-лист и готов поделиться им с вами.
Первое, что я делаю при техаудите, — смотрю на структуру кодовой базы и качество кода. Не нужно быть фанатом чистоты, но базовые вещи должны быть на месте: есть ли модульность, разделение ответственности, адекватные размеры файлов. Я открываю несколько случайных модулей и оцениваю: можно ли понять логику за десять минут, или это чёрный ящик, в который заглядывал только один человек? Если второй вариант — это красный флаг, особенно если тот человек не в команде. Код, который написан одним человеком и не имеет документации, — это риск на миллион.
Второй блок — инфраструктура и деплой. Я всегда спрашиваю: как разворачивается приложение в прод? Есть ли CI/CD, или кто-то руками копает по SSH-сессиям? Проверяю, есть ли мониторинг, алерты, бэкапы. Звучит банально, но я видел стартапы, у которых бэкапы не работали полгода, и никто не знал. Инвесторам это не видно в презентации, но если завтра упадёт сервер с базой данных, деньги сгорят быстрее, чем вы успеваете сказать «давайте сделаем раунд».
Третий момент — безопасность. Я не прошу вас делать пентест на каждом этапе, но базовые вещи обязательны: есть ли управление секретами, используются ли устаревшие библиотеки с известными уязвимостями, есть ли аутентификация и авторизация на всех критичных маршрутах. Однажды я нашёл в коде открытый API-ключ к облачному провайдеру, который лежал в открытом репозитории. Это не только безопасность, это прямые деньги, которые утекают через кран. Такие вещи нужно проверять всегда.
Четвёртое — командная скорость и процесс разработки. Я смотрю на гит-историю: как часто коммитят, есть ли code review, как устроены ветки. Если у вас три разработчика и все коммитят в мастер без ревью, то при росте это превратится в ад. Также обращаю внимание на документацию: есть ли внутренние wiki, описание архитектуры, процесс онбординга нового разработчика. Если новый человек не может начать работать за день-два, у вас проблема с масштабируемостью.
Пятое и последнее — соответствие кода бизнес-требованиям. Это то, что часто упускают. Я спрашиваю: что именно делает продукт, какие фичи обещаны клиентам, и потом иду смотреть в код. Бывает, что в презентации заявлены интеграции, которые не реализованы, или что ключевая бизнес-логика завязана на костылях и хардкодах. Технический аудит — это не просто «код красивый или нет», это понимание того, что вы сможете масштабировать продукт без переписывания всего с нуля.
Мой совет всем, кто участвует в инвестиционных процессах: не бойтесь задавать неудобные вопросы команде разработчиков. Они не должны обижаться — хороший CTO или тимлид будет рад, что вы ищете проблемы до того, как они станут критичными. А если команда закрывается, оборачивается и пытается продавить инвестиции на словах «да мы потом всё переделаем» — это повод насторожиться. Технический долг не исчезает сам, он копится и отнимает время, деньги и нервы.
А как вы проводите технический аудит перед инвестициями? Есть ли у вас свои критерии, которые вы считаете обязательными? Буду рад обсудить — делитесь опытом в комментариях, это полезно всем.
Первое, что я делаю при техаудите, — смотрю на структуру кодовой базы и качество кода. Не нужно быть фанатом чистоты, но базовые вещи должны быть на месте: есть ли модульность, разделение ответственности, адекватные размеры файлов. Я открываю несколько случайных модулей и оцениваю: можно ли понять логику за десять минут, или это чёрный ящик, в который заглядывал только один человек? Если второй вариант — это красный флаг, особенно если тот человек не в команде. Код, который написан одним человеком и не имеет документации, — это риск на миллион.
Второй блок — инфраструктура и деплой. Я всегда спрашиваю: как разворачивается приложение в прод? Есть ли CI/CD, или кто-то руками копает по SSH-сессиям? Проверяю, есть ли мониторинг, алерты, бэкапы. Звучит банально, но я видел стартапы, у которых бэкапы не работали полгода, и никто не знал. Инвесторам это не видно в презентации, но если завтра упадёт сервер с базой данных, деньги сгорят быстрее, чем вы успеваете сказать «давайте сделаем раунд».
Третий момент — безопасность. Я не прошу вас делать пентест на каждом этапе, но базовые вещи обязательны: есть ли управление секретами, используются ли устаревшие библиотеки с известными уязвимостями, есть ли аутентификация и авторизация на всех критичных маршрутах. Однажды я нашёл в коде открытый API-ключ к облачному провайдеру, который лежал в открытом репозитории. Это не только безопасность, это прямые деньги, которые утекают через кран. Такие вещи нужно проверять всегда.
Четвёртое — командная скорость и процесс разработки. Я смотрю на гит-историю: как часто коммитят, есть ли code review, как устроены ветки. Если у вас три разработчика и все коммитят в мастер без ревью, то при росте это превратится в ад. Также обращаю внимание на документацию: есть ли внутренние wiki, описание архитектуры, процесс онбординга нового разработчика. Если новый человек не может начать работать за день-два, у вас проблема с масштабируемостью.
Пятое и последнее — соответствие кода бизнес-требованиям. Это то, что часто упускают. Я спрашиваю: что именно делает продукт, какие фичи обещаны клиентам, и потом иду смотреть в код. Бывает, что в презентации заявлены интеграции, которые не реализованы, или что ключевая бизнес-логика завязана на костылях и хардкодах. Технический аудит — это не просто «код красивый или нет», это понимание того, что вы сможете масштабировать продукт без переписывания всего с нуля.
Мой совет всем, кто участвует в инвестиционных процессах: не бойтесь задавать неудобные вопросы команде разработчиков. Они не должны обижаться — хороший CTO или тимлид будет рад, что вы ищете проблемы до того, как они станут критичными. А если команда закрывается, оборачивается и пытается продавить инвестиции на словах «да мы потом всё переделаем» — это повод насторожиться. Технический долг не исчезает сам, он копится и отнимает время, деньги и нервы.
А как вы проводите технический аудит перед инвестициями? Есть ли у вас свои критерии, которые вы считаете обязательными? Буду рад обсудить — делитесь опытом в комментариях, это полезно всем.