IronBase за два дні на Bubble MCP + Claude: кейс шипінгу, не доказ що MCP уже в прод

Засновник маркетплейсу IronBase написав на форумі Bubble, що підключив Bubble MCP до Claude і закрив низку завдань менш ніж за два дні. Свого часу він витратив до 10 годин. Ручна збірка, за його оцінкою, зайняла б 30–40 годин. Спільнота цей кейс активно обговорює, і я розумію чому. Якщо ти фаундер без технічного бекграунду, хочеться взяти такий інструмент і за вихідні запустити MVP, перевірити гіпотезу чи показати прототип інвесторам.

Після того як Bubble на початку жовтня 2026 року анонсував бету MCP, це перший настільки помітний приклад шипінгу. Але я б розділив дві речі. Одна — реальне прискорення перевірки гіпотез. Інша — ризиковані припущення, які не можна сліпо переносити у свій діючий проєкт. Про це окремо: Bubble September 2026 Update: що.

Що насправді дає Bubble MCP при створенні MVP

Bubble запустив офіційний MCP у статусі бети в жовтні 2026 року. Він для досвідчених білдерів, які хочуть працювати з редактором через зовнішніх агентів: Claude, Claude Code чи Codex. Для вайбкодінгу головне в підході «bring your own agent» те, що логіку, елементи та зв'язки можна генерувати в діалозі. Годинами клікати по меню вже не треба. Схожий розбір: Codex CLI stable і 28-day.

Засновник IronBase дав Claude права на запис і віддав йому пакетні завдання та доопрацювання інтерфейсу: кандидатські метчі, скриньку повідомлень, допоміжні операції. Швидкість тут дає сайдкар. Агент складає рутинні компоненти, а людина думає про бізнес-логіку.

Жорсткі обмеження безпеки: чому це не «зелене світло» для продакшену

Якщо ти будуєш свій перший продукт, спершу прочитай, які рамки Bubble сам описує в документації:

• MCP не робить деплой: агент не може опублікувати зміни на Live. Реліз у прод робить тільки людина через редактор Bubble.
• Запис даних — лише в середовищі розробки: MCP пише тільки в Development DB. Живі дані користувачів на Live агент напряму не перезапише.
• Агент не зливає гілки і не читає системні логи: архітектурний контроль і моніторинг лишаються за розробником.
• Офіційна рекомендація Bubble: перші підключення й тести роби на тестовому застосунку (test app), а не на продукті, який уже працює.

І ще одне. Кейс IronBase — це оцінка одного засновника (self-reported timeline). Це не аудит безпеки і не гарантія стабільності від команди Bubble. Заощаджені години він порахував сам, у своїх конкретних умовах. Новачок не обов'язково отримає ті самі цифри.

Що нетехнічний засновник може повторити вже сьогодні

Якщо ти перевіряєш ідею і хочеш зібрати MVP за кілька днів через вайбкодінг, я б тримався такого протоколу:

1. Експериментуй на ізольованій копії. Під перші сесії з Claude через MCP створи окремий тестовий застосунок у Bubble.
2. Фіксуй точки відновлення (Savepoints). Перед кожною серією змін дай агенту команду створити точку збереження або зроби її вручну. Якщо генерація піде не туди, повернешся до робочого стану в один клік.
3. Працюй короткими ітераціями. Не проси ШІ побудувати весь застосунок одразу. Давай точкові завдання: окрема група полів, окрема сторінка.
4. Перевіряй в Editor та Issue Checker. Перед деплоєм для перших клієнтів відкрий візуальний редактор Bubble, переглянь згенеровані елементи й виправ усі помилки, які знайшов вбудований валідатор.

Для багатьох стартапів швидкість запуску MVP вирішує все. Але дані перших користувачів не повинні за неї платити. Я б використовував Claude і Bubble MCP як сайдкар на чернетках, а контроль над деплоєм залишав би за собою. Схожий розбір: Buildprint (форум 19 вер.): Claude/Codex.