Technical Due Diligence: как проверить код перед покупкой стартапа

"Мы купили стартап за $2M. Через месяц узнали, что код надо переписывать с нуля."

Инвестор показал мне "приобретение": 3 года разработки, 150K строк кода, "работающий продукт" с 5K пользователей. Выглядело отлично на демо.

Через 2 недели технического аудита картина изменилась:

• Архитектура: монолит на 12-летнем фреймворке, который больше не поддерживается
• Безопасность: пароли в открытом виде в базе, SQL-инъекции в 15 местах
• Масштабируемость: база данных падает при 100 одновременных пользователях
• Команда: 80% кода написал один разработчик, который уже уволился

Реальная стоимость покупки: $2M сделка + $1.5M на переписывание = $3.5M вместо заявленных $2M.

За 15 лет я провёл технический аудит десятков проектов перед покупкой или инвестициями. В этой статье — чек-лист того, как не попасть в ловушку "красивого демо" и понять реальное состояние технологической части стартапа.

TL;DR: Главное для руководителей

Для инвесторов и покупателей:

• Technical due diligence стоит 0.5-1% от сделки, но экономит в среднем 30-50% от переплаты
• 5 критичных проверок: Security, Bus Factor, Test Coverage, Dependencies, Infrastructure
• Технический долг > 30% = переоценка сделки минимум на 20-40% вниз
• Если Bus Factor = 1 и разработчик уже ушёл — это deal breaker

Для основателей (продавцов):

• Начинайте подготовку за 6 месяцев до сделки
• Приоритет: исправить критичные проблемы с безопасностью, покрыть тестами ключевой функционал
• Подготовьте "Data Room": архитектурные схемы, ADR, метрики производительности
• Хороший код может добавить 10-20% к цене сделки

Длительность аудита: 2-4 недели для сделок $1M-5M

Стоимость пропуска аудита: В среднем +44% к изначальной цене из-за скрытых долгов

Что такое Technical Due Diligence и зачем он нужен

Technical Due Diligence — это технический аудит компании перед инвестицией или покупкой. Цель — понять:

1. Сколько на самом деле стоит продукт? (учитывая скрытые долги)
2. Какие риски вы покупаете? (безопасность, масштабируемость, команда)
3. Сможете ли вы развивать продукт? (или придётся переписывать)

Когда проводить technical due diligence

• Покупка стартапа или технологической компании
• Инвестиции в tech-проект (Series A и выше)
• Перед стратегическим партнёрством
• M&A сделки с технологическим компонентом

Сколько стоит НЕ делать technical due diligence

Реальный пример:

E-commerce платформа куплена за $5M. Technical due diligence не проводился ("зачем, если работает?").

Что обнаружили через 3 месяца:

• База данных не масштабируется (нужна миграция на другую архитектуру)
• Payment gateway написан с хардкодом API ключей
• Нет автоматизированного тестирования (регрессия при каждом релизе)
• Deployment занимает 6 часов (manual process)

Итоговые затраты:

Цена покупки:              $5.0M
Миграция БД:               $0.8M
Рефакторинг платежей:      $0.5M
Внедрение CI/CD:           $0.3M
Покрытие тестами:          $0.6M
──────────────────────────────
Итого:                     $7.2M

Переплата: 44% от изначальной сделки

Стоимость technical due diligence: $20K-50K. Экономия: $2.2M.

Что проверять: полный чек-лист

1. Архитектура и код

Качество кодовой базы

Метрики для проверки:

• Cyclomatic Complexity — сложность кода (норма: <10 на функцию)
• Code Coverage — покрытие тестами (минимум: 60%, хорошо: 80%+)
• Code Duplication — дублирование кода (норма: <5%)
• Technical Debt Ratio — отношение долга к коду (критично: >20%)

Как проверить:

# Python: Cyclomatic Complexity
pip install radon
radon cc -a src/ --total-average
 
# Test Coverage
pytest --cov=src --cov-report=term
 
# Code Duplication
npm install -g jscpd
jscpd src/

Red flags:

• ❌ Cyclomatic Complexity > 20 в критичных модулях
• ❌ Test Coverage < 30%
• ❌ Code Duplication > 15%
• ❌ Technical Debt Ratio > 25%

Архитектурные паттерны

Что смотрим:

• Соответствие архитектуры бизнес-задачам (не over-engineered?)
• Монолит vs микросервисы (оправдан ли выбор?)
• Разделение ответственности (SOLID принципы)
• Зависимости между модулями

Вопросы для команды:

1. Почему выбрана текущая архитектура?
2. Как она менялась за время разработки?
3. Какие узкие места вы знаете?
4. Что бы вы изменили, если бы начинали сейчас?

Red flags:

• ❌ Невозможность объяснить архитектурные решения
• ❌ "Так исторически сложилось" как единственное объяснение
• ❌ Монолит на 500K+ строк без планов на декомпозицию
• ❌ Микросервисы при команде из 3 разработчиков
• ❌ Циклические зависимости между модулями

2. Технологический стек

Актуальность технологий

Проверка:

• Версии фреймворков и библиотек
• Наличие активной поддержки (LTS, EOL даты)
• Размер и активность сообщества
• Обновления безопасности

Как проверить:

# Python: outdated packages
pip list --outdated
 
# Node.js: outdated packages
npm outdated
 
# Проверка CVE (уязвимости)
npm audit

Критичные вопросы:

• Когда последний раз обновлялись зависимости?
• Есть ли deprecated библиотеки?
• Планируется ли миграция на новые версии?

Red flags:

• ❌ Фреймворк/язык с истекшей поддержкой (например, Python 2.7)
• ❌ Критичные security уязвимости (CVSS > 7.0)
• ❌ Зависимости не обновлялись больше года
• ❌ Использование deprecated API

Vendor lock-in риски

Что проверяем:

• Зависимость от конкретного облачного провайдера
• Проприетарные решения vs open source
• Сложность миграции на другие платформы

Примеры vendor lock-in:

🚨 Критичный lock-in:
- AWS-специфичные сервисы (Lambda, DynamoDB) без абстракций
- Firebase для всей бизнес-логики
- Proprietary CMS без экспорта данных

✅ Приемлемый lock-in:
- Стандартные managed сервисы (PostgreSQL, Redis)
- Kubernetes (переносим между облаками)
- Open source решения

3. Безопасность

Критичные проверки:

Authentication & Authorization

Вопросы:

• Как хранятся пароли? (bcrypt/argon2 или plain text?)
• Как управляются сессии?
• Реализована ли MFA?
• Как работает восстановление пароля?

Red flags:

• ❌ Пароли в plain text или MD5
• ❌ Session tokens без истечения срока
• ❌ Отсутствие rate limiting на login
• ❌ Secret keys в git репозитории

Data Protection

Проверка:

• Encryption at rest (для чувствительных данных)
• Encryption in transit (HTTPS везде?)
• Backup стратегия и тестирование восстановления
• GDPR/compliance требования

Инструменты:

# Поиск секретов в git history
git log --all --full-history --source -S "password="
git log --all --full-history --source -S "api_key="
 
# Или используйте gitleaks
docker run --rm -v $(pwd):/path zricethezav/gitleaks:latest detect --source="/path"

SQL Injection & XSS

Как проверить:

• Code review критичных endpoints
• Использование ORM vs raw SQL queries
• Input validation и sanitization
• Output encoding

Примеры уязвимого vs безопасного кода:

# ❌ КРИТИЧНО: SQL Injection уязвимость
def get_user(username):
    query = f"SELECT * FROM users WHERE username = '{username}'"
    return db.execute(query)
 
# ✅ БЕЗОПАСНО: Параметризованные запросы
def get_user(username):
    query = "SELECT * FROM users WHERE username = %s"
    return db.execute(query, (username,))

// ❌ КРИТИЧНО: XSS уязвимость
function displayMessage(msg) {
  document.getElementById("output").innerHTML = msg; // Любой HTML выполнится!
}
 
// ✅ БЕЗОПАСНО: Экранирование контента
function displayMessage(msg) {
  document.getElementById("output").textContent = msg; // Только текст
}

# ❌ КРИТИЧНО: Command Injection
def backup_database(db_name):
    os.system(f"pg_dump {db_name} > backup.sql")  # Опасно!
 
# ✅ БЕЗОПАСНО: Используйте subprocess с аргументами
def backup_database(db_name):
    subprocess.run(['pg_dump', db_name], stdout=open('backup.sql', 'w'))

Red flags:

• ❌ String concatenation/interpolation в SQL запросах
• ❌ Отсутствие input validation на user input
• ❌ Пользовательский ввод в eval(), exec(), os.system()
• ❌ innerHTML для отображения пользовательских данных
• ❌ Нет CSP (Content Security Policy) headers

4. Инфраструктура и DevOps

CI/CD Pipeline

Что должно быть:

• Автоматизированное тестирование
• Автоматический deployment
• Code review процесс
• Rollback механизм

Вопросы:

• Сколько времени занимает deployment?
• Как часто делаете релизы?
• Что происходит при падении production?
• Есть ли staging/QA окружения?

Red flags:

• ❌ Manual deployment (копирование файлов по FTP)
• ❌ Нет staging окружения
• ❌ Deploy в production без code review
• ❌ Релизы реже 1 раза в месяц

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

Критичные метрики:

• Application Performance Monitoring (APM)
• Error tracking
• Uptime monitoring
• Resource utilization (CPU, Memory, Disk)

Инструменты должны быть:

Обязательный минимум:
✅ Логирование (ELK, CloudWatch, или аналог)
✅ Error tracking (Sentry, Rollbar)
✅ Uptime monitoring (UptimeRobot, Pingdom)
✅ Application metrics (Prometheus, Grafana)

Red flags:

• ❌ Нет централизованного логирования
• ❌ Узнаём о проблемах от пользователей
• ❌ Нет исторических данных о производительности
• ❌ Не знают про last incident

Масштабируемость

Проверка:

• Может ли система масштабироваться горизонтально?
• Есть ли bottlenecks в архитектуре?
• Как ведёт себя под нагрузкой?

Вопросы:

• Какая текущая нагрузка (RPS, concurrent users)?
• Какой максимум выдерживали?
• Проводилось ли нагрузочное тестирование?
• Где будет узкое место при росте в 10x?

Red flags:

• ❌ Single point of failure (SPOF)
• ❌ Не проводилось load testing
• ❌ База данных на одном сервере без репликации
• ❌ Stateful архитектура без возможности горизонтального масштабирования

5. Документация

Что должно быть:

• README — как запустить проект локально
• Architecture documentation — как устроена система
• API documentation — актуальная документация API
• Deployment guide — как деплоить
• Runbooks — что делать при инцидентах

Red flags:

• ❌ Нет документации вообще
• ❌ "Документация устарела, смотрите код"
• ❌ Никто не может объяснить, как работает критичный компонент
• ❌ Onboarding нового разработчика занимает больше месяца

6. Команда и процессы

Bus Factor

Bus Factor — количество людей, которые должны "попасть под автобус", чтобы проект встал.

Как проверить:

# Git: кто автор кода?
git ls-files | xargs -n1 git blame --line-porcelain | \
  grep "^author " | sort | uniq -c | sort -rg | head -5

Интерпретация:

12456 John Doe       # ← 60% кода — Bus Factor = 1 (критично!)
 3421 Alice Smith    # ← 17% кода
 1987 Bob Johnson    # ← 10% кода

Red flags:

• ❌ Bus Factor = 1 (один человек знает весь код)
• ❌ Ключевые разработчики уже уволились
• ❌ Отсутствие code review культуры
• ❌ Нет парного программирования или knowledge sharing

Процессы разработки

Вопросы команде:

• Как выглядит ваш sprint/цикл разработки?
• Как принимаете технические решения?
• Есть ли code review?
• Как управляете техническим долгом?

Red flags:

• ❌ "Code review — трата времени"
• ❌ Отсутствие процесса принятия архитектурных решений
• ❌ Никто не знает про технический долг
• ❌ "Мы всегда делаем так, как сказал основатель"

Red Flags: критические признаки проблем

Уровень 1: Немедленное НЕТ сделке

Эти проблемы делают покупку нецелесообразной без серьёзного пересмотра условий:

• ❌ Критичные security уязвимости — SQL injection, XSS, пароли в plain text
• ❌ Нет прав на код — лицензионные проблемы, использование пиратского софта
• ❌ Непоправимый vendor lock-in — невозможность миграции без полной переписывания
• ❌ Вся команда уволилась и Bus Factor был = 1-2

Уровень 2: Требуется глубокий рефакторинг

Можно купить, но надо закладывать 6-12 месяцев и значительный бюджет на исправление:

• ⚠️ Technical Debt Ratio > 30% — критичный уровень долга
• ⚠️ Test Coverage < 20% — практически нет тестов
• ⚠️ Monolith на 500K+ строк без модульной структуры
• ⚠️ Нет CI/CD — manual deployment
• ⚠️ Deprecated технологии с EOL в ближайшие 12 месяцев

Уровень 3: Контролируемые риски

Можно исправить в процессе развития (3-6 месяцев):

• ℹ️ Debt Ratio 15-20% — средний долг
• ℹ️ Test Coverage 40-60% — есть базовое покрытие
• ℹ️ Устаревшие зависимости (но с путём миграции)
• ℹ️ Слабая документация — можно восстановить
• ℹ️ Bus Factor = 2-3 — зависимость от нескольких людей

Как оценить технический долг в деньгах

Формула оценки долга

Cost of Technical Debt =
  (Remediation Cost) + (Opportunity Cost) + (Risk Cost)

где:
  Remediation Cost = Время на исправление × Стоимость команды
  Opportunity Cost = Упущенная выгода из-за медленной разработки
  Risk Cost = Вероятность инцидента × Стоимость downtime

Пример расчёта

Ситуация:

• Monolith на 300K строк
• Test Coverage: 25%
• Technical Debt Ratio: 28%
• Deployment: manual, 4 часа
• Команда: 5 разработчиков × $80K/год

Remediation Cost (исправление долга):

Рефакторинг критичных модулей:     3 месяца × $33K = $100K
Покрытие тестами до 70%:           2 месяца × $33K = $66K
Внедрение CI/CD:                   1 месяц × $33K =  $33K
Документация:                      2 недели × $16K = $16K
──────────────────────────────────────────────────────
Итого Remediation:                                $215K

Opportunity Cost (упущенная выгода):

Текущая скорость: 1 фича в месяц
При рефакторинге: 2-3 фичи в месяц

Упущенная выгода:
  6 месяцев × 2 фичи × $50K потенциальной выручки = $600K

Risk Cost (риски):

Вероятность critical incident: 40% в год
Стоимость 1 часа downtime: $5K
Среднее время восстановления: 4 часа

Risk Cost = 0.4 × ($5K × 4 часа) = $8K/год

Итого Cost of Technical Debt:

Remediation: $215K
Opportunity:  $600K (за период рефакторинга)
Risk:         $8K/год

Реальная стоимость покупки:
  Цена сделки + Remediation + Opportunity
  $2M + $215K + $600K = $2.815M

Переоценка: +40% от заявленной цены

Процесс проведения Technical Due Diligence

Этап 1: Подготовка (1-2 дня)

Запрос информации:

1. Доступ к Git repository
2. Документация (Architecture, API, Deployment)
3. Инфраструктурные схемы
4. Список технологий и зависимостей
5. Метрики производительности (если есть)
6. Incident history и постмортемы за последний год

Этап 2: Автоматический анализ (2-3 дня)

Запуск инструментов:

# 1. Метрики кода
radon cc -a src/ --total-average
radon mi src/
 
# 2. Test coverage
pytest --cov=src --cov-report=html
 
# 3. Code duplication
jscpd src/
 
# 4. Security scan
npm audit
git log --all | grep -i "password\|secret\|key"
 
# 5. Dependencies audit
npm outdated
pip list --outdated

Таблица инструментов для автоматизации аудита

Рекомендуемый минимальный стек для due diligence:

• Code Quality: SonarQube Community Edition (бесплатно)
• Security: Gitleaks + Semgrep + npm audit
• Dependencies: Snyk Open Source (бесплатно для OSS)
• Coverage: Codecov или встроенные инструменты языка

Стоимость инструментов:

• Базовый стек (open source): $0
• Полный commercial стек: ~$500-2000/месяц
• ROI: Один найденный критичный баг окупает годовую подписку

Этап 3: Code Review (3-5 дней)

Приоритеты проверки:

1. Критичные модули — authentication, payments, data access
2. Архитектура — design patterns, dependencies
3. Security — input validation, data encryption
4. Performance — database queries, caching

Этап 4: Интервью с командой (1-2 дня)

Вопросы разработчикам:

• Какие архитектурные решения вызывают у вас боль?
• Где самый большой технический долг?
• Что бы вы изменили, если бы начинали сейчас?
• Какие были самые серьёзные инциденты?

Вопросы DevOps:

• Как часто падает production?
• Сколько времени занимает восстановление?
• Какие узкие места в infrastructure?

Этап 5: Отчёт и рекомендации (2-3 дня)

Структура отчёта:

# Technical Due Diligence Report
 
## Executive Summary
 
- Общая оценка (Go/No-Go/Go with conditions)
- Ключевые риски
- Финансовая оценка долга
 
## Code Quality
 
- Metrics (Complexity, Coverage, Duplication)
- Architecture review
- Critical issues
 
## Security
 
- Vulnerabilities found
- Compliance gaps
- Remediation plan
 
## Infrastructure
 
- Scalability assessment
- DevOps maturity
- Cost optimization opportunities
 
## Team & Process
 
- Bus Factor
- Development practices
- Knowledge transfer risks
 
## Financial Impact
 
- Remediation cost
- Opportunity cost
- Risk cost
- Adjusted valuation
 
## Recommendations
 
- Immediate fixes (before closing)
- Short-term improvements (0-6 months)
- Long-term roadmap (6-12 months)

Частые ошибки при проведении Technical Due Diligence

Ошибка 1: Фокус на синтаксисе, а не на архитектуре

Проблема:

Аудитор тратит время на code style violations и naming conventions, упуская критичные архитектурные проблемы.

Пример:

# Аудитор зациклился на этом:
def getUserData(userId):  # ❌ "Не camelCase!"
    return db.get(userId)
 
# Пропустил реальную проблему:
def process_payment(amount):
    # Hardcode, нет retry logic, нет error handling
    requests.post("https://api.stripe.com", json={"amount": amount})

Решение:

Приоритизируйте проверки:

1. Security (критично)
2. Architecture & Scalability (важно)
3. Code quality metrics (средне)
4. Code style (низко)

Ошибка 2: Не проверить операционную готовность (Operational Readiness)

Что упускают:

• Есть ли runbooks для типичных инцидентов?
• Как команда реагирует на production incidents?
• Сколько времени занимает rollback?
• Есть ли disaster recovery план (и проверялся ли он)?

Проверка:

Спросите команду: "Покажите мне, что вы делаете, когда база данных упала в 3 часа ночи?"

Если ответ: "Э-э-э... звоним DevOps-у?" — это red flag.

Что должно быть:

• Документированные runbooks
• On-call rotation
• Post-mortem культура (записи об инцидентах)
• Tested backup recovery

Ошибка 3: Не поговорить с рядовыми разработчиками

Проблема:

Общение только с CTO/Tech Lead. Они знают о проблемах, но могут их преуменьшать.

Решение:

Попросите провести анонимный опрос разработчиков:

Вопросы:

1. Какая часть кода вызывает у вас наибольшую боль?
2. Что вы боитесь трогать при разработке?
3. Если бы вы начинали проект с нуля, что бы изменили?
4. Какие технические проблемы блокируют развитие продукта?

Рядовые разработчики часто знают о "скелетах в шкафу" больше, чем менеджмент.

Ошибка 4: Игнорировать качество тестов

Проблема:

Смотрят только на % покрытия, не оценивая качество тестов.

Пример плохих тестов с высоким coverage:

# Test Coverage: 90%, но тесты бесполезные
def test_calculate_discount():
    result = calculate_discount(user=mock_user, total=1000)
    assert result is not None  # ❌ Проверяет только, что не None
 
def test_process_payment():
    process_payment(100)
    assert True  # ❌ Всегда проходит

Что проверять:

• Есть ли integration tests (не только unit tests)?
• Есть ли E2E tests для критичных flows?
• Тестируются ли edge cases и error scenarios?
• Как часто тесты падают (flaky tests)?

Ошибка 5: Не провести нагрузочное тестирование

Почему критично:

Код может работать отлично при 10 пользователях и падать при 100.

Кейс из практики:

Аудит показал хороший код. Купили. Black Friday — система упала. Причина: N+1 запросы в базу, которые проявились только под нагрузкой.

Минимум:

• Проведите stress test с 2-5x текущей нагрузки
• Найдите bottleneck (БД? API? Frontend?)
• Оцените стоимость масштабирования

Ошибка 6: Не проверить compliance и legal

Что упускают:

• Лицензии open source библиотек (GPL vs MIT vs Apache)
• Использование pirated software
• GDPR/CCPA compliance для персональных данных
• Права на код (contributor agreements)

Пример проблемы:

Стартап использовал GPL-библиотеку в проприетарном продукте. После покупки получили письмо от правообладателей с требованием открыть код или заплатить штраф $500K.

Проверка:

# Проверка лицензий в Node.js проекте
npm install -g license-checker
license-checker --summary
 
# Ищем GPL/AGPL лицензии (могут требовать раскрытия кода)
license-checker | grep -i "gpl"

Ошибка 7: Не оценить зависимость от конкретных людей

Beyond Bus Factor:

Проверьте:

• Кто единственный знает deployment процесс?
• Кто единственный имеет доступ к production?
• Кто единственный понимает billing логику?

Реальный пример:

Купили стартап. Через месяц узнали, что AWS account на личной кредитке founder-а. Founder уволился. Потеряли 3 дня на миграцию аккаунтов и чуть не потеряли доступ к production.

Проверка:

• Все critical доступы на корпоративных аккаунтах
• Минимум 2 человека имеют доступ к каждому критичному ресурсу
• Документирован процесс передачи доступов

Чек-лист для проведения due diligence

✅ Code & Architecture

• Metrics: Complexity, Coverage, Duplication в норме
• Architecture: Соответствует scale и бизнес-задачам
• Patterns: Использованы best practices
• Dependencies: Актуальные, без критичных уязвимостей
• Technical Debt: Ratio < 15%

✅ Security

• Authentication: Secure password storage (bcrypt/argon2)
• Authorization: Proper access control
• Data Protection: Encryption at rest and in transit
• Input Validation: Protection от injection attacks
• Secrets Management: Нет ключей в коде
• Security Audit: Проведён за последние 12 месяцев

✅ Infrastructure & DevOps

• CI/CD: Автоматизированный deployment
• Monitoring: APM, error tracking, alerting
• Backups: Регулярные + tested recovery
• Scalability: Может масштабироваться горизонтально
• High Availability: Нет single points of failure
• Disaster Recovery: План есть и проверен

✅ Testing

• Unit Tests: Coverage > 60%
• Integration Tests: Критичные flows покрыты
• E2E Tests: Есть smoke tests для production
• Load Testing: Проведено для peak load
• Security Testing: Penetration testing выполнен

✅ Documentation

• Architecture Docs: ADR (Architecture Decision Records)
• API Documentation: Актуальная (Swagger/OpenAPI)
• Deployment Guide: Пошаговый процесс
• Runbooks: Incident response procedures
• Onboarding: Документация для новых разработчиков

✅ Team & Process

• Bus Factor: ≥ 3 для критичных компонентов
• Code Review: Обязателен для всех PR
• Knowledge Sharing: Регулярные tech talks/pairing
• Development Process: Defined и следуется
• Tech Debt Management: Планируется и отслеживается

✅ Compliance & Legal

• Licenses: Open source лицензии совместимы
• IP Rights: Вся интеллектуальная собственность принадлежит компании
• GDPR/Privacy: Compliance для целевых регионов
• SLAs: Документированы и выполняются

Реальные кейсы

Кейс 1: "Красивое демо, ужасный код"

Ситуация:

SaaS продукт для управления проектами. 10K платящих пользователей, $500K ARR. Цена сделки: $5M.

Due Diligence обнаружил:

• База данных: один PostgreSQL сервер, нет репликации
• Backup: последний успешный backup — 2 месяца назад
• Authentication: passwords в MD5
• Test coverage: 8%
• Bus Factor: 1 (основной разработчик уже уволился)

Критичные риски:

Security incident: 90% вероятность в течение года
Data loss risk: 60% вероятность
Scalability: Текущая инфраструктура не выдержит рост в 2x

Стоимость исправления:
  Security fixes:        $150K
  Infrastructure:        $200K
  Tests:                 $100K
  Knowledge recovery:    $80K
  ────────────────────────────
  Total:                 $530K

Риск downtime: $2M потенциальных потерь

Решение:

Сделка не состоялась. Продавец не согласился на переоценку с учётом рисков.

Кейс 2: "Как мы купили стартап и увеличили выручку в 3x"

Ситуация:

E-learning платформа. 5K пользователей, $200K ARR. Цена: $1.5M.

Due Diligence показал:

• Code Quality: хороший (Debt Ratio 12%)
• Test Coverage: 75%
• Architecture: модульная, расширяемая
• Security: нет критичных проблем
• Team: Bus Factor = 4

Найденные возможности:

• Infrastructure overprovisioned (можно сэкономить 40%)
• Нет A/B testing framework (можно увеличить conversion)
• Mobile app устаревший (переписать на React Native)

Результат:

Покупка:                     $1.5M
Infrastructure optimization: -$40K/год
Feature velocity увеличилась: +50% (благодаря хорошему коду)
Новые фичи:                  +$400K ARR за год

ROI: 26% в первый год

Кейс 3: "Скрытый технический долг съел всю прибыль"

Ситуация:

Fintech startup. 20K пользователей, $800K ARR. Цена: $6M.

Due Diligence упустил:

• Load testing не проводился (упустили при аудите)
• Документация архитектуры была, но устаревшая
• Команда не упомянула о "медленных" endpoints

Что случилось после покупки:

Black Friday. Нагрузка выросла в 5x. Система упала.

Корень проблемы:

# Найдено после инцидента
def get_user_transactions(user_id):
    # Этот код вызывался 1000 раз в секунду
    all_transactions = db.query("SELECT * FROM transactions")  # 10M записей!
    user_txs = [tx for tx in all_transactions if tx.user_id == user_id]
    return user_txs
 
# N+1 problem в критичном коде
# Нагрузочное тестирование это бы показало

Результат:

• 12 часов downtime
• $150K упущенной выгоды
• 1 месяц на emergency fix
• Trust подорван у пользователей

Урок:

Load testing обязателен для due diligence. Без него вы не знаете, как система ведёт себя под нагрузкой.

Для основателей: как подготовить стартап к техническому аудиту

Эта секция для founders, которые планируют продажу или привлечение инвестиций. Хорошая подготовка может увеличить цену сделки на 10-20%.

За 6 месяцев до сделки

1. Исправить критичные security проблемы

Приоритет #1:

# Проверьте свой проект СЕЙЧАС:
# 1. Secrets в коде
git log --all --full-history -S "password=" -S "api_key="
 
# 2. Security уязвимости
npm audit --audit-level=high
pip-audit
 
# 3. Outdated зависимости с CVE
npm outdated

Что исправить немедленно:

• ✅ Пароли: bcrypt/argon2 (не MD5/SHA1)
• ✅ Secrets: переместить в environment variables или secrets manager
• ✅ SQL Injection: параметризованные запросы везде
• ✅ HTTPS: везде, без исключений
• ✅ Dependencies: обновить пакеты с критичными CVE

Инвестиция: 2-4 недели разработки ROI: Предотвращает снижение цены сделки на 20-40%

2. Покрыть тестами критичный функционал

Не нужно 80% coverage. Нужно покрыть business-critical код:

• Authentication & Authorization
• Payment processing
• Data access layer
• Core business logic

Цель: Coverage > 60% на критичных модулях

Инвестиция: 1-2 месяца ROI: Показывает серьёзность команды, снижает риски для покупателя

3. Начать вести ADR (Architecture Decision Records)

Что это:

Документация архитектурных решений в формате:

# ADR-001: Выбор базы данных PostgreSQL вместо MongoDB
 
## Контекст
 
Нам нужна БД для хранения транзакций с сильной consistency
 
## Решение
 
Используем PostgreSQL с ACID гарантиями
 
## Последствия
 
- Плюсы: Транзакции, foreign keys, mature ecosystem
- Минусы: Сложнее горизонтальное масштабирование
- Риски: При росте > 10M записей нужно будет шардировать

Почему важно:

Покупатель видит, что решения принимались обоснованно, а не "как получилось".

Шаблон ADR: adr.github.io

4. Настроить автоматический мониторинг метрик

Минимальный стек:

• Error tracking: Sentry (бесплатно до 5K events/месяц)
• Uptime monitoring: UptimeRobot (бесплатно для 50 мониторов)
• Application metrics: Prometheus + Grafana (open source)

Зачем:

During due diligence покупатель попросит показать метрики за последние 3-6 месяцев. Без мониторинга вы не сможете ответить на:

• Какой у вас uptime?
• Сколько ошибок в день?
• Какая средняя response time?

Инвестиция: 1-2 недели на настройку ROI: Демонстрирует зрелость процессов

За 3 месяца до сделки

5. Рефакторинг top-3 проблемных модулей

Как найти:

# Git: самые часто изменяемые файлы
git log --since="6 months ago" --pretty=format: --name-only \
  | sort | uniq -c | sort -rg | head -10
 
# Python: самые сложные модули
radon cc -a src/ -n C

Что делать:

• Если Complexity > 20 → разбить на функции
• Если Code Duplication → вынести в utils
• Если Bus Factor = 1 → провести knowledge sharing

6. Написать deployment и recovery документацию

Что должно быть:

• Deployment Guide: Пошаговый процесс деплоя
• Rollback Procedure: Как откатить релиз
• Disaster Recovery Plan: Что делать при падении БД/сервера
• Runbooks: Типичные инциденты и решения

Формат:

# Deployment Guide
 
## Pre-deployment checklist
 
- [ ] Tests проходят в CI
- [ ] Staging testing completed
- [ ] Database migrations reviewed
 
## Deployment steps
 
1. `git pull origin main`
2. `docker-compose build`
3. `docker-compose up -d`
4. Run health check: `curl /health`
 
## Rollback procedure
 
1. `git revert HEAD`
2. Redeploy previous version

7. Провести внутренний security audit

Опции:

• Нанять external security consultant ($5K-15K)
• Использовать automated tools (OWASP ZAP, Burp Suite)
• Code review с фокусом на security

Цель:

Найти и исправить проблемы ДО того, как их найдёт покупатель.

За 1 месяц до сделки

8. Подготовить "Data Room" для due diligence

Структура Data Room:

technical-data-room/
├── architecture/
│   ├── system-architecture.pdf
│   ├── database-schema.sql
│   ├── api-documentation.yaml (OpenAPI)
│   └── adr/ (Architecture Decision Records)
├── metrics/
│   ├── performance-reports/ (last 6 months)
│   ├── uptime-statistics.csv
│   └── error-rate-trends.png
├── security/
│   ├── security-audit-report.pdf
│   ├── penetration-test-results.pdf
│   └── compliance-certificates/ (SOC2, ISO, etc.)
├── code-quality/
│   ├── sonarqube-report.html
│   ├── test-coverage-report.html
│   └── dependency-audit.txt
├── team/
│   ├── team-structure.pdf
│   ├── knowledge-distribution.csv (Bus Factor анализ)
│   └── onboarding-guide.md
└── tech-stack/
    ├── technologies-used.md
    ├── infrastructure-diagram.pdf
    └── third-party-services.xlsx

Зачем:

• Ускоряет due diligence (экономия 1-2 недель)
• Демонстрирует профессионализм
• Снижает "красные флаги"

9. Провести mock due diligence

Как:

• Попросите CTO друга или advisor провести аудит
• Используйте чек-лист из этой статьи
• Исправьте найденные проблемы

Вопросы для mock audit:

1. Можете ли вы запустить проект локально за < 30 минут?
2. Есть ли критичные security проблемы?
3. Какой Bus Factor?
4. Может ли система масштабироваться в 5x?
5. Что произойдёт, если БД упадёт прямо сейчас?

Что делать НЕ нужно

❌ Переписывать код на новый фреймворк — слишком рискованно

❌ Добавлять фичи ради демо — покупателю нужна стабильность, не фичи

❌ Скрывать проблемы — всё равно найдут, но потеряете доверие

❌ 100% test coverage — это трата времени, достаточно 60-70% на core

ROI подготовки к аудиту

Затраты:

Security fixes:           2-4 недели
Testing:                  1-2 месяца
Documentation:            2-4 недели
Monitoring setup:         1-2 недели
Mock audit:               1 неделя
──────────────────────────────────
Итого:                   3-4 месяца работы
Стоимость (1 dev):        $40K-60K

Выгода:

• Цена сделки: +10-20% ($200K-500K для сделки $2M-5M)
• Скорость сделки: -20% времени (быстрее closing)
• Вероятность срыва: -50%

Реальный кейс:

Стартап потратил $50K на подготовку к аудиту (4 месяца):

• Исправили security проблемы
• Покрыли тестами core
• Написали документацию

Результат:

• Изначальное предложение: $3M
• После due diligence: $3.6M (+20%)
• ROI подготовки: $600K / $50K = 12x

Стоимость Technical Due Diligence

Кто проводит

• In-house CTO/Tech Lead — если есть компетенция
• External consultant — независимый эксперт (Senior/Principal/CTO level)
• Specialized firm — для крупных M&A сделок

Бюджет

Что делать с результатами due diligence

Сценарий 1: Всё отлично (редко бывает)

Показатели:

• Technical Debt Ratio < 10%
• Test Coverage > 70%
• Security issues: minor или нет
• Bus Factor ≥ 4
• Хорошая документация

Действие:

✅ Покупать по заявленной цене или даже с премией (если команда сильная)

Сценарий 2: Контролируемые риски (часто)

Показатели:

• Debt Ratio 15-20%
• Test Coverage 40-60%
• Security: нет критичных, но есть medium issues
• Bus Factor 2-3
• Документация частичная

Действие:

📊 Переоценка с учётом рекомендованной стоимости:

Original price:        $5.0M
Remediation cost:      $0.8M
Risk discount (15%):   $0.7M
─────────────────────────────
Adjusted offer:        $3.5M

ИЛИ

Original price с условиями:
- $2M upfront
- $3M earnout (при достижении метрик после исправлений)

Сценарий 3: Критичные проблемы (иногда)

Показатели:

• Debt Ratio > 30%
• Critical security issues
• Bus Factor = 1
• Нет тестов, нет документации

Действие:

❌ Расходиться или радикальная переоценка:

Original price:        $5.0M
Remediation cost:      $2.5M
Risk premium:          $1.5M
─────────────────────────────
Adjusted offer:        $1.0M

+ Условия:
  - Ключевые разработчики остаются на 2 года
  - 6 месяцев transition period
  - Earnout привязан к метрикам качества

Выводы и рекомендации

Основные принципы

1. Technical due diligence — не опция, а обязательное условие для tech-сделок
2. Красивое demo ≠ качественный код — всегда смотрим под капот
3. Технический долг измеряется в деньгах — считайте remediation + opportunity + risk cost
4. Bus Factor = 1 — это критичный риск — требует немедленных мер
5. Нагрузочное тестирование обязательно — без него вы не знаете пределы системы

Минимальный чек-лист

Даже если времени мало, проверьте эти 5 вещей:

1. Security — пароли, secrets, SQL injection
2. Bus Factor — кто владеет знаниями
3. Test Coverage — есть ли хоть какие-то тесты
4. Dependencies — критичные уязвимости
5. Infrastructure — single points of failure

Когда НЕ покупать

• ❌ Критичные security уязвимости + нежелание продавца исправлять
• ❌ Вся команда уже ушла и Bus Factor был = 1
• ❌ Remediation cost > 50% цены сделки
• ❌ Продавец скрывает доступ к коду или отказывается от due diligence

Когда покупать с премией

• ✅ Отличное code quality + сильная команда
• ✅ Хорошая документация и процессы
• ✅ Scalable архитектура
• ✅ High Bus Factor (≥ 5)
• ✅ Technical Debt управляется осознанно

Нужна помощь с Technical Due Diligence?

За 15 лет я провёл технический аудит многих проектов перед инвестициями и покупкой. Помогу:

• Провести полный technical due diligence
• Оценить технический долг в деньгах
• Выявить критичные риски
• Подготовить отчёт для инвесторов/board
• Составить remediation roadmap

Пишите на почту — обсудим ваш кейс.

Первая консультация — бесплатно. Расскажу, на что обратить внимание в вашей конкретной ситуации.

Понравилась статья?

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

Подписывайтесь на обновления в Telegram — пишу про архитектуру, техническое управление и инвестиции в tech. Только практика, без воды.