Low-code чи custom-розробка: як обрати без переплати та технічного боргу

Компанії потрібно запустити кабінет для партнерів, автоматизувати погодження заявок або швидко перевірити нову послугу. Є два шляхи. Перший — зібрати рішення на low-code-платформі за кілька тижнів із готових блоків. Другий — спроєктувати власну систему й отримати повний контроль над логікою, даними та інтерфейсом.

Питання low-code чи custom-розробка часто обговорюють як битву «дешево проти якісно», але це хибна рамка. Low-code — не дешева заміна програмістів, а custom — не обов'язково багаторічний проєкт на мільйони. Це різні інструменти, і вибір залежить від того, наскільки процес критичний, які потрібні інтеграції і як він змінюватиметься через рік-два. Розберемо вибір на трьох типових задачах.

Коротко про категорії

Low-code платформа дозволяє будувати інтерфейси й процеси з готових компонентів, візуальних схем і конекторів. Код пишуть лише там, де стандартних можливостей бракує: Microsoft Power Apps, Retool, OutSystems, Mendix, а для автоматизації процесів — n8n, Make чи Zapier.

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

Задача 1. Кабінет партнерів на 300 дилерів

Партнери мають бачити свої ціни, залишки, історію замовлень і документи. Дані лежать в ERP, доступ потрібен ззовні, кожен бачить лише себе.

Low-code тут закриває інтерфейс і авторизацію за кілька тижнів, але швидко впирається в дві речі: ліцензування за кожного зовнішнього користувача та обмеження на кількість запитів до ERP. Для 300 партнерів вартість платформи може перевищити вартість розробки вже на другий рік.

Практичний висновок: якщо кабінетом користуються десятки внутрішніх людей — беріть low-code. Якщо сотні зовнішніх — рахуйте повну вартість володіння на три роки, і часто виграє custom або гібрид, де backend свій, а адмінка на платформі.

Задача 2. Погодження заявок усередині компанії

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

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

Задача 3. Конфігуратор продукту з власною логікою цін

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

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

Порівняння підходів

Як порахувати вартість чесно

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

Для custom у ту саму таблицю ідуть розробка, хостинг, тестування, моніторинг і розвиток. Часто виявляється, що на горизонті одного року дешевший low-code, на горизонті трьох — уже custom. Саме тому рішення приймають за TCO, а не за ціною запуску.

Перевірка платформи до старту

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

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

Гібрид — частіше за все правильна відповідь

Low-code і custom не обов'язково протиставляти. Поширена модель: критична бізнес-логіка та дані живуть у власному backend, а внутрішня адмінпанель чи звітність збирається на low-code поверх нього через API. Інший сценарій — MVP на платформі перевіряє гіпотезу, після чого найцінніша частина переноситься в custom-продукт.

Головне — заздалегідь визначити межі. Платформа не повинна стати випадковим сховищем критичної логіки, яку неможливо перенести. Про те, як розпізнати момент, коли готове рішення перестає справлятися, ми писали в статті «Коли інтернет-магазин переріс CMS»: більшість ознак актуальні й для внутрішніх систем. А якщо мова про e-commerce із кількома каналами, до порівняння варто додати ще й headless-архітектуру.

П'ять запитань перед рішенням

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

Якщо на більшість відповідей ви кажете «типово, небагато, підтримує» — беріть low-code. Якщо хоча б дві відповіді про унікальність, критичність або масштаб — закладайте custom чи гібрид.

Часті запитання

Чи можна перенести систему з low-code у custom пізніше?

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

Low-code — це безпечно?

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

Що дешевше на горизонті трьох років?

Для внутрішнього інструменту на кілька десятків користувачів зазвичай low-code. Для системи з сотнями зовнішніх користувачів, складними інтеграціями чи високим навантаженням часто вигідніший custom.

Скільки триває MVP на low-code?

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

Якщо процес типовий і потрібно швидко перевірити цінність, low-code може бути найкращим стартом. Якщо система визначає продукт, має складні інтеграції або високі ризики, власна архітектура дає більше контролю. GL.ua може провести discovery, зібрати прототип і допомогти обрати підхід без прив'язки до одного інструмента — детальніше про наші послуги з розробки сайтів і систем.