Главная > Блог > IT Due Diligence для инвесторов IT Due Diligence для инвесторов: на что смотреть при вложении в стартап Михаил Кадочников · 22 июля 2026 · 19 мин чтения 01 Чему инвестора учат в школе бизнеса, но не учат про IT Iнвесторы привыкли анализировать финансовые показатели: выручку, расходы, маржу, growth rate. Но когда инвестируешь в IT-стартап, финансы рассказывают только половину истории. Другая половина — это технология. Я видел стартапы с фантастической выручкой и маржой, которые при детальном IT-аудите выявляли, что весь продукт построен на хаке, который может сломаться в любой момент. Их выручка выглядит хорошо, потому что они еще не масштабировались. Как только они попытаются удвоить количество пользователей, инфраструктура рухнет. С другой стороны, я видел стартапы с меньшей выручкой, но со здоровой архитектурой и сильной командой, которые смогли вырасти в 10x благодаря стабильной технологии. Именно поэтому профессиональные VC фонды (особенно для Series A и позже) требуют IT DD перед инвестированием. Это не недоверие основателям, это навык управления рисками. Три причины IT DD критична для инвесторов: Это скрытая стоимость — техдолг не видна в P&L, но она там есть, и со временем съедает прибыль Это потолок роста — плохая архитектура означает, что компания не сможет расти быстро без переписи Это стоимость выхода — будущего покупателя (при M&A) также будет волновать состояние технологии, и он снизит оценку В этой статье я создал чеклист для инвесторов — что смотреть при оценке IT-стартапа, какие вопросы задавать основателям и разработчикам, как понять, является ли продукт smoke & mirrors или реальная технология. 02 MVP vs Production-ready: где находится стартап на этом спектре MVP (Minimum Viable Product) MVP — это версия продукта, созданная за несколько недель или месяцев, чтобы проверить гипотезу на рынке. Характеристики: Код писался для скорости, не для масштабируемости Нет большого покрытия тестами (часто 10-30%) Нет полноценного мониторинга и аналитики Инфраструктура развёрнута на одном сервере или в простой облачной конфигурации Архитектура монолитная и простая Документация минимальная Безопасность базовая, не прошла аудит MVP идеален для поиска product-market fit. Но остаться на уровне MVP при масштабировании — это подготовка к проблемам. Scale-up stage Когда MVP нашёл рынок и нужно расти, компания должна перейти на Production-ready. Характеристики: Код частично рефакторен, есть план на дальнейший рефакторинг Покрытие тестами 50-70% Есть CI/CD pipeline, автоматизированное тестирование Инфраструктура горизонтально масштабируема (можно добавлять новые серверы, а не только делать их мощнее) Есть мониторинг, логирование, аналитика ошибок Архитектура разделена на компоненты, есть API documentation Есть обновлённая документация по development и deployment Прошёл базовый аудит безопасности Enterprise-grade Когда компания готовится к выходу в большой бизнес или к IPO, нужен Enterprise-grade: Покрытие тестами 80-90% Архитектура микросервисы или чётко разделённые модули Высокая доступность (99.9%+ uptime SLA) Прошли ISO 27001, SOC 2, GDPR аудиты Есть disaster recovery plan Есть dedicated security team или консультант «Ошибка многих инвесторов — требовать Enterprise-grade от Series A стартапа. MVP может быть хорошим MVP, но он не должен претендовать на то, что готов к масштабированию в 100x.» Как определить, где находится стартап Простой тест: спросите основателя, насколько система может расти в нагрузку. Если ответ «я точно не знаю, нужно протестировать» — это красный флаг. Он должен знать, при какой нагрузке система начинает проседать. Если ответ «мы протестировали, держим 10K RPS», попросите show the data. Второй тест: спросите, сколько времени требуется добавить новую фичу. MVP обычно — 1-2 недели на простую фичу. Scale-up stage — 2-4 недели. Enterprise — 3-5 недель (потому что сложнее, но больше поддержки). Если time to feature растёт без причины, это техдолг. 03 Оценка команды: есть ли один genius или team? Bus factor: что произойдёт, если CEO сбивает автобус? Хороший технический вопрос для инвесторов: если главный архитектор уходит завтра, компания продолжит работать без перебоев? Или всё держится на одном человеке? В многих стартапах есть один гений (обычно CTO), который знает систему изнутри и снаружи. Если это человек в возрасте 25 лет, без семьи, готов жить в офисе — это огромный риск. Однажды он захочет отпуск, захочет семью, захочет заняться другим проектом. Что смотреть в команде Размер команды — есть ли 1-2 человека или 5+ человек в разработке? Маленькая команда — это гибкость на MVP, но риск на scale-up. Опыт — есть ли senior разработчики, которые проводили масштабирования других проектов? Или это только juniors? Знание домена — понимает ли команда business domain (например, если это fintech, есть ли опыт в payments)? Разнообразие навыков — есть ли backend, frontend, devops разработчики или everyone does everything? 턴оувер — как долго люди в команде? Если everyone был нанят последние 3 месяца, это может быть проблема (потеря знаний) или здоровый рост. Локация — в одной локации или распределённая команда? Распределённая команда сложнее при onboarding новых, но лучше для найма talent. Интервью с разработчиками Когда вы проводите DD, попросите интервью с 3-4 разработчиками (не только CTO). Спросите их: «Какой самый большой технический долг в системе?» — если они не могут ответить, это плохо. Если все говорят одно и то же, это хорошо (общее понимание). «Сколько времени заняла бы переписка компонента X?» — они должны иметь чувство масштаба. «Что вам больше всего не нравится в архитектуре?» — честные ответы говорят о здоровой культуре. Если все говорят «всё отлично», это красный флаг (либо они боятся говорить правду, либо они не разбираются). «Как бы вы переписали систему, если бы начали заново?» — это покажет, думали ли они об архитектуре или просто писали код. Red flag в команде: Все разработчики нанялись за последние месяц (потеря знаний старой системы) Средний возраст команды 23 года (недостаток опыта) Нет ни одного человека, который работает в компании более года CTO говорит, что кодовая база идеальна, а разработчики говорят, что она ужас Никто не может объяснить, почему выбрана именно эта архитектура 04 Масштабируемость и стресс-тестирование Обещания масштабируемости часто выглядят хорошо на слайдах. Реальность может быть другой. Что нужно протестировать Максимальная пропускная способность (RPS) — сколько запросов в секунду может обработать система стабильно без потери данных? Точка отказа — в какой нагрузке система начинает давать ошибки, теряет данные или полностью падает? Время отклика — как изменяется response time при растущей нагрузке? Нормально: при 10x нагрузке время отклика растёт на 2-3x. Плохо: при 2x нагрузке время отклика растёт на 10x. Scalability bottlenecks — где система начинает напрягаться? База данных? Caching layer? Сетевое соединение? Как тестировать Используются инструменты вроде Apache JMeter, Gatling, k6. Простой тест нагрузки выглядит так: Запустить нагрузку в 1K RPS, 5K RPS, 10K RPS, 20K RPS Для каждого уровня нагрузки зафиксировать: CPU usage, memory usage, database connection count, response time (p50, p95, p99), error rate Посмотреть, во что превращаются числа Также важно провести долгосрочное нагрузочное тестирование: может быть, система выдерживает пиковые нагрузки 5 минут, но не выдерживает их часами (утечки памяти, растущие очереди). Нужно провести stress test в течение как минимум 2-3 часов с постоянной нагрузкой. Опытные инвесторы также просят провести chaos engineering тесты: выключить один сервер, посмотреть, что происходит. Отключить сетевое соединение, посмотреть, как система реагирует. Эти тесты показывают, насколько система resilient к сбоям. Красные флаги «Мы никогда не тестировали нагрузку, но я уверен, что масштабируемся» — это ненадёжно. «Мы используем microservices, поэтому масштабируемся» — нет, если микросервисы неправильно спроектированы, это может быть хуже, чем монолит. «Мы в облаке, поэтому масштабируемся» — облако даёт возможность масштабироваться, но само по себе это не гарантирует хорошую архитектуру. Отказ показать результаты нагрузочного тестирования — большой красный флаг. Правило: Стартап должен рассчитать, сколько стоит удвоить нагрузку в облаке. Если ответ «мы просто добавим ещё серверы» за ту же цену, это хорошо. Если ответ «расходы вырастут в 3-4 раза», это означает неправильную архитектуру. 05 Интеллектуальная собственность и открытое ПО Кто владеет кодом? Простой, но критичный вопрос: кто владеет исходным кодом? Это должна быть сама компания (или если разработка аутсорсена, должно быть соглашение о передаче прав). Я видел случаи, когда стартап построил весь продукт на аутсорсированной разработке у агентства, но забыл про IP rights. Агентство имеет право на код, и стартап по сути не может ничего с ним делать без разрешения агентства. Open source лицензирование Если система использует open-source компоненты, нужно проверить лицензии. Особенно опасны: GPL / AGPL — вирусные лицензии. Если вы используете GPL код, ваш код тоже становится GPL (в нём нет секретов). Это может быть проблемой для proprietary SaaS. Unmaintained libraries — если используется библиотека, которая не обновлялась 5 лет, это уязвимость. Conflicting licenses — если в проекте используются компоненты с несовместимыми лицензиями, это может быть проблемой. Инструмент для проверки: FOSSA, WhiteSource Bolt, Black Duck. Они сканируют проект и выявляют все проблемы с лицензиями за 5 минут. Конкурентный мост и patents Есть ли у компании что-то запатентованное? Это важно для M&A. Если вся конкурентность построена на open-source кодом, который любой может скопировать, это снижает стоимость компании. Вопрос инвестора: «Что предотвращает конкурента скопировать ваш продукт в течение 3 месяцев?» Если ответ только «наш CTO умён», это риск. Анализ версионности и support окна Важно также посмотреть, как часто компания выпускает обновления и как долго поддерживает старые версии. Если стартап выпускает новую версию раз в год, это может означать отсутствие agility. Если он выпускает обновления несколько раз в день, это может означать отсутствие процессов. Оптимум — несколько релизов в неделю с checklists и тестированием. Checklist по IP: Компания владеет 100% исходным кодом Нет GPL/AGPL зависимостей (или есть согласие на них) Все external developers передали IP права компании Нет конфликтов лицензий Есть документ с перечислением всех используемых open-source зависимостей и их лицензий 06 Анализ конкурентного преимущества: моат или мираж? Что такое technological moat Technological moat — это технологический барьер, который защищает компанию от конкуренции. Примеры: Proprietary algorithm, который конкурентам будет сложно скопировать Большой датасет, который собирался годами Patented technology Масштаб инфраструктуры (например, Netflix имеет CDN по всему миру) Network effects (чем больше пользователей, тем больше ценность для других пользователей) Как инвестор может оценить мост Воспроизводимость — может ли конкурент воспроизвести то же самое за 3-6 месяцев? Если да, это не мост. Масштаб данных — если преимущество в больших данных, нужно проверить, насколько больше их у компании по сравнению с конкурентом. Если 10% больше, это не большой мост. Если 100x больше, это хороший мост. Время на разработку — если оригинальную систему разрабатывали 2 года, а конкурент может сделать похожее за 3 месяца, это не очень сильный мост. Стоимость — есть ли экономия масштаба? Если компания может обслуживать одного клиента за ₽100K в месяц, а конкурент за ₽50K, то у конкурента есть преимущество. Опасные ответы «Наш мост это наша технология» — слишком расплывчато. Какой именно аспект технологии? «Мы первые на рынке» — это не мост. Быть первым означает, что конкурентов можно легко будет копировать. «Наша команда лучше» — может быть правдой, но это не технологический мост, это человеческий капитал. И люди могут уходить. «Мы используем AI/ML» — модно звучит, но в чём конкретно? Если это стандартный нейросеть из TensorFlow, конкурент может сделать то же самое. «Сильный технологический мост должен быть сложным для копирования, даже если конкурент знает, что вы делаете. Это может быть уникальная комбинация компонентов, или доступ к данным, которые конкурент не может получить.» Риск-матрица для инвесторов После всех проверок эксперты часто создают risk матрицу специально для инвесторов. На одной оси — вероятность того, что проблема возникнет в течение 2 лет. На другой оси — финансовое влияние (потеря выручки, дополнительные расходы, пенальти от клиентов). Например, если есть известная уязвимость в платёжной системе, и есть вероятность 30%, что её используют для фрода в течение года, и потенциальная потеря 10M рублей, это risk = вероятность × влияние = 3M рублей. Инвестор должен скидывать это из оценки компании или требовать страховку/escrow для покрытия потенциальных потерь. Хороший IT DD также предоставляет временные рамки для исправления проблем. Некоторые проблемы можно исправить за две недели, другие требуют месяцев. Инвестор должен понимать, насколько быстро компания может стать более стабильной, и планировать инвестицию соответственно. 07 Оценка стоимости масштабирования Вопрос инвестора: если мы инвестируем в вас, сколько стоит удвоить пользователей? Правильный ответ должен включать: стоимость инфраструктуры, стоимость разработки новых фич, стоимость customer support, стоимость маркетинга. Для SaaS это примерно так: если текущая выручка 10M в месяц и CAC (customer acquisition cost) 50K, то маркетинг расходы будут 10M / (50K average LTV) = ? человек в месяц * 50K = примерно 10% от выручки. Инфраструктура расходы могут быть 5-15% от выручки (зависит от того, есть ли economies of scale). Разработка — 20-30% расходов на зарплаты командам разработчиков. Итого: маркетинг (10%) + инфра (10%) + разработка (25%) = 45% от выручки. Margin = 55%. Это здоровый SaaS. Красные флаги в экономике масштабирования Unit economics не улучшаются с масштабом — маржа падает, когда растёшь CAC слишком высокий — 30%+ от LTV Инфраструктура расходы растут быстрее, чем выручка Нужно нанять много людей для масштабирования (каждый новый пользователь требует ручной работы) Вопрос для CTO: «Если выручка вырастет в 10x, сколько инженеров нужно нанять для поддержки?» Ответ должен быть 1-2 человека, не 10. Если нужно 10, это значит, что архитектура не масштабируется. FAQ Часто задаваемые вопросы Нужен ли DD перед seed инвестицией? Не обязательно. На seed стадии (когда инвесторы инвестируют в идею и команду) часто MVP выглядит как MVP, и никто не ожидает production-ready архитектуры. Но для Series A и позже — да, обязательно. Сколько времени занимает IT DD? 2-4 недели активной работы для компании среднего размера. Может быть быстрее для маленьких стартапов (1-2 недели), может быть дольше для сложных систем (6+ недель). Кто проводит IT DD? Обычно это независимые консультанты или audit firms, специализирующиеся на IT. Инвесторы редко имеют в-house экспертизу. Что если DD выявляет проблемы, как на это реагировать? Проблемы — не причина отказывать инвестицию. Это информация для переговоров. Если проблема серьёзная (например, система не может масштабироваться), это влияет на оценку компании и условия инвестиции (например, more equity, трансш инвестиции). Может ли стартап скрыть технические проблемы? Сложно. Хороший audit выявит проблемы через анализ кода, интервью с разработчиками, тестирование нагрузки. Стартап может быть неполностью честным, но если DD профессиональный, выявятся проблемы. Есть ли стандартный чеклист для IT DD инвестора? Нет универсального чеклиста, потому что разные компании требуют разной глубины анализа. Но основные области (архитектура, код, инфраструктура, безопасность, команда, IP, масштабируемость) всегда проверяются. Готов обсудить вашу задачу Отвечу в течение 2 часов. Бесплатная оценка проекта за 24 часа. Написать в Telegram WhatsApp mk@cybergroup.su +7 (963) 275-29-83