Технологический due diligence иногда воспринимают как проверку качества кода. Но красивый код сам по себе ещё не делает компанию хорошей покупкой, а старый стек не означает автоматически плохую.
Главный вопрос другой: какие технологические обязательства, ограничения и риски переходят к покупателю вместе с бизнесом?
Начните с связи технологии и бизнеса
Нужно понять, какие части технологии действительно критичны для выручки, клиентов и дальнейшего роста.
Что невозможно быстро заменить? Какие функции создают отличие продукта? Где компания зависит от ручных операций? Что произойдёт, если нагрузка, количество клиентов или география заметно изменятся?
Без этого архитектурная проверка легко превращается в спор о вкусах.
Проверьте не красоту архитектуры, а её ограничения
Любая работающая система содержит компромиссы. Важнее понять, где они уже начинают стоить бизнесу денег или скорости.
Какие компоненты сложно менять? Где слишком много связей? Что регулярно ломается? Какие изменения команда боится делать? Есть ли части продукта, которые невозможно развивать без большого проекта?
Это и есть реальные технологические обязательства будущего владельца.
Посмотрите, на ком держится система
Один из самых дорогих рисков может находиться не в коде, а в людях.
Есть ли один инженер, который знает критическую систему? Кто умеет выпускать релизы? Кто понимает инфраструктуру? Кто принимает архитектурные решения? Что произойдёт, если два ключевых человека уйдут после сделки?
Документация полезна, но она не всегда компенсирует концентрацию знаний.
Разберитесь с данными
Нужно понимать, какие данные компания хранит, откуда они приходят, кому принадлежат, насколько легко их восстановить и перенести.
Особенно опасны ситуации, когда продукт критически зависит от данных, но нет ясности по их качеству, происхождению, доступам или резервному восстановлению.
Проблема с данными после сделки может оказаться намного дороже плохого фреймворка.
Проверьте внешние зависимости
Продукт может выглядеть собственным, но большая часть его возможностей может зависеть от внешних поставщиков, лицензий, облачных сервисов, закрытых API или одного подрядчика.
Что произойдёт при росте цены поставщика? Можно ли сменить его? Какие условия договора критичны? Есть ли технология, которую компания фактически не контролирует?
Vendor lock-in — это не обязательно проблема. Но он должен быть осознанной частью цены сделки.
Безопасность проверяйте через последствия
Бессмысленно спрашивать только «есть ли security policy». Важнее понять, какие сценарии реально опасны для бизнеса.
Кто имеет доступ к production и данным? Как управляются секреты? Что происходит при компрометации учётной записи? Есть ли резервное восстановление? Проводились ли критические изменения вручную без контроля?
Цель не найти компанию без риска. Таких компаний нет. Цель — понять размер и управляемость риска.
Посчитайте не только проблемы, но и стоимость их исправления
Длинный список замечаний почти бесполезен без приоритета. Десять мелких архитектурных недостатков могут стоить меньше одного кадрового риска.
Для каждого существенного ограничения полезно понять: нужно ли его исправлять вообще, когда оно станет критичным, сколько организационных изменений потребуется и что произойдёт, если ничего не делать.
Хороший technology due diligence не отвечает на вопрос «насколько хороший здесь код». Он помогает покупателю понять, какую технологическую реальность он действительно покупает и сколько свободы она оставляет бизнесу после сделки.