Технически due diligence за инвеститори: пълното ръководство

Техническият due diligence не е code review. Той е отговор на един въпрос: колко ще струва тази технология да стигне там, където инвестиционната теза я иска?

Повечето технически due diligence произвеждат документ, който никой не използва. Изброява фреймуърци, брои тестове, отбелязва, че документацията може да е по-добра — а после сделката се случва или не по съвсем други причини. Това пропилява реална възможност рискът да получи цена.

Полезният технически due diligence отговаря на три въпроса на бизнес език: може ли тази технология да понесе плана, който финансирате, колко ще струва затварянето на пропуските и кои рискове могат да унищожат стойност, а не просто да я забавят.

За какво служи наистина техническият due diligence

Рисковият инвеститор не купува кодова база. Купува теза: този екип ще достигне този мащаб за това време. Технологията има значение само там, където прави тезата по-вероятна или по-малко вероятна.

Петте области, които имат значение

1. Архитектура и запас за мащабиране

Всяка система има таван. Въпросът е къде е спрямо плана и колко скъпо е вдигането му. Монолит, който обслужва спокойно 100 000 потребители, не е констатация; монолит с една-единствена master база за запис и план за растеж до 10 милиона — е.

• Единичните точки на отказ — и дали екипът знае кои са те
• Слоят на данните — обикновено истинският таван и най-скъпото за промяна по-късно
• Дали натоварването изобщо е тествано, или мащабирането се предполага
• Крива на облачните разходи: издържа ли unit economics 10×, или инфраструктурата изяжда маржа?

2. Цялост на парите и данните

За всяка компания, която докосва плащания, салда или регулирани данни, това е областта с най-висока цена на грешката — и най-често пропусканата, защото проверката ѝ изисква експертиза в областта.

• Извежда ли се салдото от неизменен журнал, или е променливо число, което кодът може да презапише?
• Идемпотентност по платежните пътища и уебхуците — може ли повторен опит да задължи два пъти?
• Парите се пазят като цели числа в минорни единици, никога като float
• Равнение: би ли се засякло разминаване вътрешно, или от клиент?

3. Експозиция по сигурност и съответствие

Констатациите по сигурност имат смисъл само обвързани с последица. «Зависимостите са остарели» е шум. «Неавтентикиран ендпойнт връща записи на други наематели» е клауза в сделката.

• Оторизация, наложена на сървъра при всяка заявка, а не скрита в интерфейса
• Multi-tenant изолация — най-честата сериозна констатация в B2B SaaS
• Управление на тайни и дали идентификационни данни стоят в git историята
• Какви регулирани данни се съхраняват — и дали изобщо трябва
• Разстояние до сертификацията, която изисква go-to-market (SOC 2, ISO 27001, PCI DSS)

4. Способност за доставяне

Това предсказва следващите две години по-добре от текущата кодова база. Посредствена кодова база със силна дисциплина на доставяне се подобрява. Елегантна кодова база без способност да пуска безопасно — не.

• Честота на разгръщанията и време за доставяне на малка промяна
• Дали rollback е упражнявана рутина или теория
• Покритие с тестове по пътищата, които имат значение (пари, auth), а не глобален процент
• Откриване на инциденти: намират ли проблемите преди клиентите?

5. Риск от екипа и ключови хора

• Bus factor: колко души разбират критичните подсистеми — ако отговорът е един, това е риск за сделката
• Дали знанието съществува извън главите
• Зависимост от външни изпълнители по основното IP и дали прехвърлянето на права е чисто
• Реализъм на плана за наемане спрямо финансираната пътна карта

Червени флагове, подредени по реална цена

Целта на техническия due diligence не е да намери причина да се откажете. Целта е да знаете точно какво купувате, за да го отразят цената и планът.

Как констатациите стават условия по сделката

1. Бюджет за отстраняване — количествено остойностяване на поправките и явното им финансиране в рунда, вместо откриване на шестия месец
2. Условия по етапи — освобождаване на транш, обвързано с конкретно отстраняване (типично, когато пропуски по съответствие блокират go-to-market)
3. Корекция на оценката — където отстраняването е голямо спрямо рунда
4. План след затваряне — 90-дневна техническа пътна карта, договорена преди превода, а не импровизирана след него

Колко време отнема

По-дълго не значи по-добре. След две седмици повечето ангажименти произвеждат подробности вместо решения — освен ако областта наистина го изисква, като плащания или регулирани здравни данни.

Определете обхвата преди събиране на документи

Прегледът трябва да отразява инвестиционната теза. Уточнете въпроси, важни системи и доказателства преди оценка на риска.

1. Свържете очаквания растеж с капацитет и оперативни разходи.
2. Разделете твърдения, проверени тестове и недостъпни данни.
3. Разграничете условия за сделката и финансиран последващ план.

• одит на код преди инвестиция →
• технически due diligence за инвеститори →