Покупка IT-продукта без глубокого технического аудита в 70% случаев приводит к скрытым расходам, которые в первый год эксплуатации могут составить от 30% до 100% от стоимости сделки. Технический due diligence — это единственный способ понять, покупаете ли вы масштабируемый актив или «спагетти-код», который потребует полного переписывания через 6 месяцев.
Анализ архитектуры и масштабируемости
Первым этапом проверка архитектуры на соответствие заявленным нагрузкам. Мы смотрим на разделение ответственности (monolith vs microservices) и наличие узких мест. Если продукт заявляет поддержку 10 000 RPS, но работает на едином экземпляре БД без шардирования и кэширования (Redis/Memcached), система рухнет при первом же скачке трафика. Практика показывает, что перенос монолита на микросервисы после покупки увеличивает бюджет разработки на 40-60%.
Кейс: при аудите FinTech-сервиса была обнаружена синхронная обработка тяжелых отчетов в основном потоке API. Результат: при росте базы пользователей на 15% время отклика выросло с 200 мс до 4 секунд. Вывод: архитектура без очередей сообщений (RabbitMQ, Kafka) в высоконагруженных системах — это критический риск, требующий дисконта в 20% от стоимости актива.
Ревизия качества кода и техдолга
Здесь мы используем статический анализ (SonarQube, Snyk) для поиска code smells и уязвимостей. Критическим показателем является уровень покрытия тестами (Unit test coverage): ниже 60% считается опасным уровнем, так как любое изменение в одной части системы с вероятностью 30% вызовет регрессионную ошибку в другой. Мы ищем «захардкоженные» доступы, отсутствие документации API (Swagger/OpenAPI) и дублирование логики.
Пример: в одном из SaaS-проектов объем дублирующего кода составлял 25%. Это означало, что любая правка бизнес-логики требовала ручного обновления в пяти разных местах. Экспертная оценка: если уровень техдолга требует более 3 месяцев работы команды только на рефакторинг без внедрения новых фич, покупку стоит пересмотреть или существенно снизить цену, опираясь на критерии оценки стоимости IT-технологий при покупке: чек-лист из 15 параметров.
Проверка инфраструктуры и CI/CD процессов
Продукт, который разворачивается «руками» системного администратора через SSH, не является современным IT-активом. Мы проверяем наличие Infrastructure as Code (Terraform, Ansible) и автоматизированных пайплайнов (GitLab CI, Jenkins). Время от коммита до деплоя в продакшн (Lead Time) более 24 часов говорит о низкой зрелости процессов и высоких рисках при интеграции.
Сравнение: команда с полным CI/CD выпускает обновления 10 раз в день с риском отказа 2%, команда с ручным деплоем — 1 раз в неделю с риском отказа 15%. Мой вывод: отсутствие автоматизации развертывания — это скрытый налог на скорость развития продукта, который замедляет Time-to-Market в 3-5 раз.
Аудит безопасности и зависимостей
Особое внимание уделяется Software Bill of Materials (SBOM) — списку всех сторонних библиотек. Использование устаревших версий фреймворков (например, Python 3.6 или PHP 7.0) делает систему уязвимой и затрудняет поиск разработчиков. Мы проверяем лицензии: наличие библиотек под GPL в коммерческом закрытом продукте может привести к юридическому требованию открыть исходный код всего проекта.
Мини-кейс: обнаружение критической уязвимости в старой версии Log4j в купленном модуле потребовало экстренной остановки сервиса на 12 часов и привлечения внешних экспертов по безопасности стоимостью $5 000 за день. Экспертная оценка: технический аудит безопасности должен быть обязательным этапом, чтобы не превратить покупку в источник бесконечных патчей.
Оценка документации и передачи знаний
Код без документации — это legacy-код, даже если он написан вчера. Мы проверяем наличие актуальной схемы БД, описания интеграций и регламентов развертывания. Если знания о системе сосредоточены в голове одного «гуру»-разработчика, вы покупаете не технологию, а зависимость от конкретного человека. Риск ухода такого сотрудника после сделки делает актив бесполезным.
Факт: стоимость восстановления документации «по коду» после покупки составляет от $10 000 до $50 000 в зависимости от сложности системы. Мой вывод: требуйте передачи знаний в формате видео-интервью и актуальной Wiki. Без этого покупка технологий через M&A;: когда выгоднее купить стартап целиком, чем отдельную технологию становится лотереей с низкими шансами на успех.
Вывод
Технический due diligence — это не поиск идеального кода, а оценка стоимости его исправления. Мой вердикт: избегайте продуктов с покрытием тестами ниже 40% и отсутствием CI/CD, так как стоимость их доведения до промышленного стандарта превысит выгоду от покупки. Начинайте с автоматического сканирования кода и анализа архитектуры; если выявлен критический техдолг, требуйте удержания 15-20% суммы сделки на эскроу-счете до полного устранения дефектов или снижайте цену покупки на сумму расчетного рефакторинга.