Продаєте компанію? Що знайде технічний due diligence покупця і що виправити насамперед

Ви вирішили продавати компанію або можете вирішити за рік-два. У якийсь момент покупець надішле фахівців, які прочитають ваш код, договори й акаунти. Розповідаємо, що вони зазвичай знаходять, як кожна знахідка впливає на угоду, що ви можете чесно перевірити самі, де потрібні фахівці і чому сильний пітч-дек іде після всього цього.

КОРОТКО

Що насправді перевіряє покупець

Технічний due diligence покупця відповідає на п'ять запитань: кому юридично належать код і акаунти, чого вимагають від вас відкриті ліцензії, наскільки вразлива система, що відбувалося з її даними і скільки всього тримається на одній-двох людях. Більшість знахідок не скасовує угоду, а змінює її умови: знижується ціна, зростає ескроу, з'являються роботи до закриття або перенесення строків.

Головна перевага продавця полягає в тому, що в нього є час, і не варто плутати це з легкістю. У місяці перед продажем та сама робота обходиться набагато дешевше, ніж посеред угоди, на тлі дедлайну, під наглядом аудитора і коштом юристів з обох сторін. Але перевірки з цієї статті лише показують власнику, куди дивитися. Для перевірки, якій повірить покупець, потрібні люди з великим досвідом у M&A, іноді з ліцензіями, і аналітичний відділ, який розбирається в чужому коді від і до, і ця робота не безкоштовна і не швидка: ідеальна підготовка до продажу займає близько року, а від чотирьох до шести місяців це мінімум для невеликого продукту й угоди на кілька мільйонів. А вінець усього цього сильний пітч-дек, який обґрунтує ціну.

Ми дивимося на це очима тих, хто проводить такі перевірки. У Peretz Agency технічний due diligence веде Валерія Чумаченко, яка має понад десять років досвіду в технологічних M&A, а код, хостинг і дані перевіряють наші розробники. Версія цього списку для покупця є у статті Як провести аудит сайту чи цифрового продукту перед покупкою. Тут ми розвертаємо її і запитуємо, з чого почати вам, власнику.

Майже будь-яку знахідку дешевше виправити, поки на вас ніхто не чекає.

МЕХАНІКА

Як знахідка доходить до ціни

Найвідоміший приклад настільки великий, що описаний у публічному документі. У лютому 2017 року, коли Yahoo вже розкрила свої витоки даних, Verizon і Yahoo домовилися знизити ціну на $350 млн, і угода стала коштувати близько $4,48 млрд. Крім того, Yahoo залишилася відповідальною за половину частини грошових зобов'язань, пов'язаних із цими витоками, уже після закриття.

Marriott показує зворотний порядок, коли знахідка приходить після угоди. Атака на системи Starwood почалася у 2014 році, до пропозиції Marriott про купівлю, і залишалася непоміченою до вересня 2018 року. Британський регулятор оштрафував Marriott на £18,4 млн, і успадкована проблема стала його власною.

Це гіганти, але механіка працює і на менших масштабах. У приватній угоді середнього розміру сумнів зазвичай перетворюється на утримані гроші. Дослідження SRS Acquiom за 2026 рік охоплює понад 2 300 угод із приватними компаніями, переважно з покупцями зі США. За оглядом юридичної фірми Fasken, медіана всіх ескроу у 2025 році становила 10% вартості угоди, а за страхування запевнень і гарантій 2,8%. Середній розмір ескроу зріс порівняно з 2024 роком. У тому ж огляді сказано, що у 22% угод продавець не давав запевнень щодо кібербезпеки, тоді як у 2024 році таких було 5%. Продавці стали обережнішими з обіцянками, а покупець, який обіцянки не отримав, має привід дивитися уважніше.

Ось як, на нашу думку, звичайні знахідки впливають на угоду. Реальні умови завжди визначаються переговорами, тому вважайте таблицю нашою оцінкою, а не ринковим стандартом:

ПРАВА НА КОД

Оплатити код ще не означає володіти ним

Ця знахідка дивує власників найбільше: рахунки ж оплачені. Якщо покупець працює за законами США, передача авторських прав недійсна без письмового документа, підписаного власником прав. Код працівника в межах його роботи належить роботодавцю, але для зовнішніх розробників правила інші.

Циркуляр 30 Бюро авторських прав США ставить чотири умови, за яких замовлена робота вважається службовою: вона входить до одного з дев'яти перелічених видів, є письмовий договір, договір прямо це обумовлює, і його підписали всі сторони. У переліку переклади, збірники, тести й атласи. Звичайний код застосунку погано вписується в цей список, тому в договори, як правило, додають пряму передачу прав.

В Україні частину коду часто пишуть ФОПи й зовнішні підрядники, а покупець може бути іноземним, тож перевіряти доведеться за правом, яке він вимагатиме. Шукайте в кожному договорі пряму передачу майнових прав на результат із зазначенням обсягу, а не лише акт виконаних робіт. Наші слова тут не замінять думки юриста: ми інженери, а не адвокати, тому покажіть цей розділ своєму юристові з угоди.

Прогалини зазвичай трапляються в одних і тих самих місцях:

• Код, який засновник написав до створення компанії і який компанія формально ніколи не отримувала.
• Перший фрилансер, з яким домовилися усно або кількома рядками в листі.
• Договір з агентством, де нічого не сказано про права на результат.
• Власна бібліотека підрядника, що потрапила у ваш продукт без письмових умов.

Є перший погляд, який можна кинути вже сьогодні, і він лише підкаже, де ставити запитання. У репозиторії команда git shortlog -sne --all виводить усіх, хто надсилав код, з кількістю комітів та адресою пошти. Покладіть цей список поруч із трудовими договорами і договорами з підрядниками. Кожне ім'я без підписаного документа стає запитанням до юриста. Git не покаже код, завантажений одним великим комітом, і працівників агентства під спільним акаунтом, тому про них запитайте окремо. Чистий список сам собою нічого не доводить: з'ясувати, хто що писав, входить у роботу фахівців.

Робіть це, поки колишні підрядники відповідають на листи і ви з ними в добрих стосунках. Людина, яка дізнається про продаж у той момент, коли в неї просять підпис, отримує важіль тиску, а дедлайн його лише посилює.

Далі йдуть акаунти, і з ними простіше. Домен на ім'я засновника, аналітика на акаунті колишнього працівника, код у репозиторії агентства переводяться без особливих складнощів, поки ніхто не квапить. Про це ми писали у статтях Більшість компаній не володіють своїм сайтом і Чим ти реально володієш, а що орендуєш. У наших проєктах код, команди розгортання і порядок відкату передаються клієнту за договором: рішення, побудоване навколо бізнесу, має належати цьому бізнесу.

Рахунок доводить, що ви заплатили. Володіння доводить лише підписаний документ.

КОД ВІД ШІ

Нове запитання на переговорах

Зазвичай у договорі покупець просить підтвердити, що компанії належить її код. Підписати таку фразу стало складніше. У звіті Бюро авторських прав США за січень 2025 року сказано, що за нинішніх технологій самі лише промпти не роблять користувача автором результату. Захист залишається там, де ШІ є інструментом, а виразні елементи визначає людина, і ШІ-матеріал усередині більшої людської роботи не позбавляє захисту її людську частину. Рішення ухвалюються в кожному випадку окремо.

Правила для цілого репозиторію у звіті немає, і сьогодні ніхто не скаже, яка частка згенерованого коду безпечна. Зате можна зберегти докази того, що рішення ухвалювали люди: письмову політику щодо дозволених інструментів, історію рев'ю, де розробники вибирали, змінювали і відхиляли запропоноване, і позначку про модулі, згенеровані майже без правок.

Друга половина запитання стосується ліцензій. У звіті Black Duck про ризики відкритого коду в M&A за 2026 рік сказано, що ШІ-асистенти дедалі частіше вставляють у код фрагменти чужого коду, а ліцензійні зобов'язання поширюються на фрагменти будь-якого розміру. Якщо першу версію вашого продукту зроблено переважно за допомогою ШІ і незабаром її дивитимуться інвестори, для цього в нас є оцінка MVP. Окреме запитання, чи справді «ШІ» з вашої презентації належить вам, розібрано у статті Проблема AI Wrapper.

ВІДКРИТИЙ КОД

Що напишуть у звіті аудиту

Покупці компаній із великою часткою софту часто платять зовнішній фірмі за перевірку коду, зокрема тому, що продавці, як правило, не передають код потенційним покупцям напряму. Аудитор бачить те, чого покупець не бачить. Black Duck продає такі аудити, тож зважайте на її інтерес і на те, що перевіряє вона переважно софтверні компанії. Дані охоплюють аудити з листопада 2024 до жовтня 2025 року:

За таких цифр сама знахідка не скандал: вона є майже в усіх. Продавцю шкодить інше: уперше почути про неї від аудитора покупця і не мати готової відповіді. Black Duck перелічує звичайні наслідки ліцензійних проблем: додатковий захист покупця, виправлення до закриття, ескроу, зниження ціни і перенесення строків.

Ще у звіті сказано, що 16% знайдених компонентів потребували глибшого аналізу, бо потрапили в код в обхід менеджерів пакетів: скопійовані теки постачальників, вставлені фрагменти, код від ШІ-асистентів. Саме їх ваша швидка перевірка і пропустить.

Вага конфлікту залежить від того, як бізнес заробляє. У звіті умови copyleft описано як проблему компаній, що розповсюджують софт, тому про завантажуваний продукт і про сайт, який ви лише розміщуєте в себе, юрист може сказати зовсім різне. Почніть зі списку. У PHP-проєкті команда composer licenses виводить усі залежності з їхніми ліцензіями, для npm є схожі інструменти. Приберіть невикористане, замініть конфліктне і запишіть, чому решта допустима. Така команда бачить лише оголошені залежності й не впіймає скопійований код, про який ішлося вище. Для цього потрібні спеціальні сканери і люди, які вміють читати їхні результати.

Щодо 97%, нуля відомих вразливостей ніхто не чекає. Покупцю важливо бачити, що хтось оновлює систему за графіком і може показати кілька останніх оновлень. З чого почати, ми розповіли у статті про те, як насправді зламують сайти бізнесу.

СТАРИЙ СТЕК

Стара версія перетворюється на цифру

Непідтримуваний фреймворк рідко зупиняє продаж. Він стає вирахуванням, і питання лише в тому, чия оцінка буде використана. Станом на листопад 2026 року опубліковано такі дати закінчення виправлень безпеки:

Якщо залишити це покупцю, його команда закладе запас в оцінку оновлення: системи вона не знає, а ризик несе сама. Якщо прийти зі своєю цифрою, розмова змінюється: ось поточна версія, ось що заважає наступній, ось оцінка розробника. Ще краще завершити оновлення заздалегідь. Метод тут такий: послідовно проходити версії на закритій копії, як у статтях Шість версій Laravel за три дні та Оновлення старого сайту на Laravel чи PHP у 2026 році. Не вважайте ці три дні нормою: ту систему команда знала добре, а чужий код без тестів може зайняти місяці. Практичний бік описано на сторінці послуги Модернізація сайту.

З цієї ж логіки випливає застереження. На наш погляд, місяці перед продажем поганий час, щоб починати повне переписування. Стару систему з відомою вартістю оновлення легко оцінити. Незавершена заміна поруч із нею змушує покупця оцінювати дві системи і план, і така перевірка зазвичай іде важко. Прихований технічний борг пояснити простіше, ніж незавершену міграцію.

МИНУЛІ ІНЦИДЕНТИ

Що ви не можете довести

Чекайте простих запитань. Чи були інциденти безпеки за останні роки? Чи повідомляли клієнтів? У кого сьогодні є доступ адміністратора? Коли хтось востаннє відновлював резервну копію і перевіряв результат? Найважча відповідь звучить як «здається, ні», адже компанія без логів не може показати, що нічого не сталося. Історія Marriott добре нагадує, як довго вторгнення може залишатися непоміченим.

Запишіть історію, поки є час: кожен відомий інцидент, що зробили, що змінилося потім. Як це розкривати, вирішить юрист, а на початок розмови у вас будуть факти. Перевірте і відновлення з копії, тому що неперевірена резервна копія залишається обіцянкою, яку ніхто не перевіряв.

Справжнім даним клієнтів нема чого робити в кімнаті даних. Покупець дізнається все потрібне зі структури, кількісних даних і знеособленої копії. Доступ перевіряльникам варто відкривати після підписання NDA і лише на читання, з цього починаються і наші перевірки. Запитайте юриста, чи дозволяє ваша політика конфіденційності передачу даних клієнтів новому власнику, тому що обіцянка, дана клієнтам, іде за даними.

КЛЮЧОВІ ЛЮДИ

Що живе у двох головах

Перевіряльник запитає, хто може розгорнути систему, хто знає, чому інтеграція з білінгом поводиться саме так, і що буде, якщо ця людина піде за місяць після закриття. Про діловий бік ми писали у статті Залежність від засновника: знижка, яку ніхто не вписує в презентацію. Технічний тест простий. Дайте розробнику, який ніколи не бачив системи, вашу документацію і попросіть підняти її, викотити невелику зміну та відновити копію. Усе, про що йому довелося запитати, і є список документів, яких бракує.

Якщо розробники у вас зовнішні, скажіть про це покупцю рано і покажіть договір, умови передачі та список доступів. Зовнішня команда сама собою норма. Справжня знахідка починається там, де єдина копія ключів лише в неї.

СПРАВЖНЯ ПЕРЕВІРКА

Що власник не перевірить сам

Усе написане вище може створити хибне відчуття безпеки, тому позначимо межу. Ваші команди й чек-листи знаходять те, що легко знайти. Вони дають список запитань, і покупець не прийме його як доказ.

Перевірці, яка витримає угоду, потрібні люди, які багато років працювали в M&A, іноді з ліцензіями, і аналітичний відділ, який розбирається в чужому коді від і до. Вони читають незнайому систему без її авторів, простежують крізь неї бізнес-логіку, відтворюють кожну знахідку і відділяють небезпечне від того, що просто виглядає старим. Потім перекладають усе це в наслідки, зрозумілі юристу й покупцю. Сканери та читання коду за допомогою ШІ прискорюють частину роботи, але не замінюють перевірки реальних доступів, реальних даних і реальних договорів.

Ваші розробники цього за вас не зроблять, хоч якими сильними вони були б. Вони написали систему або успадкували її, знають, куди не зазирали, а покупець не має причин вірити їм на слово.

Тверезо оцініть і витрати, і розділіть дві речі. Оцінка це зрозуміла робота зі зрозумілою ціною. Станом на листопад 2026 року сесія технічного due diligence коштує $1 500, а повна перевірка від $7 500, і її ціна залежить від масштабу бізнесу. Зазвичай вона займає від п'яти до десяти робочих днів і дає оцінку й вектор: над чим треба працювати, а над чим дуже глибоко. Часу потребуватимуть і від вашої команди: відкрити доступи, відповідати на запитання, шукати старі договори.

Справжня робота починається після цього, і чесної стартової ціни вона не має: вона залежить від продукту, і його спочатку треба побачити. В ідеалі на неї відводять рік, щоб компанію можна було грамотно подати інвесторам. Від чотирьох до шести місяців це мінімум, коли продукт досить невеликий, а угода коштує кілька мільйонів. Команди для цього часом потрібні зовсім не маленькі.

Тут ми маємо справжню перевагу. Peretz працює з великою базою перевірених розробників європейського й українського походження за адекватними цінами, тому, коли продукту на ці місяці потрібна велика виділена команда, ми можемо її зібрати.

ПІТЧ-ДЕК

Шар, який продає

Чиста система компанію не продає. Технічна робота захищає ціну, а обґрунтовує її пітч-дек. Назвете ви його презентацією, тизером чи інформаційним меморандумом, саме він вирішує, чи відкриє серйозний покупець вашу кімнату даних, і читають його, коли вас немає поруч.

Це вінець усього, про що йшлося вище. Пітч-деки ми робимо самі, і це наша улюблена частина роботи: якщо справа дійшла до дека, значить, продукт готовий.

Порядок тут важливий. Дек, написаний до перевірки, повний тверджень, які аудитори можуть спростувати, а одне спростоване твердження ставить під сумнів усі інші. Дек, написаний після, може прямо сказати, чим компанія володіє, що орендує, що відомо як проблема і скільки коштує її виправити. Така прямота виглядає як сила, бо команда покупця все одно знайде те саме.

Сильний дек добре робить кілька речей:

• Пояснює, чому ця компанія потрібна саме цьому покупцю, із причинами, а не довгим списком імен, як у статті Buyer Universe.
• Показує економіку, за яку платять покупці: регулярний дохід, утримання клієнтів і маржу, про це ми писали у статті про те, чому технологічні компанії оцінюють за іншою математикою.
• Показує бізнес, який працює, не спираючись на засновника як на операційну систему.
• Розповідає одну історію, вибудувану навколо того, як заробляє цей бізнес, і не виглядає шаблоном із вашим логотипом.

Потім звірте кожен технічний рядок із кімнатою даних. Якщо вони розходяться, покупець перестає вірити деку:

Перевірка захищає ціну. Пітч-дек її обґрунтовує.

Не йдіть до банкірів із деком, поки цю роботу не зроблено, про це наша стаття Перш ніж наймати банкірів, діагностуйте бізнес.

Як побудований сам дек, слайд за слайдом, і що має стояти за кожним твердженням, ми розібрали у статті «Як представити компанію покупцю так, щоб її історія витримала due diligence».

ГРАФІК

За рік до кімнати даних

Ідеальний строк це рік, і ось як ми б його розділили. Від чотирьох до шести місяців це мінімум для досить невеликого продукту й угоди на кілька мільйонів, тоді ті самі кроки йдуть щільніше. Послідовність від цього не змінюється, і пітч-дек іде останнім.

Якщо ви ще не вирішили, чи продавати взагалі, почніть на крок раніше з послуги Сесія готовності до продажу бізнесу: сесія коштує $1 500, програма підготовки від $5 000. Ідеться там про рішення власника щодо майбутнього, а не про оцінку вартості. Як і перевірка, вона дає оцінку й вектор, а самі виправлення це окрема робота. Якщо угода не планується і треба зрозуміти, чим компанія володіє і що орендує, підійде Аудит цифрового володіння та боргу: від $1 000, для великого бізнесу від $3 000.

Продавець може замовити і ту саму перевірку, що й покупець, через Сесію технічного due diligence за $1 500 або повну перевірку від $7 500. Ціну роботи, яка йде далі, ми можемо назвати лише після того, як побачимо продукт. Ви отримуєте письмовий звіт і сесію, на якій ми розбираємо його з вами та вашими консультантами. Кожна перевірка починається з того, як заробляє саме цей бізнес: конфлікт ліцензій, серйозний для компанії, що постачає софт, у власника магазину може виявитися приміткою.

ЗАПИТАННЯ

Поширені запитання

Що перевіряє технічний due diligence під час продажу компанії?

Код і його архітектуру, хостинг і доступи, власників домену, репозиторіїв та акаунтів, ліцензії, безпеку, дані й те, скільки знань про систему є лише в однієї-двох людей. Добрі перевіряльники починають із того, як бізнес заробляє, і лише потім відкривають код.

Чи варто продавцю проводити перевірку раніше за покупця?

Якщо технології становлять реальну частину вартості, так. Незалежна перевірка покаже, що знайде команда покупця, поки ще є час виправити це або підготувати чесне пояснення. Ідеально це рік, мінімум від чотирьох до шести місяців, тож залиште місце для виправлень.

Чи можна підготуватися до технічного due diligence самостійно?

Частково. Власник може зібрати договори, перевести акаунти і скласти список очевидних прогалин, і це заощадить час і гроші пізніше. Перевірці, якій повірить покупець, потрібні люди з великим досвідом у M&A, іноді з ліцензіями, і аналітичний відділ, який читає чужий код від і до. Це платна робота, і вона потребує часу.

Скільки часу займає підготовка компанії до продажу і скільки вона коштує?

Ідеально близько року. Від чотирьох до шести місяців це мінімум для невеликого продукту й угоди на кілька мільйонів, і команда часом потрібна велика. Оцінка займає від п'яти до десяти робочих днів: сесія коштує $1 500, повна перевірка від $7 500. Робота, яка йде далі, чесної стартової ціни не має, бо залежить від продукту.

Коли писати пітч-дек?

Після технічної перевірки й основних виправлень, щоб його твердження витримали аудиторів покупця. Кожен технічний рядок дека має вести до документа в кімнаті даних. Дек, написаний першим, зазвичай обіцяє те, що перевірка потім спростовує. Пітч-деки ми робимо самі, коли продукт готовий.

Чи можуть технічні знахідки зірвати угоду?

Можуть, хоча частіше вони змінюють умови: знижується ціна, зростає ескроу, з'являються умови до закриття або перенесення строків. Black Duck називає це звичайними наслідками ліцензійних проблем. Verizon і Yahoo знизили ціну на $350 млн після витоків і довели угоду до кінця.

Покупець побачить мій вихідний код?

Зазвичай не напряму. Black Duck зазначає, що продавці, як правило, не передають код потенційним покупцям, тому його дивляться незалежні аудитори під NDA і передають покупцю висновки. Умови доступу погодьте з юристом до того, як хтось отримає копію.

Що робити, якщо колишнього підрядника не знайти або він не підписує?

Рано повідомити юриста. Варіанти залежать від частки його коду та умов договору: новий договір, переписування цієї частини або розкриття проблеми з окремим захистом для покупця. Якщо ви знайшли це самі, у вас є час вибрати.

Чи є проблемою код, написаний за допомогою ШІ, під час продажу?

Запитання він викликати може, але перешкодою для угоди сам собою не стає. Бюро авторських прав США вважає, що самі промпти авторства не дають, а добір і правка людиною можуть бути захищені. Ведіть політику щодо інструментів та історію рев'ю і перевіряйте згенерований код на ліцензії, як будь-який інший.

Джерела

• Пресреліз Yahoo і Verizon про нові умови угоди, документ SEC, 21 лютого 2017
• Black Duck: 2026 Open Source Risk in M&A by the Numbers
• Бюро авторських прав США: Circular 30, Works Made for Hire
• Бюро авторських прав США: Copyright and Artificial Intelligence, Part 2, січень 2025
• Fasken: висновки з дослідження SRS Acquiom про умови угод за 2026 рік, 7 травня 2026