Технічний due diligence: десять запитань перед інвестицією
Інвестори добре читають фінанси й ринки. Кодова база зазвичай лишається чорною скринькою, доки щось не зламається після закриття раунду. Десять запитань, які відкривають скриньку без потреби самому читати код.
У типовій угоді продукт показують на демо, ринок — у моделі, команду — на співбесідах. Софту, який має витягнути наступні два роки зростання, часто дістається одне запитання — «технічно все надійно?» — і впевнене «так». Технічний due diligence існує тому, що це «так» щире і часто хибне: не через нечесність, а тому, що засновники рідко бачать власну систему ззовні.
Запитання нижче не вимагають читати код. Їх ставлять команді засновників і звіряють із доказами: репозиторієм, дашбордом, рахунком. Розмиті чи суперечливі відповіді — це і є висновок.
Власність і контроль
- Кому належать код, домен, хмарні акаунти й сторінки в магазинах застосунків — компанії чи особисто засновнику або підряднику?
- Чи зможе компанія завтра задеплоїти продукт, якщо двоє найдосвідченіших інженерів підуть?
Звучить адміністративно, але саме на ці запитання найчастіше відповідають погано. Репозиторій в особистому акаунті фрилансера чи продакшен, що працює на кредитці засновника, — це предмет переговорів до раунду і криза після нього.
Поставка
- Як часто код потрапляє в продакшен і як — через пайплайн чи хтось вручну запускає команди?
- Коли реліз щось ламає, як його відкочують і коли це було востаннє?
- Чи є staging-середовище, достатньо схоже на продакшен, щоб йому довіряти?
Частота релізів — один із найчесніших сигналів. Команда, яка випускає невеликі зміни кілька разів на тиждень, зазвичай може дешево змінити напрям. Команда, яка випускає раз на місяць у нервовий день-подію, витратить непропорційну частку нового бюджету на те, щоб нічого не зламалося.
Надійність і дані
- Чи є резервні копії продакшен-даних і чи хтось колись із них відновлювався?
- Що сталося під час останньої аварії і як команда про неї дізналася?
- Які персональні чи регульовані дані зберігає продукт і хто має до них доступ?
Вартість, масштаб і план
- Скільки коштує інфраструктура на місяць і як ця сума змінюється з ростом кількості користувачів?
- Які частини системи доведеться переробити, щоб виконати роадмап, під який залучається цей раунд?
Багато продуктів мають цілком здорову юніт-економіку на папері й рахунок за інфраструктуру, який на практиці росте швидше за виручку, — особливо там, де є великі мовні моделі чи відео. Попросити шість останніх щомісячних рахунків поруч із кількістю користувачів за ті самі місяці — п'ять хвилин, які часто змінюють модель.
А ще в кожній системі є частини, збудовані, щоб дійти до перших клієнтів, і вони не переживуть наступну сотню. Це нормально і не тривожний сигнал. Тривожний сигнал — роадмап, у якому на це немає бюджету, або команда, яка цього не помітила.
Як читати відповіді
Мало хто на етапі seed чи Series A добре відповідає на всі десять — і не повинен. Важливо, чи команда знає свої слабкі місця і чи має реалістичний, оцінений у грошах план. Засновник, який каже «деплой у нас ручний, і ось коли ми це виправимо», — краща ставка, ніж той, у кого все гаразд. Незалежний огляд потрібен, щоб відрізнити одного від іншого до переказу грошей, а не після.