Технічний due diligence — це не code review. Це відповідь на одне питання: скільки коштуватиме привести цю технологію туди, де її потребує інвестиційна теза?
Більшість технічних due diligence виробляє документ, яким ніхто не користується. У ньому перелічені фреймворки, підраховані тести, зазначено, що документація могла б бути кращою — а потім угода відбувається або ні з абсолютно інших причин. Це змарнована реальна нагода оцінити ризик у грошах.
Корисний технічний due diligence відповідає на три питання бізнес-мовою: чи витримає ця технологія план, який ви фінансуєте, скільки коштуватиме закрити розриви і які ризики здатні знищити вартість, а не просто сповільнити її.
Для чого насправді потрібен технічний due diligence
Венчурний інвестор купує не кодову базу. Він купує тезу: ця команда досягне такого масштабу за такий час. Технологія важлива лише там, де вона робить цю тезу більш або менш імовірною.
| Теза каже | Отже, diligence має встановити |
|---|---|
| Зростання користувачів у 10 разів за 24 місяці | Де ламається архітектура і скільки коштує підняти цю стелю |
| Експансія в ЄС | Чи переживе обробка даних GDPR і скільки коштує відповідна версія |
| Це платіжний бізнес | Цілісність журналу, ідемпотентність, звірка — те, що втрачає справжні гроші |
| Команда вміє виконувати | Пропускна здатність доставки і bus factor, а не якість резюме |
| Захищена технологія | Чи є рів справжньою інженерією, чи це тонкий шар над чужим API |
П'ять сфер, які мають значення
1. Архітектура та запас для масштабування
У кожної системи є стеля. Питання в тому, де вона стосовно плану і наскільки дорого її підняти. Моноліт, який спокійно обслуговує 100 тис. користувачів, — це не знахідка; моноліт з єдиною master-базою на запис і планом зростання до 10 мільйонів — знахідка.
- Єдині точки відмови — і чи знає команда, які саме
- Шар даних — зазвичай справжня стеля і найдорожче для зміни згодом
- Чи тестувалося навантаження, чи масштабування просто припускається
- Крива хмарних витрат: чи переживе юніт-економіка 10×, чи інфраструктура з'їсть маржу?
2. Цілісність грошей і даних
Для будь-якої компанії, що торкається платежів, балансів або регульованих даних, це сфера з найвищою ціною помилки — і та, яку найчастіше пропускають, бо її перевірка вимагає доменної експертизи.
- Чи виводиться баланс із незмінного журналу, чи це змінне число, яке код може перезаписати?
- Ідемпотентність на платіжних шляхах і вебхуках — чи може повтор списати двічі?
- Гроші зберігаються цілими числами в мінорних одиницях, ніколи у float
- Звірка: чи виявили б розбіжність усередині, чи це зробив би клієнт?
3. Ризики безпеки та відповідності
Знахідки з безпеки мають сенс лише прив'язані до наслідку. «Залежності застарілі» — це шум. «Неавтентифікований ендпоінт повертає записи інших орендарів» — це умова угоди.
- Авторизація перевіряється на сервері при кожному запиті, а не схована в інтерфейсі
- Ізоляція мультитенантності — найпоширеніша серйозна знахідка в B2B SaaS
- Управління секретами і чи лежать облікові дані в історії git
- Які регульовані дані зберігаються — і чи взагалі мають зберігатися
- Відстань до сертифікації, якої вимагає go-to-market (SOC 2, ISO 27001, PCI DSS)
4. Спроможність доставляти
Це прогнозує наступні два роки краще, ніж поточна кодова база. Посередня кодова база з міцною дисципліною доставки покращується. Елегантна кодова база без здатності безпечно випускати — ні.
- Частота розгортань і час доставки малої зміни
- Чи є відкат відпрацьованою рутиною, чи теорією
- Покриття тестами шляхів, що мають значення (гроші, auth), а не глобальний відсоток
- Виявлення інцидентів: чи знаходять вони проблеми раніше за клієнтів?
5. Ризик команди та ключової особи
- Bus factor: скільки людей розуміють критичні підсистеми — якщо відповідь «одна», це ризик угоди
- Чи існують знання поза головами
- Залежність від підрядників щодо ключової IP і чи чисте передання прав
- Реалістичність плану найму щодо роадмапу, який фінансується
Червоні прапорці за реальною ціною
| Знахідка | Критичність | Чому |
|---|---|---|
| Змінні баланси / відсутній журнал у фінтеху | Рівень угоди | Збитки необмежені й можливо вже сталися непоміченими |
| Доступ до даних між орендарями | Рівень угоди | Одне розкриття зупиняє enterprise-продажі й активує регуляторів |
| Один інженер тримає всі критичні знання | Висока | Його вихід обнуляє роадмап |
| Немає автоматизації розгортання | Висока | Обмежує пропускну здатність незалежно від найму |
| Незрозумілі права на IP від підрядників | Висока | Юридичне, не технічне — але вбиває exit |
| Застарілі залежності | Низька | Рутинне обслуговування, вимірюється днями |
| Непослідовний стиль коду | Шум | Ігнорувати |
Мета технічного due diligence — не знайти привід відмовитися. Мета — точно знати, що ви купуєте, щоб ціна і план це відображали.
Як знахідки стають умовами угоди
- Бюджет на усунення — оцінити виправлення і профінансувати їх явно в раунді, а не виявити на шостому місяці
- Умови за етапами — вивільнення траншу прив'язане до конкретного усунення (типово, коли розриви відповідності блокують go-to-market)
- Коригування оцінки — там, де усунення велике відносно раунду
- План після закриття — 90-денний технічний роадмап, узгоджений до переказу, а не імпровізований після
Скільки це триває
| Глибина | Тривалість | Коли застосовувати |
|---|---|---|
| Скринінг | 2-3 дні | Рання стадія, малий чек, лише перевірка на здоровий глузд |
| Стандарт | 1-2 тижні | Більшість раундів Series A / Series B |
| Глибокий | 3-4 тижні | Фінтех, healthtech, великий чек або відомо неохайна ціль |
Довше не означає краще. Після двох тижнів більшість проєктів виробляє деталі замість рішень — якщо тільки домен справді цього не вимагає, як платежі чи регульовані медичні дані.
Визначте межі перевірки до збору документів
Огляд має відповідати інвестиційній тезі. Зафіксуйте питання, важливі системи й потрібні докази до оцінювання ризику.
- Пов'яжіть очікуване зростання з місткістю та операційними витратами.
- Розділіть заяви менеджменту, перевірені тести й недоступні дані.
- Відокремте умови закриття угоди від фінансованого плану після неї.
Часті запитання
Чим технічний due diligence відрізняється від аудиту коду?
Аудит коду досліджує якість коду. Технічний due diligence досліджує, чи здатні технологія, команда і процес доставки витримати конкретний бізнес-план — і скільки коштують розриви. Код — це один з п'яти входів; архітектура, безпека, спроможність доставляти і ризик ключової особи зазвичай важать більше для інвестиційного рішення.
Хто платить за технічний due diligence?
Майже завжди інвестор, як частину витрат на угоду. Іноді засновник замовляє його перед раундом, щоб знайти і виправити проблеми раніше за інвесторів — зазвичай це добре витрачені гроші, бо знахідки, виявлені іншою стороною, коштують у переговорах набагато більше, ніж в інженерії.
Чи потрібна співпраця стартапу?
Так. Змістовний diligence потребує доступу до репозиторію на читання, огляду архітектури і розмови з інженерами. Ціль, яка цьому опирається, сама по собі є знахідкою, вартою нотатки.
Чи можна зробити технічний due diligence за кілька днів?
Скринінг — так, і він надійно вихопить проблеми рівня категорії: немає журналу в платіжній компанії, немає автоматизації розгортання, bus factor один. Він не скаже, скільки коштує усунення. Для раунду з оцінкою один-два тижні — реалістичний мінімум.
Чи можна продовжувати з обмеженим доступом?
Так, зі скороченим обсягом і явними обмеженнями. Зафіксуйте невизначеність та запросіть відсутні докази, перш ніж покладатися на висновок.
Робите diligence портфельній компанії?
Ми віддаємо знахідки, впорядковані за бізнес-впливом, із вартістю усунення, яку можна взяти в переговори — за один-два тижні.
Читати далі за темою
Аудит коду перед інвестицією: що вимагати до переказу коштів
Ви за крок від купівлі частки в активі, який не оглядали. Аудит коду — це той огляд, але лише якщо його окреслено під інвестиційні питання, а не інженерні.
Технічний аудит MVP: що ми перевіряємо в перші 48 годин
Більшість аудитів MVP закінчуються документом. Корисний закінчується рішеннями: що горить, що може почекати і скільки коштує виправлення.