Инвеститорите не оценяват кода ви. Те остойностяват риска технологията да спре плана, който финансират — а основателите, които разбират това, се подготвят съвсем различно.
Основателите, подготвящи се за технически due diligence, често лъскат грешните неща — подреждат код, пишат документация, която никой не е искал, тревожат се за избора на фреймуърк. Инвеститорите задават съвсем друг въпрос: какво може да се обърка откъм технология и да попречи на компанията да достигне етапите от плана?
Четирите неща, които наистина се оценяват
1. Мащабира ли се до плана (а не до безкрайност)
Никой не очаква от компания на Series A архитектурата на Google. Въпросът е по-тесен: издържа ли системата конкретния растеж от модела и ако не, колко струва вдигането на този таван? Ясен, остойностен отговор е силен сигнал. «Би трябвало да е наред» не е.
2. Риск от ключов човек
Често най-решаващата констатация — и тази, която основателите най-малко очакват. Ако един инженер държи цялото критично знание, инвестицията носи риск, който няма нищо общо с качеството на кода. Инвеститорите питат директно: кой друг би могъл да оперира тази система следващата седмица, ако този човек си тръгне?
3. Дали технологията наистина е ваша
- Работа на изпълнители без подписано прехвърляне на IP — правен проблем, който може да забави или убие приключването
- Лицензионно замърсяване от open source в затворен продукт
- Критична зависимост от доставчик, който може да промени цените, да ограничи или да изчезне
- Каква част от «собствената технология» е тънък слой върху чуждо API
4. Способност за доставяне
Това предсказва следващите две години по-добре от текущото състояние на кодовата база. Инвеститорите гледат честотата на разгръщанията, как промените стигат до продукция, дали инцидентите се засичат вътрешно и дали екипът може да поеме наемането, което планът предполага.
Как да се подготвите (в четирите седмици преди)
- Напишете честен регистър на техническите рискове — какво е слабо, какво блокира, колко струва отстраняването. Да го подадете сами се чете като компетентност; да бъдете хванати да го криете — обратното.
- Първо поправете всичко от категорията пари и данни — точно тези констатации стават условия по сделката.
- Затворете празнотите по IP: подписани прехвърляния от всеки изпълнител, преглед на лицензите на зависимостите.
- Видимо намалете bus factor — включете още някой в критичната система, напишете регистъра на архитектурните решения.
- Подгответе ясен преглед на архитектурата: какво е, защо, къде се чупи, какъв е планът.
Как констатациите стават условия
| Констатация | Типичен изход |
|---|---|
| Парите може да са беззвучно грешни (няма журнал) | Отстраняване, финансирано в рунда; понякога на траншове |
| Изтичане на данни между наематели | Условие за приключване — да се поправи преди освобождаване на средствата |
| Неясно IP от изпълнители | Изисква се правно уреждане преди приключване |
| Bus factor единица | Пакет за задържане или ангажимент за наемане в плана |
| Ръчно разгръщане, без rollback | Остойностено в 90-дневния план след приключване |
| Остаряващи зависимости, оскъдна документация | Отбелязано, без последица |
Инвеститорите не очакват перфектна система. Очакват основател, който знае точно кои части са несъвършени и колко струва поправката им.
Свържете всяка констатация с решение
Покажете кои допускания остават надеждни и какво променя плана. Представяйте несигурност заедно с усилието за поправка.
- Посочете бизнес допускането и проверените доказателства.
- Опишете последствие, несигурност и зависимости на отстраняването.
- Разделете условие за сделка, бюджетна позиция и приет риск.
Често задавани въпроси
Колко време отнема техническият due diligence на инвеститор?
Обикновено една до две седмици за Series A, повече за финтех, healthtech или необичайно големи системи. Обикновено включва достъп до хранилището, преглед на архитектурата и интервюта с инженерния екип.
Трябва ли основателите да направят собствен технически одит преди набирането?
Често да. Констатациите, които извадите сами, се превръщат в план за отстраняване, който вие контролирате; същите констатации, извадени от съветника на инвеститора, се превръщат в преговорна позиция срещу вас. Цената на одит преди рунда е малка спрямо влиянието върху оценката, което може да предотврати.
Може ли разхвърлян код да убие рунда ни?
Рядко сам по себе си. Сделките се влияят от констатации с последица — цялост на парите, експозиция по сигурност, неясна собственост върху IP и риск от ключов човек. Инвеститорите са виждали несъвършенствата на всяка кодова база; притеснява ги екип, който не може точно да опише собствените си рискове.
Достатъчна ли е една техническа оценка?
Не. Тя обобщава, но скрива обхват и несигурност. Добавете важни констатации, недостъпни доказателства и допускания зад оценките.
Скоро набирате?
Правим diligence преди вашия инвеститор — за да дойдат констатациите с вашия план за отстраняване в комплект.
Още по темата
Технически due diligence за инвеститори: пълното ръководство
Техническият due diligence не е code review. Той е отговор на един въпрос: колко ще струва тази технология да стигне там, където инвестиционната теза я иска?
Одит на кода преди инвестиция: какво да поискате, преди да преведете
На път сте да купите дял от актив, който не сте огледали. Одитът на кода е този оглед — но само ако е очертан така, че да отговаря на инвестиционни, а не на инженерни въпроси.