Терміни для старту цифрового проєкту

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

Детальніше: Стратегічна сесія

CTO за підпискою це досвідчений технічний директор (CTO, chief technology officer), який працює на компанію неповний час: ухвалює рішення щодо стеку, архітектури, підрядників і найму та перевіряє роботу розробників, без витрат на штатного топменеджера. Формат підходить компаніям, які залежать від технологій, але ще не готові до CTO на повний день. Наша базова ціна від $3 500 на місяць, це приблизно один день на тиждень, з помісячною оплатою.

Детальніше: CTO за підпискою

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

Детальніше: Як працює Peretz Agency: послуги, процес і ціни

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

Детальніше: Метод Коломбо: як знайти справжню проблему бізнесу

Формулювання проблеми (problem statement) це короткий опис проблеми, яку має розв'язати продукт або проєкт, словами самих клієнтів і з підтвердженням, що за її розв'язання готові платити. Проєкти часто надходять із готовим рішенням, наприклад «нам потрібна CRM», хоча ніхто ще не визначив, що має змінитися в бізнесі. Без такого формулювання команда може зробити швидший і сучасніший сайт, який нічого не змінить, бо власникові насправді потрібно було більше записів на прийом, а не гарна головна сторінка.

Детальніше: Архітектура MVP: що маркетинг винен продукту до запуску

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

Детальніше: Диджиталізація бізнесу в Кіркленді: що це означає насправді (і коли вона потрібна)

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

Детальніше: Софт має підходити бізнесу

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

Детальніше: Ми проєктуємо не для ідеальних сценаріїв, а для реальності

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

Детальніше: Неправильний хід. Правильний хід. Запізно.

Дорожня карта продукту (roadmap) це план того, що і в якому порядку буде створено за певний період, прив'язаний до цілей бізнесу, а не просто перелік функцій. Стратегією, пріоритетами й самою дорожньою картою керує продуктовий менеджмент, а продуктовий дизайн вирішує, чим кожен запланований пункт має стати для користувачів. Карту переглядають, коли команда дізнається нове; наша стратегічна сесія завершується дорожньою картою перших кроків на 90 днів.

Детальніше: Product Design проти UX/UI: де реально починається цифровий продукт?

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

Детальніше: Стратегічна сесія

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

Детальніше: Неправильний хід. Правильний хід. Запізно.

Discovery-фаза це платний етап перед розробкою, на якому ідея перетворюється на документи, на які можна спертися в ціні й термінах: вимоги, сценарії користувачів, клікабельний прототип, архітектура, інтеграції, ризики та беклог з оцінкою. Вона потрібна, коли оцінки однієї й тієї самої ідеї в різних підрядників сильно розходяться. Наша discovery-фаза триває від двох до чотирьох тижнів і коштує від $4 000, а її документи написані так, щоб за ними могла працювати будь-яка команда.

Детальніше: Discovery-фаза проєкту

Product discovery це частина продуктового менеджменту, яка знімає найнебезпечнішу невизначеність щодо продукту, поки її ще дешево виправити: від питання до фактів, їх інтерпретації та рішення. Це спосіб роботи, а не воркшоп. Дослідження достатньо, коли команда може сказати, яку проблему розв'язує продукт, для кого, як її розв'язують сьогодні, які є обмеження й ризиковані припущення і чого не буде в першій версії. Не плутайте з product discovery в e-commerce, де так називають те, як покупці знаходять товари через пошук і фільтри.

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

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

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

Технічне дослідження (technical discovery) це частина discovery, у якій вивчають наявний технічний ландшафт: які системи вже працюють у компанії, де лежать дані, яка система є джерелом істини, які API та обмеження діють і що вигідніше: розробити, купити чи інтегрувати. Воно має впливати на продуктовий дизайн від самого початку, а не додаватися після того, як намальовано екрани. Наше архітектурне дослідження проходить сім етапів, перш ніж рекомендувати технологію: бізнес-проблема, припущення, клієнти, наявна система, вартість змін, точніші питання до ШІ і лише потім технологія.

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

Мапа припущень (assumption mapping) це техніка discovery, за якої команда записує свої переконання щодо користувачів, ринку й рішення та ранжує кожне за важливістю, невизначеністю і ціною помилки. Спершу досліджують фундаментальні й найменш підтверджені припущення. Метод відокремлює факти (поведінку, яку спостерігали, або дані) від припущень (у них вірять, але їх не показали) і гіпотез (їх ще треба перевірити), а просте питання «звідки ми це знаємо?» не дає мимохідній репліці стати вимогою.

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

Інтерв'ю з клієнтами (customer discovery) це розмови з потенційними користувачами про те, як вони дають раду проблемі сьогодні, які проводять до проєктування продукту. Питання стосуються останнього випадку, коли проблема виникла, а не того, чи користувалися б люди продуктом або чи платили б за нього: минула поведінка це факт, майбутній намір лише гіпотеза. Такі інтерв'ю часто показують, що таблиця, ланцюжок листів або чат у WhatsApp уже розв'язують частину проблеми так, як запропонований продукт ще не зрозумів.

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

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

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

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

Детальніше: MVP, це не мінімальний продукт. Це вартість входу.

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

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

Тест попиту (передзамовлення) це лендинг, який пропонує продукт до його появи й просить відвідувача про дію, що йому чогось коштує: внести депозит, оформити передзамовлення або вказати дані картки. Поріг успіху фіксують до запуску, а проблему описують словами самих клієнтів. Так перевіряють найчастішу причину провалу: за даними CB Insights, відсутність ринкової потреби названо у 42% розборів стартапів, що закрилися.

Детальніше: Landing page

Тест «фальшивих дверей» (fake door test) це експеримент, у якому пропонують функцію або продукт, яких ще немає, через кнопку, сторінку чи рекламу, щоб виміряти, скільки людей спробують ними скористатися. Тим, хто натиснув, повідомляють, що це скоро з'явиться, а частка кліків показує реальний, а не заявлений інтерес. Це один із найдешевших способів перевірити припущення без прототипу, поряд з інтерв'ю, таблицями й розмовами про ціну.

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

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

Детальніше: Product Discovery: що варто знати, перш ніж починати проєктувати?

Відповідність продукту ринку (product-market fit) це момент, коли продукт зустрічає реальний повторюваний попит на ринку, достатньо великому, щоб його підтримувати. Без неї маркетинг не виправляє слабкий продукт, а лише посилює його слабкість. Аналіз CB Insights щодо 385 стартапів, що закрилися, назвав невідповідність продукту ринку головною причиною в 43% випадків, а брак грошей зазвичай був уже наслідком.

Детальніше: MVP, це не мінімальний продукт. Це вартість входу.

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

Детальніше: Чому більшість ШІ-пілотів не доходить до продакшену і як довести свій до живої роботи

Технічне завдання (ТЗ) це документ, який описує, що і як має робити система: функції, ролі користувачів, інтеграції, дані та обмеження. Воно фіксує чиєсь поточне розуміння того, що треба створити, а не те, як насправді працює компанія, тому п'ять агенцій, оцінюючи одне ТЗ, оцінюють ті самі припущення. Довге ТЗ корисне, коли за ним стоїть дослідження; зі ШІ сьогодні легко написати вражаюче ТЗ, яке описує лише поверхню.

Детальніше: Як обрати вебстудію

Обсяг робіт (scope of work) це письмовий опис робіт проєкту з етапами, результатами, термінами й ціною, погоджений до початку роботи. Зміни в ньому погоджують до того, як їх роблять, а не після. Обсяг робіт має йти за бізнес-ціллю: проєкт можна виконати точно за договором і все одно не створити цінності, якщо в обсязі було описано не той результат.

Детальніше: Як працює Peretz Agency: послуги, процес і ціни

Розростання обсягу робіт (scope creep) це неконтрольоване зростання обсягу проєкту після початку роботи, зазвичай через дрібні додавання, кожне з яких здається розумним. Одна функція відкриває інтеграцію, інтеграція проблему з даними, а та структурну проблему, і за погодинної оплати ці витрати несе клієнт. Розростання через нерішучість відрізняється від розумної адаптації до нової інформації. У перевитратах часто звинувачують саме його, хоча звичайна причина прихований технічний борг.

Детальніше: Скільки коштує кастомний сайт у 2026 році?

Запит на зміну (change request) це формальний запит на зміну погодженого обсягу проєкту, який оцінюють і затверджують до виконання роботи. Він відокремлює нові рішення від дефектів: «кнопка оформлення замовлення не працює» це помилка, яку виправляють, а «переробити оформлення замовлення до запуску» це нове рішення зі своєю вартістю й термінами. Такий порядок зберігає передбачуваність бюджету й дати запуску.

Детальніше: Скільки насправді займає розробка e-commerce і що має робити клієнт

Оцінка проєкту це прогноз вартості й термінів проєкту на основі того, що відомо про його обсяг на цей момент. Дві агенції можуть назвати $40 000 і $100 000 за той самий бриф, бо оцінюють різні проєкти; цифра, названа без питань про процеси клієнта, відображає припущення, а не вимоги. Складний проєкт неможливо чесно оцінити після годинного дзвінка чи за PDF. Етап вебзастосунку готовий до оцінки, коли описано його користувачів, ролі та пов'язані системи.

Детальніше: Скільки коштує кастомний сайт у 2026 році?

Порівняння комерційних пропозицій це зведення пропозицій різних агенцій до одного обсягу робіт перед порівнянням цін. Пропозиції на $18 000, $65 000 і $190 000 щодо одного проєкту зазвичай описують три різні проєкти. Перевіряють, що входить у кожну: discovery, UX/UI, інформаційна архітектура, міграція, інтеграції, платежі, податки, доставка, SEO-міграція, аналітика, тестування, документація, навчання й підтримка після запуску; якщо команда велика, варто запитати, чим займатиметься кожен.

Детальніше: Чому кошториси на e-commerce розробку в Сіетлі коливаються від $25 до $300 на годину

Беклог продукту (backlog) це впорядкований перелік робіт, які ще належить зробити в продукті: функції, покращення, виправлення й технічні задачі, з найціннішими нагорі. Його переглядають, коли команда дізнається нове, і саме за ним вирішують, що ввійде в наступний реліз. Наша discovery-фаза завершується беклогом із бюджетом і термінами за етапами, а розробники на аутстафі беруть задачі з беклогу клієнта.

Детальніше: Розробка вебзастосунків і SaaS

Терміни проєкту це графік його етапів від старту до запуску, включно з роботами й рішеннями на боці клієнта. Для орієнтиру: магазин на готовій темі в хмарної платформи роблять за тижні, власну вітрину з інтеграціями та міграцією за кілька місяців, професійний сайт на замовлення зазвичай за 6-10 тижнів. Затримки накопичуються до розробки (обсяг, контент) і просто перед запуском (тестування, погодження), тому реалістичний графік показує й доріжку клієнта: рішення, дані про товари, доступи, зворотний зв'язок і приймання.

Детальніше: Скільки насправді займає розробка e-commerce і що має робити клієнт

MVP, або мінімально життєздатний продукт (minimum viable product), це перша версія продукту з набором функцій, достатнім, щоб реальні користувачі могли його спробувати й заплатити за нього. Так попит перевіряє ринок, а не чиїсь думки. Добрий MVP скорочений за обсягом, але не за якістю: його модель даних і код мають витримати зростання. Наші проєкти MVP коштують від $20 000, розробка зазвичай триває від двох до чотирьох місяців.

Детальніше: Розробка MVP

Оцінка MVP (MVP review) це незалежна перевірка першої версії продукту, якою вже користуються люди, часто зібраної швидко або за допомогою ШІ: її коду, безпеки, продуктової логіки й ринку. Підсумок це письмовий вердикт: залишити, доопрацювати чи переписати. Вузький внутрішній інструмент без платежів і чутливих даних зазвичай можна залишити, робочий продукт з аудиторією, що зростає, і зрозумілою структурою доопрацювати, а платежі чи персональні дані на основі без контролю доступу потребують переписування. Наша оцінка коштує від $3 000, найчастіше $3 000-5 000, і ціну фіксують до початку роботи.

Детальніше: Оцінка MVP

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

Детальніше: Розробка вебзастосунків і SaaS

Go-to-market стратегія (стратегія виходу на ринок) це план того, як продукт дійде до клієнтів: через які канали, з яким повідомленням, з яким бюджетом і в якому порядку. Її перевіряють паралельно з розробкою: де цільовий клієнт витрачає увагу і чи можна достукатися до нього цим каналом за розумну ціну. Чудовий продукт без життєздатного шляху до клієнта це не MVP, а дорогий проєкт із нечисленними користувачами, а новий сайт без маркетингового бюджету й плану трафіку дорогий об'єкт, якого ніхто не бачить.

Детальніше: Архітектура MVP: що маркетинг винен продукту до запуску

Build vs buy це рішення, чи розробляти власне програмне забезпечення, чи користуватися готовим продуктом, найчастіше SaaS (software as a service, програма як послуга). Змінилися обидві сторони: платформи вміють значно більше, ніж раніше, а розробка на замовлення пришвидшилася завдяки сучасним фреймворкам і ШІ. Рішення часто не остаточне: компанія може спершу купити й налаштувати готове, зрозуміти, як насправді працює її процес, а потім розширити його або написати своє.

Детальніше: Рівняння Build vs. Buy змінилося. Більшість компаній його ще не перерахували

Розростання підписок (SaaS sprawl) це неконтрольоване зростання кількості підписок компанії на програмні сервіси: інструменти додають різні відділи, функції перетинаються, а частиною ліцензій ніхто не користується. Підписка за $500 рідко лишається системою за $500: довкола неї накопичуються конектори, додаткові модулі й дорожчі тарифи. За індексом Zylo за 2026 рік витрати на SaaS зросли на 8% за рік, а 36% ліцензій не використовувалися.

Детальніше: Рівняння Build vs. Buy змінилося. Більшість компаній його ще не перерахували

Сукупна вартість володіння, або TCO (total cost of ownership), це повна вартість системи за весь термін її роботи, а не лише ціна розробки чи купівлі: підписки, застосунки й комісії, хостинг, підтримка, оновлення, тестування, доопрацювання та ціна обхідних рішень. Поширена помилка: порівнювати разовий кошторис на розробку із щомісячною підпискою без урахування TCO. У наших порівняннях платформ ми дивимося на п'ять років уперед.

Детальніше: Чи йти з Magento у 2026 році: оновлення, Shopify Plus чи Laravel?

Витрати після запуску це те, у що обходиться робота сайту чи застосунку після релізу: хостинг, безпека, оновлення, моніторинг і виправлення. Поширений орієнтир для планування становить 10-20% від початкової вартості розробки на рік. Для професійно підтримуваного сайту невеликого бізнесу хостинг, підтримка й оновлення обходяться приблизно в $1 200-3 600 на рік, із них на домен і хостинг припадає $200-500.

Детальніше: Що насправді робить розробку e-commerce дорогою

Ліцензування за користувача (per seat) це модель ціни, за якої за програму платять за кожного користувача на місяць; вона поширена в CRM, ERP та інструментах для спільної роботи. На старті це виглядає дешево, але витрати зростають разом із командою: за прайсами 2026 року 20 користувачів за п'ять років обійдуться в $120 000-234 000 у Salesforce Sales Cloud і $109 500 у HubSpot Professional, тоді як власна CRM коштує від $90 000. За 10 користувачів дешевшим виходить HubSpot ($55 500), а CRM за $30 на користувача стає дорогою, якщо її впровадження коштує $50 000.

Детальніше: Розробка CRM

Цінові рівні сайтів це типові діапазони цін на сайт залежно від того, хто і як його робить. На ринку США у 2026 році конструктори коштують $20-80 на місяць, фрилансери $1 500-6 000, невеликі агенції $5 000-15 000, сайти на замовлення від $15 000 до $50 000 і більше, корпоративні проєкти від $50 000 до $150 000 і більше. За $5 000 клієнт платить за виконання, а за $20 000 за стратегію, власний дизайн, роботу над конверсією, SEO-архітектуру й досвідчену команду.

Детальніше: Скільки коштує сайт у Сіетлі у 2026 році?

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

Детальніше: Чому бізнес, що росте в Bellevue, рано чи пізно виростає зі свого сайту

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

Детальніше: Софт має підходити бізнесу

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

Детальніше: Чим ти реально володієш, а що орендуєш: Digital Ownership Audit

Цифрові активи це домени й DNS, хостинг, вихідний код, ліцензії CMS, аналітика, рекламні кабінети, CRM і пошта, API та облікові записи, на яких працює бізнес, разом із його контентом. Кожен із них має бути оформлений на акаунт компанії, а не на особистий. Активи, які підтримують, наприклад статті, описані процеси й кейси, з часом дорожчають, а не знецінюються, і це стає помітно під час продажу компанії.

Детальніше: Що відбувається із сайтом після купівлі компанії?

Цифрове володіння це реальний контроль компанії над своїм доменом, DNS, хостингом, репозиторієм коду, аналітикою, Search Console, платіжними й поштовими сервісами через акаунти, які належать їй самій. Логін адміністратора чи вивантаження даних це доступ, а не володіння: договір може передати сайт, а паролі й ключі лишаться в людей, які вже пішли. Кожен компонент можна віднести до однієї з груп: володіємо, орендуємо (зрозуміла залежність) або залежимо від людини чи підрядника, до якого більше ніхто не може дістатися. Хто володітиме сайтом після запуску, краще вирішити до того, як вирішувати, як його будувати.

Детальніше: Більшість компаній не володіють своїм сайтом. Вони володіють сукупністю залежностей.

Залежність від постачальника (vendor lock-in) це залежність від підрядника чи платформи, через яку піти від них дорого або неможливо в розумний строк. Простий тест: чи може компанія замінити свого розробника, агенцію, хостинг, CRM або платформу, не втративши критичних функцій. Вивантаження даних може виявитися марним без закритої логіки, яка їх оточує. Ризик цілком практичний: Bitrix24 оголосив, що з 1 червня 2023 року його хмара перестане працювати в Україні, і користувачі могли втратити портали й дані.

Детальніше: Чим ти реально володієш, а що орендуєш: Digital Ownership Audit

Аудит до оцінки це практика вивчати наявний сайт або систему до того, як погодити ціну робіт над ними. Звичний порядок (вступний дзвінок, пропозиція, договір, аудит, розробка) фіксує ціну до того, як знайдено прихований технічний борг, і сюрпризи потім надходять додатковими рахунками. Якщо спершу провести аудит, за дні, а не місяці, оцінка спирається на те, що справді є в проєкті.

Детальніше: Прихований технічний борг, через який редизайн сайту коштує дорожче за план

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

Детальніше: Сесія технічного due diligence

Аудит цифрового володіння це перевірка того, чим бізнес справді володіє, а що орендує або від чого залежить: сайт, код, дані, сервіси, договори з підрядниками та ключові люди. Він відповідає на одне питання: що зламається, якщо завтра зникне розробник, агенція чи платформа. У підсумку ви отримуєте карту володіння й залежностей і список пріоритетів; наш аудит коштує від $1 000 і триває від п'яти до десяти робочих днів.

Детальніше: Аудит цифрового володіння та боргу

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

Детальніше: Аудит цифрового володіння та боргу