Ви за крок від купівлі частки в активі, який не оглядали. Аудит коду — це той огляд, але лише якщо його окреслено під інвестиційні питання, а не інженерні.
Аудит коду перед інвестицією є частиною ширшого технічного due diligence і має вужче завдання: встановити, що насправді існує, чи чисте право власності і чи витримає це план, який фінансують.
Погано окреслений, він видає перелік претензій до стилю. Добре окреслений — дві-три знахідки, що змінюють угоду.
Які доступи запитувати
Просіть їх до підписання term sheet. Опір на цьому етапі сам по собі показовий.
- Доступ на читання до всіх репозиторіїв — включно з infrastructure-as-code і скриптами розгортання, де часто видно справжній стан справ
- Повна історія комітів, а не сплющений знімок: історія показує, хто справді збудував систему і як швидко вона рухається
- Огляд архітектури з інженером, який її будував, одна-дві години
- Доступ до трекера задач і, якщо є, до записів про інциденти
- Перелік сторонніх сервісів, від яких залежить продукт
Вісім питань, на які має відповісти аудит
- Чи відповідає наявний код тому, що описували в пітчі? (Demoware та інтеграції, які насправді є ручними процесами, трапляються часто.)
- Хто його написав і чи ці люди досі тут?
- Чи чисте право на IP — підрядники з угодою про передання, немає скопійованого нeліцензованого коду, немає ліцензійного забруднення GPL-залежностями у пропрієтарному продукті?
- Що ламається першим за планом зростання і скільки коштує зсунути цю стелю?
- Чи ізольовані дані клієнтів між орендарями і чи перевіряється авторизація на сервері?
- Для всього фінансового: чи є незмінний журнал і чи ідемпотентний кожен грошовий шлях?
- Чи може команда безпечно розгортати — автоматизація, відкат, моніторинг?
- Яка частина продукту справді їхня, а яка — тонка обгортка над вендорами, що можуть змінити ціни або зникнути?
Знахідки, що виправдовують умову в угоді
| Знахідка | Типовий наслідок |
|---|---|
| Ядро побудоване підрядниками без передання IP | Закрити до переказу — правовий засіб, не технічний |
| Немає журналу в компанії, що рухає гроші | Бюджет на усунення у складі раунду; можливі транші |
| Витік даних між орендарями | Виправлення як умова закриття |
| Критична залежність від вендора без запасного варіанта | Розкритий ризик концентрації; іноді ковенант |
| Bus factor один на ключовій системі | Пакет утримання або страхування ключової особи |
| Немає автоматизованого розгортання | Закладено у план після закриття |
Що не варте вашої уваги
Аудитори, які рахують за знахідками, дадуть вам довгий список. Більшість не має значення для інвестиційного рішення:
- Уподобання щодо фреймворка чи мови — у кожного вибору є критики
- Непослідовний стиль коду і форматування
- Низький загальний відсоток покриття тестами, коли шляхи грошей і auth покриті
- Застарілі залежності без досяжної вразливості
- Відсутня документація — справді поширено, рідко вирішально, дешево виправляється
Якщо звіт про аудит неможливо переказати вашому інвесткомітету трьома реченнями, його окреслили як інженерну вправу, а не як інвестиційну.
Який вигляд має добрий результат
- Односторінкове резюме бізнес-мовою з чіткою загальною позицією щодо ризику
- Знахідки, впорядковані за наслідком, кожна з доказом, який команда цілі може перевірити
- Вартість усунення в інженеро-тижнях, щоб вона переводилась у гроші
- Рекомендований 90-денний технічний план після закриття
- Явний перелік того, що НЕ перевірялося, щоб ніхто не припускав покриття, якого не було
Зафіксуйте очікувані докази в завданні
Покупець має простежити важливий висновок до джерела та зрозуміти вартість реагування.
- Назвіть репозиторій, commit, середовище й дату перевірки.
- Запросіть приклади, уражені процеси та припущення щодо зусиль.
- Вимагайте перелік виключень і можливість повторної перевірки.
Часті запитання
Скільки триває аудит коду перед інвестицією?
Три-десять робочих днів для більшості цілей seed і Series A. Фінтех, healthtech або незвично великі кодові бази тривають довше. Після двох тижнів ви зазвичай купуєте деталі, а не рішення.
Чи знатиме стартап, що ми його аудитуємо?
Так — змістовний аудит потребує доступу до репозиторію і часу інженерів, тож це спільний процес. Серйозні цілі цього очікують і зазвичай почуваються спокійно; незвичний опір сам по собі вартий нотатки.
Чи можна аудитувати без доступу до вихідного коду?
Лише поверхово. Без репозиторію можна оцінити робочий продукт, публічний стан безпеки і сигнали команди, але не чистоту IP, справжню архітектуру чи придатність до підтримки — а це зазвичай і є знахідки, що мають значення.
Що робити, якщо аудит знайде серйозні проблеми?
Це успішний аудит, і він рідко зриває угоду. Більшість знахідок перетворюються на бюджет усунення, умову закриття, траншеве фінансування або коригування оцінки. Справжній провал — виявити ті самі проблеми на шостому місяці, коли вони коштують значно дорожче.
Чи потрібна аудитору копія продакшен-бази?
Не за замовчуванням. Надавайте синтетичні або належно очищені дані й обмежений доступ. Розширюйте його лише для конкретного питання без менш ризикової альтернативи.
Потрібен аудит до переказу коштів?
Знахідки, впорядковані за бізнес-наслідком, усунення оцінене в інженеро-тижнях, доставка менш ніж за два тижні.
Читати далі за темою
Технічний due diligence для інвесторів: повний посібник
Технічний due diligence — це не code review. Це відповідь на одне питання: скільки коштуватиме привести цю технологію туди, де її потребує інвестиційна теза?
Технічний аудит MVP: що ми перевіряємо в перші 48 годин
Більшість аудитів MVP закінчуються документом. Корисний закінчується рішеннями: що горить, що може почекати і скільки коштує виправлення.