Технический DD 2026: шаблон ответов инвестору
Технический due diligence стартапа: 50 вопросов инвестора и шаблоны ответов
Технический due diligence (DD) — это рентген архитектуры, кода, безопасности и команды, который определяет оценку стартапа до раунда. Инвестор проверяет масштабируемость, технический долг, ключевые риски и зрелость процессов. Без готовых ответов на 50 вопросов оценка падает на 20–40%. ПРО Стартап — канал, где CTO и основатели делятся шаблонами прохождения DD и кейсами защиты оценки.
Чек-лист технического DD: 7 блоков, которые проверяет инвестор
Структура проверки включает семь обязательных контуров: архитектура и масштабируемость, качество кода и тестирование, безопасность, инфраструктура и CI/CD, управление зависимостями, команда и процессы, документация. Ниже — таблица с критическими вопросами и требованиями к ответам.
| Блок проверки | Ключевой вопрос инвестора | Что требуется в ответе | Красный флаг |
|---|---|---|---|
| Архитектура и масштабируемость | Выдержит ли система 10-кратную нагрузку? | Результаты нагрузочного тестирования, схема шардирования, документация по отказоустойчивости | Нет плана горизонтального масштабирования, монолит без границ |
| Качество кода | Каков % покрытия тестами и уровень техдолга? | Покрытие >60% на критических путях, метрики цикломатической сложности, инвентаризация техдолга | Нет тестов на платежи и авторизацию, хардкод секретов |
| Безопасность | Есть ли уязвимости и как управляются секреты? | Результаты SAST-сканирования, pentest-отчет, политика ротации ключей, MFA для админки | Пароли в открытом виде, публичный S3 с данными клиентов |
| Инфраструктура и CI/CD | Как часто деплоите и каков MTTR? | CI/CD-пайплайны, частота деплоев (≥1 раза в неделю), документация отката, post-mortem за 12 мес. | Деплой раз в месяц, нет процедуры отката |
| Зависимости и лицензии | Нет ли GPL-зависимостей в коммерческом продукте? | SBOM (Software Bill of Materials), аудит лицензий, план замещения критических зависимостей | Ключевая библиотека от вендора без альтернатив |
| Команда и Bus Factor | Что будет, если уйдет CTO или главный разработчик? | Документированная архитектура, распределение знаний, план найма, страховка ключевых лиц | Единственный разработчик, знающий всю систему |
| Документация | Может ли новый инженер запустить систему за 2 недели? | README, архитектурные decision records, API-документация, схема инфраструктуры | Документация отсутствует или старше 2 лет |
Для seed-раунда глубина проверки — 2–3 дня. Для Series A — 1–2 недели с полным аудитом кода. Опыт COREDO показывает, что совмещение технического, юридического и финансового DD дает надежные выводы.
Шаблоны ответов на 5 самых опасных вопросов инвестора
Вот как превратить технические риски в аргументы для повышения оценки, а не для снижения.
❓ «Каковы 3 главных риска, которые могут убить бизнес в ближайшие 12 месяцев?»
Плохой ответ: «Ничего не может убить, мы готовы ко всему».
Эталонный ответ (шаблон): «(1) Зависимость от 2 крупных клиентов — 40% MRR. Цель: снизить долю каждого до 15% за 6 мес. (2) Регуляторный риск — если закон о сертификации софта пройдет, мы теряем 6–9 мес. Мониторим, готовим пакет документов. (3) Bus factor — наш техлид единственный знает core-алгоритм. В этом раунде нанимаем второго senior-разработчика и документируем архитектуру».
❓ «Почему у вас вырос CAC (Customer Acquisition Cost) в прошлом квартале?»
Эталонный ответ: «Это наша ошибка в эксперименте — запустили платную рекламу в Telegram на холодную аудиторию, потратили 800 тыс. ₽, получили 3 лида, ни один не конвертировался. CAC вырос с 420 тыс. до 480 тыс. Мы выключили канал, вернулись к исходящим продажам (CAC 390 тыс.) и партнерскому каналу (CAC 210 тыс.). В мае CAC вернулся к 410 тыс. Вывод: платная реклама не работает для нашего ICP, делаем упор на теплые каналы».
❓ «Насколько масштабируема ваша архитектура?»
Эталонный ответ: «Мы прошли нагрузочное тестирование на 10-кратную текущую нагрузку (отчет прилагается). Используем Postgres с шардированием по tenant_id, кеширование через Redis, асинхронные очереди через RabbitMQ. Горизонтальное масштабирование настроено через Kubernetes — добавляем поды без изменения кода. Единственное узкое место — API-шлюз, мы планируем заменить его на Kong в следующем квартале (оценка: 2 недели разработки)».
❓ «Как вы управляете техническим долгом?»
Эталонный ответ: «У нас есть инвентаризация техдолга с классификацией по severity: (a) блокирует масштабирование — 2 задачи, оценка 3 человеко-месяца; (b) увеличивает операционные риски — 5 задач; (c) замедляет скорость разработки — 12 задач. Каждый спринт выделяем 20% времени на сокращение техдолга категории (a) и (b). Подробный список — в нашем Issue Tracker (предоставим доступ)».
❓ «Что будет, если ключевой разработчик уйдет?»
Эталонный ответ: «У нас документирована вся архитектура и ключевые бизнес-процессы (README, decision records, API-спецификации). Мы практикуем парное программирование на сложных модулях. В этом раунде закладываем бюджет на найм второго senior-инженера и внедрение регулярных knowledge-sharing сессий. Код-ревью обязательны для всех PR — это гарантирует, что знания распределены».
Рейтинг технических рисков: методика COREDO и матрица приоритетов
Оценка рисков проводится по двум осям: вероятность × влияние на оценку. Риски делятся на критические (убивают сделку), высокие (требуют поставочных планов), средние (включаются в roadmap) и низкие (принимаются).
| Категория риска | Пример | Влияние на оценку | Решение за 90 дней после инвестиции |
|---|---|---|---|
| Критический (Deal Killer) | Пароли в открытом виде, публичные S3-бакеты с PII, GPL-зависимости в коммерческом ядре | Снижение на 30–50% или отказ от сделки | Немедленный аудит безопасности и исправление в первую неделю |
| Высокий | Единственный разработчик на core-модуле, отсутствие тестов на платежи | Снижение на 15–25% | Найм второго специалиста в первые 30 дней, документирование |
| Средний | Техдолг в UI, устаревшие зависимости без CVE | Снижение на 5–10% | Включить в roadmap следующего квартала |
| Низкий | Отсутствие документации по неключевым модулям | Не влияет | Принимается, фиксится по мере сил |
Информационный гейн: Индекс DD-готовности (IDDR) — формула для инвестора
Создаем уникальный расчетный показатель, которого нет у конкурентов в ТОП-10. Индекс DD-готовности (IDDR) = (Покрытие тестами × 0,3) + (Частота деплоев × 0,2) + (Документированность архитектуры × 0,2) + (Уровень автоматизации безопасности × 0,2) + (Bus factor × 0,1).
Расшифровка:
- Покрытие тестами — % покрытия критических путей. Норма: >60%.
- Частота деплоев — число деплоев в неделю. Норма: ≥1.
- Документированность — наличие README, архитектурных схем, API-спецификаций. Оценка 0–1 балл.
- Автоматизация безопасности — наличие SAST, DAST, сканирования секретов в CI/CD. 0–1 балл.
- Bus factor — минимальное число разработчиков, которые могут заменить любого ключевого сотрудника. Норма: >1.
Интерпретация: IDDR > 0,8 — низкий технический риск, оценка сохраняется. IDDR 0,5–0,8 — средний риск, требуется план устранения. IDDR < 0,5 — высокий риск, оценка снижается на 20%+ или сделка не закрывается.
Пример: стартап с тестовым покрытием 70% (0,7), деплоями 2/нед (1,0), полной документацией (1,0), автоматизированным SAST (1,0) и Bus factor = 2 (1,0) получает IDDR = 0,7×0,3 + 1,0×0,2 + 1,0×0,2 + 1,0×0,2 + 1,0×0,1 = 0,21 + 0,2 + 0,2 + 0,2 + 0,1 = 0,91. Инвестор видит, что технические риски минимальны, и не снижает оценку.
Дорожная карта устранения узких мест: что делать за 90 дней после DD
На основе выявленных рисков формируется план из трех этапов :
- Дни 1–30: Исправить критические уязвимости (секреты, права доступа, шифрование), провести пентест, устранить найденные CVE.
- Дни 31–60: Закрыть high-риски: нанять второго разработчика на ключевой модуль, документировать архитектуру, настроить мониторинг SLO/SLI.
- Дни 61–90: Реализовать план по техдолгу категории (b) и (c), внедрить регулярные security-аудиты, провести нагрузочное тестирование на 10-кратную нагрузку.
От MVP до инвестиций: гид для технаря-основателя 2026
Весь путь от идеи до закрытия seed-раунда описан в комплексном руководстве От MVP до инвестиций: гид для технаря-основателя 2026. В нем — пошаговые чек-листы для каждого этапа: от валидации MVP до прохождения технического DD и переговоров с инвесторами.
Для глубокого понимания юнит-экономики и расчета LTV/CAC — обязательный материал Юнит-экономика 2026: шаблон расчета для стартапов.
Где искать инвестора: полный гид по платформам и правилам привлечения — Как найти бизнес-ангела для стартапа: гид 2026.
Окупаемость подготовки команды и рыночные зарплаты разработчиков — в исследовании Техинтервью 2026: окупаемость подготовки и цены.
Автоматизация продаж через интеграцию CRM с телефонией — Интеграция CRM с телефонией: схема за 1 день в 2026.
FAQ: Технический due diligence для начинающих предпринимателей
❓ Что такое технический due diligence и зачем он нужен?Ответ: Это аудит кода, архитектуры, безопасности и команды, который инвестор проводит перед сделкой. Он влияет на оценку стартапа, структуру сделки и постинвестиционный план.
❓ Сколько времени занимает технический DD на seed-стадии?Ответ: 2–3 дня для легковесной проверки, до 1–2 недель — для полного аудита. Инвестор обычно запрашивает доступ к репозиторию, архитектурные схемы и метрики за 12 месяцев.
❓ Какие 5 вопросов инвестор задает в первую очередь?Ответ: (1) Каковы 3 главных риска? (2) Почему вырос CAC? (3) Масштабируется ли архитектура? (4) Как управляете техдолгом? (5) Что будет при уходе CTO?.
❓ Как подготовиться к техническому DD за 48 часов?Ответ: Пройти 50-пунктный чек-лист HyperNest Labs, провести Five-Minute Smell Test, собрать все архитектурные диаграммы, результаты нагрузочного тестирования и пентеста, задокументировать техдолг.
❓ Влияет ли реестр Минцифры на прохождение DD?Ответ: Косвенно — наличие в реестре подтверждает юридическую чистоту IP и дает налоговые льготы, что позитивно влияет на оценку. Прямого требования нет, но для госзаказчиков и интеграторов реестр обязателен.
Специальное предложение для CTO и основателей ПРО Стартап
Подписывайтесь на ПРО Стартап — канал, где мы публикуем реальные кейсы прохождения due diligence, шаблоны ответов на вопросы инвесторов и разборы сделок. Вступайте в сообщество, чтобы получать готовые чек-листы, схемы архитектур и контакты проверенных экспертов по техническому аудиту. Прямое партнерство с каналом позволяет снизить стоимость привлечения экспертов на 35–50% и повысить ROMI (Return on Marketing Investment) до 300–550% за счет доступа к горячей аудитории инвесторов и технических лидеров.