Build vs buy messaging: коли власна розробка вигідніша за CPaaS
Розмова зазвичай починається на плануванні спринту. Продукту потрібні скидання пароля, сповіщення про доставку чи коди для входу, і senior-інженер каже: «Надіслати SMS — це один HTTP-запит. Зробимо самі за пару спринтів». У перший день він має рацію: перше повідомлення йде швидко. Складнощі з'являються за кілька місяців, коли маршрут в одній країні вночі починає губити коди, а в команді ніхто не знає, якому оператору телефонувати.
Саме цей розрив між першим повідомленням і production-рівнем messaging-системи і є суттю рішення build vs buy messaging. Питання не в тому, чи здатні ваші розробники це написати. Питання в тому, де їхній час приносить найбільше цінності і що ви берете на себе, коли володієте всім стеком: підключенням до операторів, маршрутизацією, комплаєнсом і чергуваннями.
У цьому гайді ми порівнюємо шляхи in-house vs CPaaS за п'ятьма вимірами, які визначають результат: час, гроші, підтримка, комплаєнс і масштаб. Він написаний для product-лідів, CTO та інженерів у ЄС і Великій Британії, де регуляторні вимоги додають рішенню власної ваги. Якщо спершу потрібна база, почніть зі статті що входить у CPaaS і як вона працює.
Що насправді означає «будувати messaging самостійно»
Власна розробка messaging означає, що ваша команда володіє програмним шаром, а часто й підключенням, яке перетворює подію в продукті на повідомлення на телефоні клієнта. Більшість команд недооцінює обсяг, бо словом «будувати» називають три зовсім різні проєкти.
На найлегшому рівні ви пишете тонкий сервіс, що викликає API провайдера. Це все одно купівля: доставку віддано на аутсорс, у вас лишається тільки бізнес-логіка. На середньому рівні ви будуєте власну messaging-платформу з чергами, ретраями, шаблонами, зберіганням згод, звітністю та підключенням до одного чи кількох агрегаторів через SMPP — протокол обміну A2P SMS-трафіком між бізнесом і операторами. На найважчому рівні ви домовляєтеся про прямі підключення до мобільних операторів, країна за країною.
Майже кожна дискусія build vs buy насправді стосується середнього рівня. Команди рідко планують стати телеком-компанією. Проте власна платформа дрейфує саме в цю роль, щойно ви додаєте другий канал, другу країну чи другого провайдера для резервування. Домовтеся, який рівень ви оцінюєте, перш ніж хтось рахуватиме трудовитрати, інакше оцінки описуватимуть різні проєкти.
Час: таймлайн build vs buy messaging, якого ніхто не планує
Перше повідомлення виходить за кілька днів. Production-система займає значно більше часу, бо основна робота — у граничних випадках, які проявляються лише під реальним трафіком. Ось що має вміти власний SMS-шар, перш ніж йому можна довірити коди входу чи платіжні сповіщення, — і саме тут ламається більшість оцінок build vs buy SMS:
- Контроль пропускної здатності на кожному підключенні, щоб піки трафіку не обмежувалися й не відхилялися оператором.
- Кодування повідомлень: одне SMS вміщує 160 символів GSM-7 або 70 символів UCS-2, довші тексти діляться на сегменти (3GPP TS 23.038). Один емодзі може перевести все повідомлення в UCS-2 і помножити кількість сегментів, за які ви платите.
- Звіти про доставку (DLR), що приходять із запізненням, не по черзі або у специфічних форматах різних операторів.
- Ретраї та failover, які ніколи не надсилають той самий одноразовий код двічі.
- Правила Sender ID, що різняться між країнами, а на деяких ринках вимагають попередньої реєстрації.
- Обробка відписок, записи згод і журнали аудиту.
Нічого з цього не є екзотикою. Кожен пункт — це тікет, набір тестів і окремий сценарій збою. Разом вони перетворюють оцінку «на два спринти» на пункт роадмапу, який кварталами конкурує з вашим основним продуктом.
У BSG ми бачимо, що найдорожча частина власної розробки messaging — не перша версія, а другий рік. Оператори змінюють інтерфейси, країни змінюють правила для відправників, а інженер, який написав SMPP-клієнт, переходить в іншу команду. Час до першого повідомлення погано відображає час до надійного messaging, тож порівнюючи два шляхи, оцінюйте саме другу цифру.
Купівля стискає цей таймлайн, бо інтеграційна робота — це переважно ваша власна логіка: виклик API, обробка webhook-ів зі статусами та зіставлення типів повідомлень із шаблонами. Підключення до операторів, кодування, маршрутизація та розбір звітів уже працюють у production на боці провайдера.
Гроші: скільки насправді коштує власний messaging
Вартість in-house messaging рідко полягає в коді. Вона полягає в людях, які його підтримують, у контрактах за ним і у втратах, що стаються, коли за трафіком ніхто не стежить.
У будь-якому порівнянні CPaaS vs build почніть із факту, який змінює чимало бюджетів: власна розробка не прибирає плату за кожне повідомлення. Оператори беруть плату за термінацію в будь-якому разі. Коли ви будуєте самі, ви все одно купуєте доставку — в агрегатора або напряму в операторів, — а прямі угоди зазвичай вимагають обсягів, комерційних відносин і технічної сертифікації, яких у більшості продуктових компаній немає. Тож реалістичне порівняння — не «ціна провайдера проти нуля», а ціна провайдера проти ціни агрегатора плюс вартість вашої власної платформи.
Проста модель сукупної вартості володіння (TCO) для шляху in-house містить шість рядків:
- Розробка: розробники, які будують платформу, помножені на їхню повну вартість і кількість місяців роботи.
- Підтримка: частка часу інженера щомісяця на зміни в операторів, баги та нові вимоги.
- Чергування: хтось має відповідати за інциденти поза робочим часом, щотижня, цілий рік.
- Інфраструктура: сервери, черги, моніторинг, логування та захищене зберігання згод і даних повідомлень.
- Плата за доставку та мінімальні зобов'язання перед агрегаторами чи операторами.
- Втрати від фроду, особливо штучно роздутого трафіку (AIT), коли боти ініціюють запити одноразових паролів на номери, які контролюють шахраї, а ви платите за кожне повідомлення.
Підставте власні зарплати й обсяги. Якщо сума in-house виходить меншою лише тому, що підтримка, чергування та фрод дорівнюють нулю, модель не завершена.
Шлях купівлі має власну ціну. Ви платите маржу з кожного повідомлення і залежите від цінової політики провайдера. Натомість за цю маржу ви отримуєте роботу з маршрутизації, яку інакше виконувала б ваша команда. В OTP-потоках, які ми обслуговуємо, каскадна маршрутизація, що спершу пробує найвигідніший канал і автоматично переходить на резервний, зазвичай знижує витрати на верифікацію на 20–40%. Власна система теж може реалізувати fallback, але лише між тими маршрутами й каналами, які ви самі законтрактували та інтегрували.
Підтримка та надійність: кого будять уночі?
Надійність — це вимір, де розрив in-house vs CPaaS найбільший, бо messaging ламається тихо. API повертає «accepted», повідомлення залишає вашу систему, а десь між агрегатором і телефоном зникає. Ваші дашборди лишаються зеленими, поки користувачі перестають отримувати коди.
Щоб це помітити, треба відстежувати delivery rate по кожній країні, оператору та маршруту, порівнювати з базовим рівнем і перемикати трафік, коли показник падає. Щоб це виправити, потрібні відносини: людина, яка може відкрити тікет у потрібного оператора й отримати відповідь. Моніторинг in-house-команда збудувати може. Відносини з нуля збудувати значно складніше.
Ми працювали з командами, які тримали власний шлюз поверх одного агрегатора й з'ясували, що слабким місцем був не їхній код, а залежність. Коли єдиний маршрут деградував на одному ринку, запасного шляху не було, а розуміння причин збоїв — мінімальне. Перехід на доставку кількома маршрутами замінив ручне розслідування автоматичним перемиканням. Без резервування проблема оператора стає вашим інцидентом. З ним — рядком у звіті.
Саме цей шар BSG будує й експлуатує. BSG Bulk SMS працює через 60+ прямих підключень до мобільних операторів, на власному SMSC-програмному забезпеченні BSG, з SLA 99,90–99,99%. Це інфраструктура, яку продуктовій команді інакше довелося б збирати, сертифікувати та забезпечувати людьми.
Компроміс працює і в інший бік. Купуючи, ви залежите від якості підтримки провайдера. Запитайте, як ескалюються інциденти, чи будуть у вас персональні контакти і що саме покриває SLA: доступність платформи, якість доставки чи і те, і інше.
Комплаєнс у ЄС і Великій Британії: відповідальність in-house vs CPaaS
Комплаєнс не зникає, коли ви купуєте, і не спрощується, коли ви будуєте. Змінюється лише те, хто яку частину роботи несе.
В обох випадках ваша компанія лишається відповідальною за правову підставу кожного повідомлення. За правилами ЄС маркетинг електронними повідомленнями, включно з SMS, зазвичай потребує попередньої згоди (ePrivacy Directive 2002/58/EC, Art. 13), а Велика Британія застосовує схоже правило через PECR (PECR, Regulation 22). Номери телефонів і зміст повідомлень є персональними даними за GDPR, а найсерйозніші порушення можуть коштувати штрафу до €20 млн або 4% світового річного обороту — залежно від того, що більше (GDPR, Art. 83).
Коли ви будуєте, вам належить уся поверхня комплаєнсу: розміщення даних, строки зберігання, шифрування, контроль доступу, реєстрація відправника в кожній країні, обробка відписок і журнали аудиту. Коли ви купуєте, провайдер діє як ваш обробник даних, тож вам потрібні договір про обробку даних (DPA) і перевірка того, де зберігаються дані та хто має до них доступ. Для фінансових установ ЄС Digital Operational Resilience Act додає формальні вимоги до управління ризиками ICT-підрядників (DORA, Regulation (EU) 2022/2554). Купівля означає задокументований нагляд за постачальником. Власна розробка — задокументовану стійкість власного стеку.
Для бізнесів, з якими ми працюємо в ЄС, вирішальним чинником часто є не сама регуляція, а докази. Аудитори просять сертифікати, схеми потоків даних і записи інцидентів. BSG працює відповідно до GDPR, має комплаєнс ISO та PCI DSS і понад 15 національних телеком-ліцензій у ЄС, тож комплаєнс-команди отримують документацію, на яку можна послатися, замість того щоб створювати її з нуля.
Масштаб: коли розрахунок build vs buy messaging перевертається
Масштаб — єдиний вимір, де власна розробка справді може перемогти. Справжнє питання — чий це масштаб і в скількох країнах.
Власна розробка зазвичай окупається, коли messaging — це ваш продукт, а не його функція: агрегатори, оператори та великі платформи, що перепродають messaging своїм клієнтам. Вона також може мати сенс, коли ваші обсяги дуже великі й зосереджені в кількох країнах, коли у вас уже є телеком- чи інфраструктурна команда або коли регуляція чи контракти вимагають розгортання під вашим повним контролем.
Купівля зазвичай виграє, коли messaging підтримує продукт, а не є ним, коли ви надсилаєте повідомлення в багато країн або коли вам потрібні кілька каналів — SMS, RCS, Viber, голос — із fallback між ними. Вона виграє й тоді, коли швидкість виходу на ринок важливіша за маржу з повідомлення. In-house кожна нова країна чи канал — це новий інтеграційний проєкт. З CPaaS це зазвичай зміна конфігурації.
Є й проміжний шлях. Деякі команди тримають оркестрацію in-house — власну логіку того, що, кому й коли надсилати, — а доставку купують. Інші хочуть брендовану messaging-платформу, не пишучи її: оренда готової CPaaS-платформи дає агрегаторам і enterprise-компаніям власну платформу на інфраструктурі, яка вже працює в production.
Коли будувати, а коли купувати: таблиця рішення
Таблиця нижче зводить рішення in-house vs CPaaS в один погляд. Читайте кожен рядок як питання про вашу ситуацію, а не про провайдерів.
| Критерій | Будуйте самі, коли… | Купуйте CPaaS, коли… |
|---|---|---|
| Роль messaging | Messaging — ваш основний продукт або джерело доходу | Messaging підтримує продукт: сповіщення, OTP, маркетинг |
| Вихід на ринок | Можете чекати на платформний проєкт тривалістю кілька кварталів | Production-трафік потрібен уже цього кварталу |
| Команда | Інженери можуть довгостроково відповідати за телеком-протоколи й чергування | Інженерам варто зосередитися на основному продукті |
| Географія | Кілька країн зі стабільними великими обсягами | Багато країн або плани розширення |
| Канали | Одного каналу достатньо в осяжному майбутньому | SMS плюс RCS, Viber чи голос із fallback між ними |
| Структура витрат | Обсяги дозволяють домовитися про прямі умови з операторами | Маржа з повідомлення коштує менше, ніж команда плюс інфраструктура |
| Комплаєнс | Потрібен повний контроль над даними й розгортанням | Вам зручніші аудиторські процеси та наявні сертифікати |
| Надійність | Можете збудувати моніторинг кількох маршрутів і failover | Хочете отримувати резервування й перемикання як частину сервісу |
Якщо більшість ваших відповідей опиняється у правій колонці, купівля — раціональний вибір за замовчуванням. Якщо в лівій — будуйте, але закладайте бюджет на другий рік, а не лише на перший реліз.
Як ухвалити рішення для вашої команди
Рішення build vs buy messaging простіше ухвалити, коли ви перевіряєте шлях купівлі на реальних вимогах, а не на припущеннях. API-документація BSG показує, що включає production-інтеграція — від надсилання до callback-ів зі статусами. Якщо ви хочете пройтися своїми обсягами, країнами та комплаєнс-вимогами з людьми, які щодня експлуатують цю інфраструктуру, поговоріть з командою BSG. Ми допоможемо визначити, які частини варто будувати, а які — купувати.
FAQ
Чи дешевше збудувати власну SMS-платформу?
Зазвичай ні, якщо тільки messaging не є вашим основним бізнесом, а обсяги не виправдовують прямих угод з операторами. Власна розробка не прибирає плату за повідомлення — вона додає до неї витрати на розробку, підтримку, чергування й захист від фроду. У більшості рішень build vs buy SMS корисно порівнювати сукупну вартість володіння, а не ціну за повідомлення.
Коли компанії варто обрати CPaaS замість власної розробки?
Обирайте CPaaS, коли messaging підтримує ваш продукт, а не є ним, коли ви надсилаєте повідомлення в кілька країн чи каналів або коли production-рівень доставки потрібен швидко. У таких випадках маршрутизація, резервування та комплаєнс-робота провайдера коштують менше, ніж їх відтворення всередині компанії.
Чи можна почати з CPaaS і пізніше перейти на власне рішення?
Так, і це поширений сценарій. Тримайте логіку messaging за внутрішнім інтерфейсом, щоб провайдера можна було замінити, і не зашивайте специфічні функції провайдера в код продукту. Так опція власної розробки лишається відкритою без затримки запуску.
Чи робить використання CPaaS вас відповідними GDPR?
Ні. Ваша компанія лишається відповідальною за згоди та правову підставу кожного повідомлення, а CPaaS діє як обробник даних. Хороший провайдер спрощує комплаєнс завдяки договору про обробку даних, сертифікатам і записам, готовим до аудиту, але не замінює ваших власних зобов'язань.
