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

П'ЯТНАДЦЯТЬ РОКІВ ТОМУ Я БАЧИВ ЦЮ МЕЖУ

П'ятнадцять років тому я часто бачив цю межу значно чіткіше.

Великий каталог. Складні фільтри. Великий трафік. Складні інтеграції.

У певний момент розмова ставала відносно простою. CMS доводила нас до цієї точки. Далі ми будували.

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

І мені менш комфортно ухвалювати їх швидко.

Не тому, що я гірше розумію софт. Тому що софт по обидва боки рішення змінився. Платформи стали сильнішими. CMS-екосистеми стали здатнішими. Інтеграції стали простішими. Кастомний софт став швидшим у розробці. А тепер AI знову зрушує економіку розробки.

Стара форма питання була простою: будувати чи купувати?

Я більше не впевнений, що це правильне питання.

Питання, яке я ставлю частіше зараз: що нам треба вирішити сьогодні, а що реальність вирішить за нас пізніше?

Я КОЛИСЬ БАЧИВ ЦЮ МЕЖУ

Пам'ятаю, коли Shopify був значно простішим продуктом. Пам'ятаю, коли багато CMS-платформ мали очевидні обмеження.

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

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

Сьогодні цю межу побачити важче.

Сучасні комерційні платформи вже не прості інструменти, які я пам'ятаю. Вони стали екосистемами. Сам Shopify тепер підтримує значно ширший B2B і extensibility шар, ніж продукт, який багато хто з нас пам'ятає з минулих років. Його поточна платформа охоплює B2B функціонал, кастомні опції storefront, API, розширюваність checkout і зростаючу екосистему навколо ядра commerce-двигуна.

Те саме сталося з софтом загалом.

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

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

Немає жодного призу за володіння 80 000 рядків коду до того, як прийде твій перший сотий клієнт.

Але змінилось і дещо інше.

Будувати стало доступніше. Сучасні фреймворки, хмарна інфраструктура, API, розподілені команди розробки, і тепер AI-асистована розробка, все це зрушило частину економіки кастомного софту.

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

Це не суперечність. Це вся складність.

ПІДПИСКА ЗА $500 РІДКО ЗАЛИШАЄТЬСЯ СИСТЕМОЮ ЗА $500

Я бачив це багато разів.

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

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

Одна підписка притягує іншу.

Рішення за $500 ніколи не було системою за $500.

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

Але стеки підписок накопичуються. І іноді накопичуються тихо.

2026 SaaS Management Index від Zylo повідомляє, що середні витрати на SaaS у їхньому датасеті зросли на 8% рік до року, тоді як середня кількість застосунків лишалась практично незмінною. Також звіт повідомляє в середньому про 36% ліцензій, що не використовуються відносно рекомендованих рівнів утилізації. Дані походять від SaaS-management вендора, і це варто враховувати, але патерн знайомий кожному, хто уважно дивився на зрілий software-стек.

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

Це нам знадобиться в кінці року. Відділ продажів це використовуватиме. Ми плануємо зайти на інший ринок.

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

Майбутнє не приходить.

Підписка приходить. Щомісяця.

Software-стеки накопичують припущення. Деякі стають реальними вимогами. Деякі ні. Рахунок не знає різниці.

ІНОДІ SAAS ЦЕ ДОСЛІДЖЕННЯ

Саме тут, я думаю, компанії роблять рішення build versus buy занадто постійним, занадто рано.

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

Але є проблема.

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

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

Це нормально. Мені подобається ця частина проєктів. Живий бізнес не чистий. Різні люди тиснуть на систему з різних боків, бо переживають різні частини реальності.

Помилка не в наявності цього хаосу. Помилка в перетворенні кожної поточної думки на постійну інфраструктуру.

Іноді найкраще рішення взяти наявний SaaS-продукт і запуститись. Не тому, що ми вважаємо, що компанія має користуватись ним вічно. Тому що компанії потрібно навчитись.

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

Через шість місяців розмова інша.

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

На це значно дорожче відповісти кастомним кодом.

Іноді SaaS не альтернатива кастомному софту. Іноді SaaS дослідницька фаза перед кастомним софтом.

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

Добре. Лишайся там.

Мета ніколи не полягала в тому, щоб знайти привід будувати. Мета полягала в тому, щоб знайти правильну інфраструктуру для бізнесу.

МОЖЕ, ТИ ПРОСТО НЕ МОЖЕШ ЦЕ ПОБУДУВАТИ

Одного разу я сперечався з клієнтом про фічу, яку він хотів, щоб ми побудували.

У нього був бюджет. Він був готовий платити. Я продовжував питати, чи бізнес реально потребує цієї фічі. У певний момент він розлютився.

Може, ти просто не можеш це побудувати. Або в тебе немає ресурсів. Твої конкуренти можуть це зробити. Ти не можеш. Мені піти до них?

Хотілося б сказати, що я лишався повністю раціональним.

Не лишався. Це мене зачепило.

Добре, сказав я. Ми це побудуємо.

Але я попросив про одне.

Через шість місяців ми повернемось і перевіримо, наскільки важливою насправді була ця фіча.

Робота коштувала близько $18,000. Ми це побудували.

Через шість місяців ми зустрілись, щоб обговорити нові задачі. Я не забув ту суперечку. Тож запитав: можемо подивитись на ту фічу?

Ми подивились.

Ніхто нею не користувався. Не менше, ніж очікувалось. Недостатньо, щоб виправдати вартість. Ніхто.

Фіча працювала. Клієнт був готовий платити. Ми були здатні її побудувати. Гроші були доступні.

І все одно нам не варто було це будувати.

Я не розповідаю цю історію, бо був правий. Я не був упевнений. У мене були сумніви. Це різні речі.

І мені точно не сподобалось відкрити, що клієнт витратив близько $18,000 на те, чим ніхто не користувався.

Але цей досвід змінив те, як я підходжу до кастомної розробки.

Сьогодні, коли клієнт каже мені, що фіча важлива, я часто ставлю інше питання.

Коли вона тобі реально потрібна?

Мабуть, ближче до кінця року.

Тоді, можливо, ми не будуємо це сьогодні. Ми запускаємо те, що бізнес розуміє зараз. Спостерігаємо. Вчимось. Якщо фіча стане реальною вимогою, ми її тоді побудуємо.

Ми досі працюємо з тим клієнтом.

ІНОДІ Я ПОЯСНЮЮ СОФТ ЧЕРЕЗ БУДИНОК

Я працював і з цифровою, і з фізичною архітектурою. Тому іноді пояснюю клієнтам software-рішення, розповідаючи про будівлі.

Софт відчувається гнучким. Поле в базі даних не виглядає дорогим. Ще одна роль користувача не виглядає структурною. Ще один статус. Ще одна інтеграція. Ще один виняток. Це код. Ми можемо змінити код.

Будівля робить ту саму помилку значно легшою для розуміння.

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

Басейн на терасі не декоративна ідея. Вода важка. Навантаження змінюється. Інженерія змінюється. Конструкцію треба спроєктувати під те майбутнє, яке ти описуєш.

Тож терасу підсилили. Конструктивні роботи, пов'язані із запланованими навантаженнями, додали приблизно $100,000. Будинок також підготували під ідею ліфта.

Басейн так і не побудували. Ліфт теж.

Майбутнє зникло. Інфраструктура, побудована під нього, лишилась.

Я бачив, як уявні вимоги ставали кодом. Я також бачив, як вони ставали бетоном. Помилка напрочуд схожа.

Софт легше змінити, ніж бетон. Рахунок ні.

Можна прибрати фічу, що коштувала $18,000. Можна видалити код. Можна вимкнути інтеграцію. Можна спростити workflow. Гроші не повертаються.

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

У певний момент ти обслуговуєш будівлю під басейн, якого так і не побудували.

Кожне припущення входить в архітектуру так, ніби майбутнє вже настало.

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

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

НАВІТЬ КОЛИ МИ БУДУЄМО КАСТОМНЕ, МИ ПОЧИНАЄМО ПРОСТО

Кастомна розробка не означає будувати все.

Звучить очевидно. На практиці це напрочуд складно.

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

І оскільки ми все одно будуємо кастомний софт, кожна ідея починає звучати дешевше.

Ми вже тут. Додаймо це зараз. Пізніше буде складніше. Нам це точно знадобиться.

Можливо.

Але кожна фіча, яку ми будуємо, створює зобов'язання щодо обслуговування.

Усе, що ти будуєш, починає старіти в день, коли ти це завершуєш.

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

Тож одне з найпростіших питань, які я ставлю: тобі реально потрібна ця фіча?

Так. Абсолютно. Ми плануємо її впровадити.

Коли?

Мабуть, ближче до кінця року.

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

Якщо виживе, ми це побудуємо.

Не будуй кастомно майбутнє припущення, якщо можеш зачекати, поки воно стане поточною вимогою.

Це не про швидке будування поганої першої версії. Мене не цікавить випустити щось погане й назвати це MVP.

Це про побудову тієї частини системи, яку бізнес уже розуміє. А потім дати реальності спроєктувати з нами наступний шар.

ПРАВИЛЬНЕ РІШЕННЯ МОЖЕ ЗМІНИТИСЬ

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

Оригінальний продукт побудували на open source CMS. На той момент це було правильне рішення. Бізнесу не потрібна була велика кастомна платформа тільки тому, що ми могли її побудувати.

CMS дала нам основу. Ми розвивали її. Розширювали. Підключали, що потрібно було підключити. Бізнес працював.

Потім бізнес зріс. Каталог став складнішим. Логіка фільтрації стала вимогливішою. Інтеграції накопичились. Сам продукт став іншою системою.

Тож ми подивились на рішення знову. Цього разу кастомна розробка мала більше сенсу.

Не тому, що кастомний софт таємно був правильною відповіддю п'ять років тому. Попереднє рішення було правильним. Бізнес змінився. І коли бізнес змінився, рівняння змінилось разом із ним.

Це та частина, яку, я думаю, багато компаній пропускають.

Software-рішення стає частиною історії компанії. Ми користуємось цією CRM. Ми на цій платформі. Ми побудували власну систему. Ми обрали цю архітектуру п'ять років тому.

Речення поступово перетворюється з рішення на факт. Ніхто більше не ставить оригінального питання.

Але бізнес, який відповідав на те питання, може вже не існувати. Його обсяг змінився. Його команда змінилась. Його клієнти змінились. Його процеси змінились. Його software-постачальники змінились. Економіка розробки змінилась. Здатності платформ змінились.

Чому відповідь має лишатись постійною?

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

Вони побудували модель під це.

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

КУПИТИ, НАЛАШТУВАТИ, РОЗШИРИТИ, ПОБУДУВАТИ

Я більше не думаю про це як про двоє дверей.

КУПИТИ

Використай наявний продукт. Запускайся швидко. Плати за доступ. Хай хтось інший несе більшість тягаря платформи.

НАЛАШТУВАТИ

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

РОЗШИРИТИ

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

ПОБУДУВАТИ

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

І навіть тоді, починай просто.

Цей спектр дедалі частіше видно і в поточних дискусіях про build versus buy. Останні фреймворки описують вибір менше як бінарний, і більше як побудувати, купити, чи розширити наявну платформу.

Але ми б додали ще одну річ.

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

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

Архітектура має служити бізнесу. Бізнес не має вдавати складність заради архітектури.

ПЕРЕРАХУЙ

Якщо клієнт запитує нас сьогодні: Shopify, SaaS, open source CMS чи кастомний софт?

Ми не можемо відповісти з самого питання. Навіть із необмеженим бюджетом ми не можемо чесно сказати: кастомний.

Нам потрібно зрозуміти бізнес.

Що він робить сьогодні? Що реально складно? Які процеси реальні, а які заплановані? Чим компанія очікує займатись через п'ять років? Скільки реально коштує поточний software-стек після підписок, модулів, конекторів та інтеграцій?

Що станеться, якщо вендор змінить ціни? Що станеться, якщо команда кастомної розробки зникне? Чи може компанія обслуговувати те, чим хоче володіти? Чи потрібна бізнесу ця функція зараз? Коли вона реально нею користуватиметься?

І, можливо, найважливіше: чи знає компанія достатньо про цей процес, щоб зробити рішення постійним?

Економіка рухається з обох боків. SaaS-портфелі не обов'язково ростуть за кількістю застосунків, але витрати продовжують зростати за поточними галузевими даними. Водночас AI-асистована розробка змушує дослідників і компанії переглядати частину історичної економіки будування софту, хоча поточні дослідження також попереджають, що ідея про те, що AI просто робить SaaS застарілим, перебільшена.

Саме тому ми думаємо, що багатьом компаніям варто переглянути це питання.

Не тому, що SaaS поганий. Не тому, що кастомний софт раптом став дешевим. Не тому, що AI змінив усе за ніч.

Тому що змінні зрушились.

І твій бізнес, ймовірно, теж зрушився.

Software-рішення, яке ти ухвалив п'ять років тому, могло бути цілком правильним. Це не робить його правильним сьогодні.

Фіча, у якій ти впевнений, що вона знадобиться в грудні, може стати критичною. Або нею ніхто ніколи не скористається.

Платформа, яку ти орендуєш, може стати фундаментом компанії на наступне десятиліття. Або вона може навчити тебе точно того, чим має стати твоя власна система.

Питання не в тому, чи можемо ми це побудувати. Дедалі частіше можемо.

Питання не в тому, чи вже існує софт, здатний це зробити. Дедалі частіше існує.

Складніше питання, чи бізнес знає достатньо, щоб зробити рішення постійним.

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