Будувати чи купувати AI-агента — decision tree для SMB

Якщо ви власник, якому за тиждень запитчили і "AI-платформу, що збере вам агента", і "коробковий vertical AI-агент" — і ви намагаєтеся зрозуміти, що з цього реальне — це для вас. Рішення простіше, ніж його роблять продавці, а неправильна відповідь коштує приблизно рік.

Чому це питання тепер термінове

У 2024 рішення можна було відкласти — vertical AI-агенти були тонкі. У 2026 vertical-ринок реальний: є придатні продукти для HR-screening, expense classification, support-deflection, contract review, finance reconciliation. Те саме на build-стороні — n8n, Make, Lindy, Relay дають компетентній ops-команді зашипити кастомного агента за дні, не місяці.

Обидва шляхи тепер життєздатні для більшості SMB-задач. Тому критерії вибору важливіші, ніж колись, а "просто збудуємо кастомне" вже не дефолтна безпечна відповідь.

Визначення: Vertical AI-агент — програмний продукт під конкретну роботу (AI sales-SDR, AI invoice-reconciliation). Продається як SaaS з агент-логікою, промптами й інтеграціями всередині.

Визначення: Custom AI-агент — агент, якого ваша команда збирає на платформі (n8n, Make, Zapier, LangChain) на ваших даних, промптах і бізнес-логіці.

Повчальна історія Builder.ai

Builder.ai підняв >$445M і оцінювався близько $1,5B перед колапсом 2024 року з повідомленими "$1,3B" знищеної вартості. Питч був звабливий: "ми побудуємо ваш кастомний софт з AI". Реальність — офшорна інженерна операція в AI-обгортці, продана покупцям, які не знали, що саме хочуть.

Урок для AI-агентів прямий: "build-as-a-service" працює лише, коли ВИ вже точно знаєте, що агент має робити. Якщо ні — а більшість SMB не знає до того, як спробує — купити vertical-продукт спершу — дешевший спосіб розібратися.

Визначення: Build-as-a-service — агенції/платформи, що обіцяють збудувати вам кастомного агента. Падають, коли клієнт не сформулював роботу; працюють, коли сформулював.

Чотири питання

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

Питання 1: Чи це ваша диференціація?

Якщо те, як ви робите цей workflow, робить вас швидшими/кращими/дешевшими за конкурентів — будуйте. Якщо 100 інших SMB роблять той самий workflow так само, як ви — купуйте.

Приклади:

• Sales SDR-outreach: workflow генеричний, важелі конверсії відомі → купити.
• Custom underwriting для нішового страхового брокера: workflow кодує 20 років правил → будувати.
• Класифікація чеків: усі роблять приблизно однаково → купити.
• Pricing проєктних bid-ів для custom-fab виробника: кожен bid комбінує 50 ваших унікальних input-ів → будувати.

Питання 2: Наскільки чутливі дані?

Якщо leak агента — регуляторна або конкурентна катастрофа — ризик-профіль покупки змінюється. Vertical SaaS вендори роблять свій data-handling; ви довіряєте їхній security. Для більшості SMB це ок. Для деяких секторів (legal, healthcare, financial advice, defense supply chain) — ні.

EU AI Act штрафи до €35M або 7% обороту — для high-risk систем. Більшість workflows не high-risk, але документуйте data flows. Self-hosted custom — найбільше контролю; vertical вендори — найменше.

Питання 3: Як часто міняється логіка?

Стабільні роками workflows — на користь "купити". Workflows, що міняються щокварталу (pricing-модель, sales-motion, fulfillment) — на користь "будувати". Vertical-вендори оновлюються по своєму roadmap, не по вашому.

Питання 4: Хто реально володіє після запуску?

Найчастіший failure-mode: "ми купили / збудували, потім ніхто не володів". До рішення — назвіть owner-а, не "operations", а конкретну людину, і підтвердіть її час і навички. Custom-агентам потрібен owner, що розуміє платформу; vertical — owner, що розуміє roadmap і integration-map вендора.

Manager scan (2-minute digest example)

Ось як daily-management-лінза розрізає абстрактну дискусію. Для кожного кандидата на агента — три рядки: Plan, Fact, Gap.

• Plan: "Купити vertical sales-SDR агента ABC за €600/міс, очікуємо +30% qualified meetings за 60 днів."
• Fact: "За 30 днів: агент живий, інтеграція готова, qualified meetings +12%, sales команда скаржиться на тон агента."
• Gap: "Тон неправильний, бо промпт вендора заточений під US-style outbound; ми продаємо в DACH — звучить пушисто."

Цей трійник Plan → Fact → Gap, оновлюваний щодня перші 60 днів, каже: тримати, замінити чи перебудувати — без таблиць, без консультантських дек. По всьому AI-портфелю SMB це спосіб бачити, які агенти тихо underperform-ять.

Tool tip (AIAdvisoryBoard.me): Build-vs-buy часто застрягає тому, що власники не знають реального ground truth — лише те, що люди КАЖУТЬ, як іде workflow. Діагностика Plan → Fact → Gap за 7 днів показує, що команда дійсно робить vs що думає, що робить. Цей ground truth — саме те, що потрібно перед рішенням, чи workflow генеричний для покупки чи специфічний для побудови. Іти всліпу — спосіб закінчити з shelfware з одного боку й кинутою кастомною побудовою з іншого.

Коли виграє "купити"

• Робота генерична (lead enrichment, класифікація витрат, support deflection, meeting summaries).
• Є репутаційний вендор з референсами компаній вашого розміру.
• Ціна вендора масштабується нормально (red flag: per-seat pricing на back-office агента).
• Запуск за 2-4 тижні.
• Switching cost прийнятний (data export задокументований, ви не lock-in).

Коли виграє "будувати"

• Workflow кодує конкурентну перевагу.
• Є один технічний owner, що підтримуватиме.
• Очікуєте ітерацій логіки хоча б щомісяця.
• Чутливість даних виключає SaaS (рідко для SMB).
• Сумарна вартість (build + run + maintain) за 24 міс матеріально нижча за buy — рахуйте чесно, з opportunity cost.

Коли не виграє ніхто (відповідь "почекати")

Іноді правильна відповідь — "ні те, ні інше, поки що". Якщо не можете відповісти "як виглядатиме успіх на 60-й день?" одним реченням — ви не готові. Купіть найдешевшу опцію на 60 днів як інструмент навчання, АБО проведіть 2-тижневий мануальний експеримент без AI — просто щоб побачити, як workflow реально виглядає. Тоді вирішуйте.

Copy-paste decision template

Workflow під розгляд: ____________________

1. Диференціація (це робить нас кращими?):
   [ ] Генеричне — у нашій ніші всі роблять схоже  → BUY
   [ ] Специфічне — кодує те, як ми виграємо  → BUILD

2. Чутливість даних:
   [ ] Стандартні бізнес-дані  → BUY
   [ ] Регульовані / IP-чутливі  → BUILD або self-hosted

3. Частота змін:
   [ ] Стабільне роками  → BUY
   [ ] Кожен квартал  → BUILD

4. Owner:
   [ ] Названа ops-людина з bandwidth  → будь-яке
   [ ] Без owner-а  → НЕ РОБИТИ нічого, поки не зʼявиться

Рахунок: __ buy / __ build  (3+ — рішення)

Очікувана 24-міс TCO:
- Buy:   €______ (підписка) + €______ (інтеграція)
- Build: €______ (build) + €______ (підтримка) + €______ (платформа)

Метрика успіху на 60-й день (одне речення):
________________________________________________

Micro-case (що змінюється за 7-14 днів)

Виробник на 200 людей вирішує — будувати кастомний quote-generation агент чи купити vertical CPQ. Запускає Plan → Fact → Gap на 7 днів на своєму поточному manual quote-процесі. Виявляється: 70% котирувань мають генеричний патерн (vertical це покриє), а 30% мають custom-fab логіку, яку жоден вендор не моделює. Купують vertical CPQ на 70% і будують тонкого кастомного на 30%. До 14-го дня turnaround на генеричних 70% падає з 2 днів до 4 годин, а команда має чіткий скоуп на кастомну побудову замість гадання. Сумарно зекономленого senior-час за квартал: ~80 годин.

Note on this case: Цей приклад ілюстративний — типові патерни для компаній 30-500 людей, не один названий клієнт. Цифри округлені, не гарантії.

Tool tip (AIAdvisoryBoard.me): Найскладніше в build-vs-buy — не порівняння, а знання, що насправді відбувається на місцях. AIAdvisoryBoard.me крутить 7-денну діагностику, що видає щоденний Plan → Fact → Gap по реальній роботі команди — показуючи, які workflows генеричні достатньо для покупки, а які кодують унікальне know-how, навколо якого варто будувати. Без цього ground truth рішення — здогадки. З ним — відповідь зазвичай очевидна на першому тижні.

FAQ

А "build-as-a-service" агенція? Сприймайте як покупку. Агенція — вендор, ви платите за доставку workflow. Урок Builder.ai: працює лише коли ВИ знаєте, що хочете. Якщо наймаєте агенцію, щоб зрозуміти — платите за дуже дорогі здогадки.

Якщо vertical-продукту під нашу роботу ще нема? Тоді купити — не варіант, лише build або wait. Wait недооцінений — vertical AI ринок швидкий, продукт, якого нема сьогодні, може зʼявитися за 6 міс. Якщо вартість очікування низька — чекайте.

Можна купити І будувати? Так, для SMB це часто правильно. Купіть генеричні 70% AI-портфеля, побудуйте диференційовані 30%. Помилка — намагатися збудувати все.

Як EU AI Act впливає? Для більшості SMB-workflows — мало; вони поза high-risk. Для high-risk (employment, біометрія, credit scoring) build-with-self-host дає найбільш захисну позицію — ви контролюєте audit trail. Купівля у вендора — довіра до його compliance posture.

Підсумок

Build-vs-buy — не релігія, а ситуативно. Генеричний workflow: купити. Диференційований: будувати. Не можете сформулювати: робіть діагностику, потім вирішуйте. Історія Builder.ai — попередження для "заплачу комусь, щоб розібрався за мене": дорогий і повільний шлях.

Наступний крок: оберіть один workflow, пройдіть 4-питальний template, ведіть Plan → Fact → Gap 7 днів. Тоді вирішуйте.

Якщо хочете систему, що автоматично щодня показує Plan → Fact → Gap по всій компанії — подивіться, як працює 7-денна діагностика: https://aiadvisoryboard.me/?lang=en