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