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

> Что смотрит инвестор на техническом due diligence, какие находки становятся красными флагами и какие документы стоит собрать заранее.

Published: 2026-09-03 · Source: https://subxcat.com/ru/articles/tech-due-diligence · Author: SUBXCAT

Когда разговор с инвестором доходит до технической проверки, команда часто узнаёт о своём коде больше, чем хотела бы. Ключи в истории репозитория, единственный человек с доступом к продакшну, резервные копии, из которых никто ни разу не восстанавливался. Обычно ни одна из этих вещей сама по себе сделку не убивает. Убивает то, что они всплывают неожиданно и выглядят как вещи, о которых команда не знала.

## Что смотрят

Глубина проверки зависит от стадии и суммы, но темы почти всегда одни и те же.

**Архитектура.** Из чего состоит система, как связаны части, что будет при росте нагрузки в несколько раз. На ранней стадии никто не ждёт идеала — ждут понимания: где узкие места и что с ними делать.

**Код.** Читается ли он, есть ли тесты на важное — деньги, права доступа, данные, — как устроены ревью и релизы. Если заметная часть кода написана с помощью ИИ, вопрос будет простым: кто в команде понимает, как это работает, и может ли это поменять.

**Безопасность.** Где хранятся секреты, как устроены вход и права, обновляются ли зависимости, у кого есть доступ к продакшну и базе.

**Инфраструктура и эксплуатация.** Как выкатываются изменения, есть ли мониторинг и алерты, есть ли резервные копии и проверяли ли восстановление, что было на последних сбоях.

**Данные.** Какие персональные данные хранятся, где физически, кто их видит, соответствует ли это законам стран, где живут пользователи.

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

**Команда и зависимости.** Что будет, если уйдёт один ключевой разработчик. Насколько продукт зависит от внешних сервисов и во что обойдётся уйти от каждого.

## Красные флаги

То, что встречается часто и выглядит плохо:

- секреты и пароли в репозитории, в том числе в старых коммитах;
- к продакшну подключаются с личных ноутбуков, учётные записи общие;
- из резервных копий ни разу не восстанавливались;
- нет отдельной среды для проверки, изменения уходят сразу к пользователям;
- нет тестов на платежи и права доступа;
- код, который никто в команде не может объяснить;
- непонятно, кому принадлежит код, написанный подрядчиком;
- расходы на инфраструктуру или внешние API растут быстрее выручки, и никто не знает почему.

## Что подготовить

Хорошая новость: большая часть подготовки — документы, а не переписывание кода.

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

Последний пункт важнее, чем кажется. Долг, который команда назвала сама и для которого есть план, — нормальная часть ранней компании. Тот же долг, найденный проверяющим, выглядит как признак того, что команда не видит собственный продукт.

## Когда начинать

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

SUBXCAT проводит такой аудит заранее и помогает закрыть найденное до того, как это найдёт кто-то другой.