Технологический Due Diligence: чек-лист из 30 пунктов

Инвестор смотрит на стартап, видит хороший бизнес-модель, растущую выручку и амбициозных основателей. Но вот вопрос техдиректору: "Что с кодом?" Ответ неуверенный. На встречу приглашают подрядчика, кода смотрел год назад, ничего не помнит.

Это опасная ситуация. Техдолг, который не виден сейчас, убивает стартапы за 12–24 месяца. Я видел компании, которые получили инвестиции и через год обвалились, потому что код был написан на костылях, архитектура хрупкая, а найм новых разработчиков добавил только проблем.

Due diligence — это проверка технического состояния компании перед инвестицией или покупкой. В этой статье даю чек-лист из 30 вопросов, которые вам нужно задать (или проверить сами) перед инвестицией в IT компанию.

---

☐ Архитектура системы понятна и документирована

Попросите диаграмму: сервисы, базы данных, очереди, кэши. Если это просто "слово-салат", это red flag. Хорошая архитектура описывается на 1-2 страницах.

☐ Нет Single Point of Failure

Проверьте: если упадёт один сервер, один database, одна очередь — приложение продолжит работать? Или при любой проблеме всё падает? В production это критично.

☐ Масштабируемость: может ли система выдержать 10x нагрузку?

Если сейчас 100K пользователей, готова ли система к 1M без полного переписания? Есть ли кэширование, database sharding, load balancing? Или это пуля в лоб на текущую нагрузку?

☐ Выявлены tech debt элементы

Спросите team lead'а: "На что нужно потратить неделю-две, чтобы улучшить качество кода?" Если он может ответить на это — хороший знак. Если пожимает плечами — code smell.

☐ База данных выбрана осознанно

PostgreSQL? MySQL? MongoDB? Почему именно эта база, а не другая? Есть ли plan как мигрировать данные при смене БД? Или это навсегда?

☐ Обработка отказов (resilience)

Что происходит, если payment gateway упал на 1 час? Если API партнёра медленный? Есть ли timeout'ы, retry логика, graceful degradation?

---

☐ Code coverage выше 60%

Автоматические тесты покрывают логику. Меньше 60% — это очень мало. 80%+ — хорошо. 100% редко, но возможно.

☐ Code review процесс работает

Посмотрите на pull request'ы: есть ли comments? Approvals перед merge? Или люди просто мержат в main? Если второе — это рассадник ошибок.

☐ Линтеры и форматеры настроены

ESLint, Prettier, Black, mypy — это не баловство, это стандарт. Если код пишут без них, он выглядит как свалка.

☐ Нет dead code

Посмотрите на repo: есть ли папки с названиями "old", "backup", "deprecated"? Если есть — это признак, что кодовую базу никто не чистит. Dead code — это долг на будущее.

☐ Есть lint результаты и метрики

SonarQube, CodeClimate или аналог? Количество ошибок, code smells, уязвимостей отслеживается? Или это просто "кажется, что код хороший"?

☐ Читаемость и документирование

Можете ли вы открыть случайный файл и за 5 минут понять, что он делает? Или это криптическое безумие с переменными `a`, `b`, `tmp`?

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

---

☐ OWASP Top 10 известна и учитывается

SQL injection, Cross-site scripting, Broken authentication, Sensitive data exposure — это базовые классы атак. Есть ли защита от них?

☐ Есть пентест или аудит безопасности

Профессиональная компания провела проверку безопасности? Результаты есть? Уязвимости исправлены? Или никто никогда не проверял?

☐ Секреты в переменных окружения, не в коде

API ключи, пароли БД, приватные ключи — это не должно быть в repo. Это должно быть в .env или хранилище секретов (AWS Secrets Manager, HashiCorp Vault).

☐ Логирование и мониторинг работает

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

☐ Данные пользователей шифруются

Пароли — bcrypt или аналог? PII данные в базе — в открытом виде или зашифрованы? Data in transit — HTTPS везде?

☐ Есть процесс управления доступом

Новый разработчик может получить доступ ко всему коду и всем серверам? Или есть role-based access control? Когда человек уходит, немедленно отключают доступ?

☐ Соответствие compliance требованиям

Если это компания в России и собирает данные граждан — ФЕДЗ? Обработка персональных данных? Если в EU — GDPR? Если данные платежных карт — PCI DSS? Что из этого выполняется?

---

☐ Bus factor выше 1

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

☐ Есть CI/CD pipeline

Github Actions, GitLab CI, Jenkins? Каждый commit автоматически проходит тесты? Деплой автоматический или ручной? Если ручной — это bottleneck.

☐ Документация существует

README в repo? API документация? Architecture docs? Процесс onboarding новых разработчиков описан? Или всё только в головах людей?

☐ Спринты и планирование

Есть ли структурированная работа? Спринты? Оценка задач? Или это как в фильме: "Давай напишем быстро, не морочься"?

☐ Разработчики имеют опыт с данным стеком

Если используется Python 3.9, есть ли люди с опытом Python? Если React, есть ли опытные React разработчики? Или это "мы все можем всё"?

---

☐ Infrastructure as Code

Серверы описаны в коде (Terraform, CloudFormation)? Или это ручное создание через AWS консоль? IaC означает, что можно пересоздать всю инфру за минуты.

☐ Мониторинг и алерты

Prometheus, Grafana, DataDog? Есть ли метрики? Есть ли алерты если CPU выше 80% или database медленнее чем обычно? Или никто не мониторит?

☐ Disaster recovery plan

Если server упадёт, как быстро поднять новый? Есть ли backup'ы? Резервные копии в другом регионе? Как часто тестируют восстановление? Или это "надеемся, что не упадёт"?

☐ Стоимость инфраструктуры разумная

Сколько компания платит за AWS/GCP/Yandex.Cloud? Это пропорционально нагрузке? Или это "мы платим $50K в месяц за облако, но нагрузка низкая"? Неоптимизированная инфра может съесть весь профит.

---

☐ Open source лицензии соответствуют бизнесу

Если вы используете GPL код, а продаёте приложение — это может быть проблема. MIT, Apache, BSD — обычно OK. Есть ли выполнен audit всех зависимостей?

☐ IP прав ясны

Кто владелец кода? Компания или founder'ы? Есть ли неоплачиваемых подрядчиков, которые могут потом заявить о своих правах? Всё ли legally clean?

---

Фаза 1: Подготовка (1 день)

• Получить доступ к repo, документации, системам
• Назначить встречу с CTO/lead разработчиком
• Скачать метрики (код качества, тесты, время деплоя)

Фаза 2: Анализ кода (2–3 дня)

• Прогулять по структуре проекта, понять архитектуру
• Посмотреть на recent commits, есть ли активная разработка?
• Проверить test coverage, качество тестов
• Попытаться поднять проект локально, есть ли оно работает?

Фаза 3: Интервью (1 день)

• Встреча с team lead'ом и несколькими разработчиками
• Задать вопросы из чек-листа
• Попросить объяснить архитектуру, problematic areas
• Спросить про планы на год: какой tech debt выправляют?

Фаза 4: Инфраструктура и безопасность (1–2 дня)

• Встреча с DevOps/infrastructure engineer'ом
• Посмотреть на инфру, стоимость, мониторинг
• Спросить про безопасность, есть ли пентесты, как обработаны findings

Фаза 5: Отчёт (1 день)

• Собрать findings, оценить риски
• Выделить "green flags" (хорошие практики)
• Выделить "red flags" (опасные моменты)
• Дать рекомендации на инвестиции

---

Критические red flags (стоп, не инвестировать):

• Нет версионирования кода (Git) или очень молодой repo (меньше года истории)
• Bus factor = 1 (только один человек понимает систему)
• Пентест не проводился, но есть PII/финансовые данные
• Code coverage ниже 20%
• Инфра полностью на one person's laptop
• Есть приватные ключи в коде

Серьёзные red flags (нужна работа перед инвестицией):

• Tech debt явно выявлен, но нет плана как его решать
• Нет CI/CD, деплой ручной
• Тесты отсутствуют или coverage ниже 40%
• Мониторинг не настроен
• Без документации

Green flags (хорошо, инвестируем):

• Code coverage выше 70%
• Есть архитектурная документация
• CI/CD pipeline работает
• Разработчики могут объяснить решения
• Пентест был, findings исправлены
• Процесс code review работает
• Bus factor выше 2
• Инфра описана как IaC

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

---

Due diligence — это не одна встреча, это систематическая проверка. 30 вопросов в этом чек-листе покрывают 90% рисков. Если по всем пунктам — хорошие ответы, инвестиция имеет смысл.

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

Используйте этот чек-лист перед любой инвестицией в IT компанию. Это потратит время (30-40 часов), но спасит вам миллионы в долгосроке.