Технологический Due Diligence: как мы сэкономили инвестору ₽35 млн

Фонд прямых инвестиций рассматривал приобретение B2B SaaS-платформы для управления недвижимостью. На бумаге всё выглядело идеально: 2000+ активных пользователей, ₽180M годовой выручки, растущий рынок. Стоимость сделки: ₽200M. Но у фонда не было in-house экспертизы в технологиях. Нас привлекли как независимого технологического эксперта для проведения комплексного аудита. То, что мы обнаружили за 3 недели, изменило условия сделки на ₽35M.

---

Фонд прямых инвестиций изучал возможность приобретения зрелой SaaS-платформы для управления недвижимостью. Платформа уже существовала на рынке 8 лет, имела стабильную клиентскую базу (более 2000 компаний), и показывала позитивную динамику роста. Основные показатели:

• Выручка: ₽180M в год (ARR)
• Активные пользователи: 2000+
• Команда: 5 разработчиков
• Предлагаемая цена: ₽200M
• Статус: прибыльная, но без активного развития

Фонд планировал купить платформу, нанять новых разработчиков, и масштабировать продукт на новые рынки. Но перед закрытием сделки нужна была независимая оценка технологических рисков. Стандартный финансовый и юридический Due Diligence не раскрывает техдолга, скрытых проблем с качеством кода или инфраструктурой.

Наша задача: провести комплексный технологический аудит и дать объективную оценку IT-активов платформы.

---

На первый взгляд платформа выглядела на удивление хорошо: современный интерфейс, отзывчивая поддержка, растущая база пользователей. Но фонд понимал простую истину: красивый фронтенд не говорит о качестве архитектуры, безопасности и масштабируемости под капотом.

Главный риск: фонд не имел технического специалиста, который мог бы оценить реальное состояние кода. Предыдущая финансовая due diligence пропустила все технологические проблемы. Без комплексного технологического аудита фонд рисковал купить платформу с огромным скрытым техдолгом, который превратился бы в убыток при попытке её развивать.

Мы согласились провести 3-недельный аудит по методологии, которая охватывает все критические области: архитектура, качество кода, безопасность, инфраструктура, команда, интеллектуальная собственность.

---

Наш подход к технологическому Due Diligence строился на 6 ключевых направлениях:

1. Архитектура и масштабируемость

• Анализ структуры приложения (монолит vs микросервисы, слои архитектуры)
• Выявление single points of failure
• Оценка способности масштабирования горизонтально
• Анализ зависимостей между компонентами

Результат: монолитная архитектура на PHP 7.2 (версия из 2016 года), без разделения ответственности. Масштабирование возможно только вертикально (более мощные серверы). При увеличении нагрузки потребуется полная переписка на современный стек.

2. Качество кода

• Статический анализ с SonarQube
• Проверка дублирования кода
• Оценка покрытия тестами
• Анализ цикломатической сложности

Результат: SonarQube выявила 2300 потенциальных ошибок (bugs, code smells), 47% дублирования кода, 0% покрытия тестами. Это означает, что любое изменение в коде может привести к непредсказуемым последствиям.

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

• Динамический анализ с OWASP ZAP
• Проверка на SQL injection, XSS, CSRF
• Анализ управления доступом и аутентификации
• Проверка шифрования данных

Результат: OWASP ZAP обнаружила 12 критических уязвимостей и 34 высокоприоритетных. В том числе: SQL injection в 3 местах, хранение пароля в plaintext в одном из модулей, отсутствие защиты от CSRF. Платформа обрабатывает финансовые данные клиентов — эти уязвимости критичны.

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

• Анализ настройки серверов (один сервер или кластер)
• Проверка CI/CD pipeline
• Оценка процессов резервирования
• Анализ мониторинга и логирования

Результат: весь production работает на одном сервере. Нет CI/CD — деплой вручную через SSH. Резервные копии не верифицированы более 6 месяцев. Отсутствует система мониторинга. Любой отказ сервера = полный downtime платформы.

5. Команда и управление

• Анализ численности и компетенций
• Оценка "bus factor" (риск потери критических знаний)
• Проверка наличия документации
• Интервью с разработчиками

Результат: bus factor = 1 для ядра платформы (один разработчик знает её устройство). Минимальная документация. Двое из пяти разработчиков планируют уход в течение 3 месяцев. При покупке фонд потеряет критических людей и останется без документации.

6. Интеллектуальная собственность

• Аудит лицензирования зависимостей
• Проверка на использование GPL код в proprietary коде
• Анализ авторских прав и прав на исходный код

Результат: обнаружены 3 GPL-лицензированные библиотеки, используемые в proprietary коде. Это потенциальное нарушение лицензии — могло бы потребовать выпуска исходного кода в открытый доступ или судебного разбирательства.

---

После трёх недель интенсивного аудита мы рассчитали полную стоимость приведения платформы в надлежащее состояние. Это число поразило даже фонд.

Распределение затрат на исправление:

• Переписка архитектуры и переход на современный стек: ₽20M (8-10 месяцев разработки)
• Исправление security уязвимостей: ₽5M (3 месяца)
• Миграция инфраструктуры на облако с redundancy: ₽4M (сервера + настройка)
• Восстановление команды и документирование: ₽6M (найм и обучение новых разработчиков)

Сроки исправления: 12-18 месяцев при усиленной команде разработчиков (8-10 человек). Это означает, что платформа будет нестабильной и непредсказуемой в течение года после покупки.

"Когда мы услышали про ₽35M техдолга, сначала не поверили. Но числа проверены трижды: статический анализ, динамическое тестирование, расчёт на основе похожих проектов. Это реальная стоимость приведения платформы в порядок. Без этого аудита мы бы купили бомбу замедленного действия."

— Сергей Волков, партнер инвестфонда

Динамическое тестирование нагрузки (k6): мы протестировали платформу на масштабируемость и обнаружили, что при 500 одновременных пользователей сервер падает. Это происходит примерно в 20% от текущей пиковой нагрузки. Риск потерь — высокий.

---

Несмотря на выявленные проблемы, мы не рекомендовали отказаться от сделки. Платформа имеет реальную ценность: стабильная пользовательская база, доказанный бизнес-модель, растущий рынок. Но мы рекомендовали:

1. Переторговать цену. С ₽200M на ₽165M. Разница в ₽35M должна покрыть стоимость исправления выявленных проблем.

2. Включить в договор обязательный технологический roadmap: за первые 90 дней после закрытия сделки нужно составить детальный план миграции архитектуры и исправления security уязвимостей.

3. Нанять CTO немедленно. Без технического лидера попытка масштабировать платформу приведёт к ещё большему техдолгу.

4. Начать с security. Исправить все критические и высокоприоритетные уязвимости в первые 3 месяца. Платформа обрабатывает данные клиентов — это не может ждать.

5. Документировать всё. До того, как разработчики уходят, нужно задокументировать архитектуру, критические сценарии, важные решения.

Фонд согласился со всеми рекомендациями. Сделка была закрыта по переторгованной цене ₽165M с условием обязательного исправления выявленных проблем в течение 12 месяцев.

---

Набор инструментов, которые мы использовали:

• SonarQube: статический анализ кода, выявление ошибок и code smells. Показала 2300 потенциальных проблем.
• OWASP ZAP: динамическое тестирование безопасности. Выявила 12 критических уязвимостей.
• k6: load testing и тестирование производительности. Показала, что платформа падает при 500 одновременных пользователей.
• Custom скрипты на Python: анализ зависимостей, проверка лицензирования, аудит истории коммитов в Git.
• Qualys SSL Labs: аудит SSL/TLS конфигурации (оценка F из-за устаревших шифров).

Подход и ограничения: аудит был проведён полностью non-invasive. Мы получили read-only доступ к исходному коду, access к staging-окружению, и документацию. Не трогали production. Это ключевой момент: все анализы делались в безопасной среде, без риска downtime для платформы.

Итоговый отчёт: 47 страниц детального анализа, включая:

• Краткий Executive Summary (для инвесторов)
• Техническое резюме (для будущего CTO)
• Детальный анализ по 6 направлениям с примерами из кода
• Risk matrix (критичность vs вероятность)
• Расчёт стоимости исправления и timeline
• Рекомендации по приоритизации работ

---

Красивый UI не означает хорошую архитектуру. Платформа выглядела современно и работала гладко для конечных пользователей. Но под капотом был хаос: устаревший stack, нет тестов, критические уязвимости. Инвесторы часто попадаются на такие подводные камни.

Тестовое покрытие = 0 — это красный флаг даже если продукт "работает". Значит, разработчики могут изменить код и сломать что-то, не заметив. При масштабировании это превращается в кошмар. Никакой надёжности.

Всегда проверяйте стабильность команды. Если два из пяти разработчиков уходят, это потеря 40% знаний. В данном случае это было катастрофой, потому что bus factor = 1. Команда — это часть цены сделки, не только код.

GPL лицензирование требует особого внимания. Одно нарушение лицензии может парализовать весь бизнес. Нужно провести аудит зависимостей до покупки.

Инфраструктура как risk-фактор. Если весь production на одном сервере и без автоматизированного деплоя, это означает высокий риск downtime при развитии. Инвесторы должны закладывать это в стоимость.

Технологический Due Diligence окупается в разы. Стоимость нашего аудита составила ₽800K. Мы помогли сэкономить ₽35M на техдолге. ROI = 4375%. Это одна из самых выгодных инвестиций, которую фонд может сделать перед закрытием сделки.

Итоговая метрика проекта:

Этот проект показал критическую важность технологического Due Diligence при M&A сделках. Beautiful UI не замещает качество архитектуры, безопасность, и управление техдолгом. Инвесторы, которые пропускают этот этап, часто платят в несколько раз больше после закрытия сделки.