Чекліст корисний лише тоді, коли до кожного пункту прикріплений наслідок. Цей упорядкований за тим, що справді змінює угоду.
Власність і залежності
Продукт і робота
Виправлення й рішення
Використовуйте це як робочий документ під час перевірки. Кожен розділ каже, що запитати, що перевірити і — головне — що погана відповідь означає комерційно. Пункти впорядковані за ціною помилки, а не за зручністю перевірки.
Перед стартом: що запитувати
- Доступ на читання до всіх репозиторіїв, включно з infrastructure-as-code
- Повна історія комітів (не сплющений знімок — історія показує, хто це справді збудував і як швидко)
- Огляд архітектури з інженером, який її будував, 1-2 години
- Доступ до трекера задач і будь-яких записів про інциденти
- Перелік сторонніх сервісів і їхніх договірних умов
- Договори з підрядниками і документи про передання прав на IP
Розділ 1 — Цілісність грошей і даних (рівень угоди)
| Перевірка | Погана відповідь означає |
|---|---|
| Баланси виводяться з журналу append-only? | Гроші можуть бути беззвучно неправильні й невідновні — фінансуйте усунення або виходьте |
| Ключі ідемпотентності на кожному платіжному шляху? | Повтори можуть списати двічі; втрати можливо вже існують непоміченими |
| Гроші зберігаються цілими числами в мінорних одиницях? | Арифметика з плаваючою комою накопичує похибку в кожній транзакції |
| Звірка з даними сетлменту провайдера? | Розбіжності спливають через скарги клієнтів |
| Незмінний аудиторський слід включно з діями адмінів? | Неможливо відповісти регулятору чи у спорі |
Розділ 2 — Безпека і мультитенантність (рівень угоди)
- Авторизація перевіряється на сервері при кожному запиті, а не приховуванням елементів інтерфейсу
- Ізоляція орендарів підтверджена тестом, а не припущена з читання коду
- Секрети в менеджері, відсутні в історії git (перевіряйте історію, не лише HEAD)
- Які регульовані дані зберігаються, де і чи потрібно це взагалі
- Відстань до сертифікації, якої вимагає go-to-market (SOC 2, ISO 27001, PCI DSS)
Розділ 3 — Власність і юридичне (рівень угоди)
- Підписане передання прав на IP від кожного підрядника і засновника
- Огляд ліцензій open source — копілефт-забруднення в пропрієтарному продукті
- Код, скопійований у попередніх роботодавців (питайте прямо; таке буває)
- Залежність від вендора: що зламається, якщо ключовий провайдер змінить ціни або закриється
Розділ 4 — Архітектура і масштаб (високий)
- Де система ламається за зростання з фінансової моделі — конкретне число, а не заспокоєння
- Стеля шару даних: єдиний master на запис, необмежені запити, покриття індексами під реальні патерни
- Ізоляція відмов: чи переростає одна повільна залежність у повну аварію
- Крива витрат на інфраструктуру на 10× — чи виживає юніт-економіка
- Архітектура відповідає розміру команди (розподілені системи в малій команді — це витрата, а не заслуга)
Розділ 5 — Спроможність доставляти (високий)
| Сигнал | Здорово | Тривожно |
|---|---|---|
| Частота розгортань | Кілька разів на тиждень | Раз на місяць, за розкладом, зі страхом |
| Час доставки малої зміни | Години до одного дня | Тижні |
| Відкат | Одна команда, відпрацьована | Ніколи не тестувався |
| Виявлення інцидентів | Внутрішній моніторинг | Повідомлення клієнтів |
| Тести на шляхах грошей/auth | Наявні | Відсутні незалежно від загального покриття |
Розділ 6 — Команда і ризик ключової особи (високий)
- Bus factor кожної критичної підсистеми — якщо десь він дорівнює 1, це ризик угоди, що потребує пом'якшення
- Чи існують знання письмово, чи лише в головах
- Ризик утримання: чия втрата протягом 12 місяців була б катастрофічною
- Реалістичність плану найму, який передбачає роадмап
Оцінювання: наслідок, а не смак
Оцінюйте кожну знахідку за тим, що станеться, якщо її не виправити, і нехай це визначає реакцію в угоді:
- Рівень угоди — цілісність грошей, витік даних, незрозумілі права на IP. Умова закриття або профінансоване усунення.
- Високий — стеля масштабування нижча за план, залежність від однієї людини, немає безпеки розгортань. Закладено у 90-денний план після закриття.
- Середній — накопичувальний борг, що сповільнює доставку. Зафіксувати і спостерігати.
- Шум — стиль, уподобання щодо фреймворку, обсяг документації. Повністю виключити зі звіту.
Якщо знахідку не можна прив'язати до грошей, часу чи юридичного ризику, їй не місце в інвестиційному меморандумі.
На чому наполягати у фінальному звіті
- Односторінкове резюме, за яким може діяти нетехнічний партнер
- Кожна знахідка з доказом, який команда цілі може перевірити самостійно
- Оцінки усунення в інженеро-тижнях, щоб вони переводились у гроші
- Явне зазначення того, що НЕ перевірялося — щоб ніхто не припускав покриття, якого не було
Перетворіть чекліст на основу рішення
Кожна відповідь має посилатися на докази й наслідки для угоди. Погодьте межі, доступи й питання до збору документів. Розділіть перевірені знахідки, заяви керівництва та відсутні матеріали. Порожня клітинка не доводить низький ризик.
| Зробіть рішення вимірюваним | Які докази погодити до початку |
|---|---|
| Власність і залежності | Запросіть історію репозиторію, угоди з розробниками й перелік залежностей. Юридичні права перевіряє правник. |
| Продукт і робота | Пройдіть важливий сценарій, перевірте розгортання й відновлення, зіставте архітектуру з припущеннями зростання. |
| Виправлення й рішення | Додайте відповідального, зусилля, залежності й перевірку. Відокремте умови до закриття угоди від подальшого плану. |
Звіт визначає перевірене, невідоме й можливі наслідки. Сам перегляд документів не підтверджує дієвість контролів у продакшені; технічний огляд не є юридичною сертифікацією.
Часті запитання
Що має входити до чекліста технічного due diligence?
Шість зон у порядку наслідку: цілісність грошей і даних, безпека та ізоляція орендарів, права на IP, архітектура і запас для масштабування, спроможність доставляти і ризик ключової особи. Кожен пункт має мати заявлений комерційний наслідок — чекліст без наслідків породжує звіти, за якими ніхто не діє.
Який пункт пропускають найчастіше?
Передання прав на IP від підрядників. Це не технічне питання, тож технічні рецензенти його пропускають, а юристи припускають, що інженерія його покрила. До того ж воно має найдовший строк виправлення — саме тому перевіряти його треба в перші дні, а не в останні.
Чи можуть засновники користуватися цим чеклістом самі?
Так, і перед раундом це гарна ідея. Знахідки, які ви виявляєте самі, стають планом усунення, який контролюєте ви; ті самі знахідки, виявлені радником інвестора, стають переговорною позицією проти вас.
Хочете, щоб це провів той, хто робить це щотижня?
Ми віддаємо diligence зі знахідками, впорядкованими за бізнес-наслідком, і усуненням, оціненим в інженеро-тижнях.
Читати далі за темою
Технічний due diligence для інвесторів: повний посібник
Технічний due diligence — це не code review. Це відповідь на одне питання: скільки коштуватиме привести цю технологію туди, де її потребує інвестиційна теза?
Що насправді шукають венчурні інвестори в технічному due diligence
Інвестори не ставлять оцінку вашому коду. Вони оцінюють ризик того, що технологія зупинить план, який вони фінансують — і засновники, які це розуміють, готуються зовсім інакше.