Когда техдолг убивает раунд: 5 красных флагов для инвестора
Технический due diligence стал стандартной частью любого раунда от Series A и выше. Инвесторы нанимают внешних технических консультантов, которые проводят 2–4 недели в вашем коде, архитектуре и процессах. Их задача — найти то, что вы не показываете в питч-деке.
Плохая новость: большинство проблем, которые они находят, известны основателям заранее. Хорошая новость: почти все их можно устранить за 4–8 недель до начала DD — если знать, где смотреть.
Вот пять флагов, которые реально останавливают раунды или существенно снижают оценку.
// Флаг 1: Монолит без границ
Сам по себе монолит — не проблема. Проблема — монолит, в котором всё знает всё. Консультанты открывают репозиторий и первым делом смотрят на связность: сколько модулей импортируют друг друга напрямую, есть ли циклические зависимости, обращается ли один модуль к таблицам другого.
Если ответ «всё вперемешку» — вопросы становятся жёсткими. Как вы будете масштабировать отдельные компоненты? Как наймёте второго тимлида, если они не могут работать независимо? Сколько займёт добавление нового платёжного провайдера, если платёжная логика разбросана по 40 файлам?
За 3–4 недели до DD можно сделать следующее: нарисовать явную карту зависимостей, убрать самые грубые циклы, задокументировать границы модулей даже если код ещё не полностью их соблюдает. Документация архитектуры существенно снижает уровень тревоги у проверяющих.
// Флаг 2: Нет тестов — нет уверенности
Нулевое покрытие тестами — не автоматический стоп-фактор. Стоп-фактор — это когда команда не может ответить на вопрос: «Как вы знаете, что новая фича не сломала старую?»
Если ответ «мы вручную проверяем перед деплоем» — следующий вопрос будет про скорость доставки и стабильность продукта. При ручном тестировании цикл обратной связи растягивается до нескольких дней. Для инвестора это означает замедление разработки с ростом команды, а не ускорение.
Минимальная планка, которую стоит достичь до DD: интеграционные тесты на критических бизнес-путях (оплата, регистрация, основной workflow). Не 80% coverage — просто работающий CI, который не даёт задеплоить явно сломанный код.
# Минимальный CI pipeline — уже лучше, чем ничего
# .github/workflows/ci.yml
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
- run: npm run lint// Флаг 3: Нет CI/CD — деплой как стресс-событие
Если деплой — это ручная процедура с инструкцией на 15 шагов, которую знают двое, — это проблема масштабирования. Инвесторы прекрасно понимают: скорость итерации определяет конкурентоспособность. Компания, которая деплоит раз в две недели вручную, будет проигрывать компании с continuous delivery.
Ещё хуже — если деплой сопровождается даунтаймом. Это сразу поднимает вопрос: что происходит с пользователями во время деплоя? Есть ли rollback-процедура? Сколько времени она занимает?
Настроить базовый CI/CD pipeline за 1–2 недели вполне реально даже без переработки архитектуры. GitHub Actions + автоматический деплой на staging по merge в main — это минимум, который закрывает большинство вопросов.
// Флаг 4: Общая база для dev и prod
Звучит как очевидная ошибка — но встречается чаще, чем кажется. Особенно в командах, которые росли быстро и не успевали формализовывать процессы. Последствия: разработчики случайно модифицируют продакшн-данные, тестовые миграции применяются к реальной базе, нет изоляции для экспериментов.
Для инвестора это сигнал о зрелости команды. Это не техническая проблема — это операционная дисциплина. Вопрос немедленно связывается с безопасностью данных: если dev имеет доступ к prod БД, кто ещё имеет к ней доступ и как это контролируется?
Решается за несколько дней: отдельный инстанс БД для dev/staging, secrets management через переменные окружения, явное разделение конфигов. Документируйте это и покажите проверяющим.
# Переменные окружения — не опционально
DATABASE_URL=postgresql://user:pass@prod-host/proddb # .env.production
DATABASE_URL=postgresql://user:pass@localhost/devdb # .env.development
# Никогда не коммитьте .env файлы
# .gitignore
.env
.env.local
.env.production// Флаг 5: Нет мониторинга и bus factor = 1
Два отдельных флага, которые часто идут вместе. Мониторинг — это базовый вопрос операционной зрелости: «Как вы узнаёте, что что-то сломалось?» Если ответ «нам пишут пользователи» — оценка снижается.
Bus factor — более серьёзная проблема для инвестора. Если один человек знает, как устроена критическая часть системы, и только он может её починить — это операционный риск, который нельзя проигнорировать. Особенно если этот человек — технический co-founder, которому предстоит тратить время на fundraising и общение с советом директоров.
Инвесторы не требуют идеального кода. Они требуют доказательств, что вы контролируете ситуацию — и знаете, где она выходит из-под контроля.
Минимум по мониторингу до DD: uptime alerts на критические эндпоинты, error rate dashboard, базовые метрики производительности. По bus factor: задокументируйте архитектуру ключевых подсистем, проведите хотя бы одну сессию knowledge transfer с командой.
Как готовиться к DD правильно
Техническая проверка — не экзамен, где нужно всё идеально. Это оценка зрелости команды и управляемости технического долга. Инвесторы понимают, что у стартапа есть долг — они хотят видеть, что вы его осознаёте и умеете с ним работать.
Практический план: за 8 недель до раунда проведите внутренний аудит по этим пяти флагам. Составьте список проблем с оценкой критичности. За 4 недели устраните критические — те, которые вызовут немедленные вопросы. Остальные задокументируйте с планом устранения. Показать работающий roadmap по техдолгу часто важнее, чем показать его полное отсутствие.
Если хотите пройти такой аудит с внешними глазами — это именно то, с чего мы начинаем работу с новыми клиентами.