У XIX столітті ткачі ламали верстати, боячись знецінення свого ремесла. А сьогодні програмісти не хочуть використовувати no-code платформи, сприймаючи їх як загрозу професії.
Але прогрес не знищує майстрів, а звільняє їх від рутинної ручної роботи. Працюючи у фінтех-сфері протягом 13 років, я помічав, як із розвитком no-code платформ скепсис розробників підживлюють міфи навколо цієї технології. Розберемо деякі з них.
Зміст
No-code довго вважався інструментом для лендінгів та простих завдань. У 80-х так і було. Але сьогодні no-code підхід використовують компанії, що обслуговують сотні мільйонів клієнтів.
Наприклад, Netflix координує процес виробництва контенту через Airtable — no-code платформу для управління даними. Кастинги, локації, бюджети, річні маркетингові кампанії — усе це поєднали в одну систему без жодного рядка коду. Регіональні команди по всьому світу працюють зі спільними даними в реальному часі та самі будують потрібні їм процеси.
«Несерйозною» розробку на no-code вважають ще й з іншої причини. Розробники впевнені — і я бачив це зсередини — що вони повинні страждати. Якщо створюєш складну систему за пару місяців без перепрацювання, крові й поту — це не справжня робота.
Існує думка, що no-code не вистачає унікальності. Це справедливо, якщо ви хочете випустити продукт на кшталт Photoshop — професійний інструмент з вузьким функціоналом, який потребує доступу до низькорівневого програмування. Але для бізнес-орієнтованих сервісів no-code платформи підходять чудово.
У 2014 році стартап Dividend Finance, який розробляв онлайн-платформу кредитування у сфері відновлюваної енергетики, створив робочий MVP на no-code платформі Bubble всього за шість тижнів. Команда швидко вивела продукт на ринок і заклала основу платформи, яку можна було масштабувати. Протягом наступних п’яти років Dividend Finance обробив кредитів на суму понад $1 млрд.
No-code — не «чарівна пігулка» для всіх. Але якщо вам не потрібне нішеве рішення, він принесе велику користь — дозволить заощадити на дорогоцінній ручній роботі IT-команди та прискорити запуск сервісу.
Наступне переконання — “якщо захочеться змінити провайдера no-code, розрив зруйнує ваш сервіс”. Це справедливо лише частково.
Використовуючи no-code платформу, ви зазвичай не володієте правом власності на ПЗ і залежите від ліцензії вендора. Ступінь залежності варіюється.
Тобто повне звільнення від одного типу залежності на практиці означає перехід до іншого. Виходить парадокс: тільки отримавши “свободу” від платформи, ви починаєте більше залежати від розробників або аутсорс-компанії. Навіть при власній розробці ви опираєтеся на open source‑технології, які можуть змінювати ліцензійну модель або переходити на комерційні рейки. Один із нещодавніх прикладів — у 2024 році Redis змінила ліцензійну модель і закрила можливість, яка дозволяла компаніям брати звідти безплатний код, “загортати” у власний сервіс і продавати клієнтам.
Тому міф скоріше — це абсолютна незалежність в IT. Для компаній поза технологічним сектором часто безпечніше працювати в тандемі з вендором — головне вибрати надійного партнера.
Наріжний камінь неприйняття no-code платформ — переконання, що їхні команди не пропрацьовують безпеку так ретельно, як це роблять компанії у власних продуктах.
Тут не погоджуся. У надійного провайдера завжди є команда з кібербезпеки, яка знає можливі вектори атак. Компоненти, з яких зібрана система, перевірені вздовж і впоперек. Самі платформи також проходять перевірки за міжнародними стандартами безпеки. Наприклад, PowerApps сертифікована за ISO/IEC 27001 і проходить незалежний аудит SOC 2 Type 2.
Інша справа, що деякі аспекти безпеки залежать від специфіки бізнесу клієнта. Наприклад, логіка блокування транзакцій з ненадійної IP-адреси — це специфічна бізнес-логіка банку, а не платформи.
Безпека — спільна зона відповідальності і вендора, і клієнта.
У дискусіях про технологію я чув тезу, що no-code платформи підходять для невеликих проєктів, але перестають справлятися з навантаженням зі зростанням масштабів. І в більшості випадків це дійсно так: багато платформ спочатку не проєктувалися під високі навантаження.
Однак має значення архітектурний підхід. Наприклад, якщо система побудована на cloud-native архітектурі та розрахована на масштабування, це усуває обмеження. Хмарні провайдери роблять масштабування автоматичним. Навіть якщо зазвичай у вас 10 тисяч користувачів, а прийшов мільйон — сервіс не впаде.
Інша сторона масштабування — розширення логіки. Вимоги користувачів можуть стати надто нестандартними. Тут спрацює гібридний підхід: багато платформ дозволяють додавати код там, де готових компонентів виявляється недостатньо.
Технологія no-code не є рішенням, яке підійде абсолютно всім. Ось декілька напрямів, де краще покладатися на класичну розробку:
No-code — це інструмент, з яким можна вирішити 90% завдань бізнесу, а для решти 10% — використовувати код. Так само як індустріалізація не змогла замінити 100% майстрів, так і no-code не замінить 100% розробників.
Ми вже увійшли у стан «no-code» навіть у класичній розробці — за нас пише код AI-агент. Саме питання “хто пише код” — розробник, AI чи платформа — для бізнесу стає другорядним. На перший план виходять швидкість запуску, стабільність, масштабованість та безпека. І найкращим рішенням стає поєднання двох підходів: код — там, де це виправдано, no-code — скрізь, де можливо.
Контент сайту призначений для осіб віком від 21 року. Переглядаючи матеріали, ви підтверджуєте свою відповідність віковим обмеженням.
Cуб'єкт у сфері онлайн-медіа; ідентифікатор медіа - R40-06029.