Обзор Bubble (проверено в августе 2026): возможности, цены и ограничения

Bubble полностью оправдывает себя для создания кастомных веб-SaaS или маркетплейсов, когда скорость развертывания готового фулстека важнее прямого владения кодом. Запуск работающего веб-приложения стоит от $29 в месяц при ежегодной оплате, но итоговая целесообразность зависит от расхода Workload Units, потребности в третьем редакторе, нативных мобильных функций или планов по дальнейшей миграции.

Что на самом деле представляет собой Bubble: детальный обзор платформы

Bubble — это визуальная платформа для разработки приложений, объединяющая интерфейс, базу данных, серверную логику, API-подключения, хостинг и деплой внутри единой управляемой экосистемы. Вместо того чтобы собирать фронтенд-фреймворк, бэкенд-сервис, базу данных и провайдера хостинга по отдельности, вы строите экраны из визуальных элементов, моделируете данные, которые они считывают и записывают, и связываете действия пользователей с рабочими процессами (workflows). Этот интегрированный стек — главное преимущество Bubble и одновременно его фундаментальный компромисс: устраняя необходимость в сборке инфраструктуры, он делает последующий перенос продукта на другой стек крайне сложным.

Bubble предоставляет весь этот стек в рамках одного редактора и единой подписки на проект.

Краткое сравнение Bubble с альтернативами

Цены ниже проверены на официальных страницах тарифов каждого сервиса по состоянию на 3 August 2026. Стартовая цена сама по себе не делает эти инструменты идентичными, поскольку FlutterFlow и WeWeb позволяют выносить инфраструктуру за пределы конструктора, тогда как Bubble включает в себя управляемый бэкенд.

Итоговый выбор зависит от пяти критериев: какую долю продакшн-стека берет на себя платформа, насколько хорошо она справляется со сложной логикой, сколько стоит живой проект до и после учета потребления, какие задачи безопасности остаются на создателе и можно ли увести приложение с платформы. Bubble лидирует по первым двум пунктам и уступает по последнему.

Более широкий список инструментов разобран в сравнении лучших no-code конструкторов приложений. Для текущего выбора вывод прост: Bubble выигрывает, когда ключевая ценность — это интегрированный кастомный стек; платформа проигрывает, если в приоритете право собственности на код, зрелая нативная мобильная разработка или строго ограниченный портал.

Кому подходит Bubble, а кому стоит выбрать другой инструмент

Bubble идеален для фаундера, которому нужна индивидуальная бизнес-логика без найма отдельных специалистов по фронтенду, бэкенду и инфраструктуре. Двусторонний маркетплейс — самый наглядный пример: покупатели, продавцы, карточки товаров, бронирования, платежи, уведомления и панель администратора работают в рамках одного проекта. Другой сильный сценарий — B2B SaaS с аккаунтами, уровнями доступа, дашбордами, задачами по расписанию и внешними API. Однако такая глубина избыточна для каталога-директории, стандартного клиентского кабинета или мобильного consumer-продукта.

Bubble становится удачным выбором при соблюдении следующих условий:

• Продукт представляет собой кастомное веб-приложение, а не контентный сайт.
• Ценность продукта завязана на связях данных, правах доступа и многошаговых процессах.
• Фаундер или компактная команда хотят быстро выпускать итерации, не администрируя нескольких инфраструктурных провайдеров.
• Управляемый хостинг предпочтительнее владения исходным кодом.
• Команда готова регулярно отслеживать privacy rules и потребление ресурсов (workload).

Откажитесь от Bubble, если хотя бы одно из следующих требований является критичным.

Выбирайте FlutterFlow для нативного мобайла и владения кодом

FlutterFlow — более надежный выбор по умолчанию, когда iOS и Android выступают основным продуктом, а не дополнительными экранами. Его тариф Basic за $39 в месяц включает скачивание исходного кода и APK, тестирование на локальных устройствах, публикацию веб-версии на собственном домене и публикацию в магазинах приложений в один клик. Разработчик получает реальную кодовую базу приложения, развитие которой можно продолжить вне FlutterFlow, чего Bubble предоставить не может.

В эту стоимость не входит готовый бэкенд из коробки, аналогичный Bubble. Для Firebase, Supabase или альтернативного решения потребуется отдельно спроектировать модель безопасности и данных. Выбирайте FlutterFlow, если такое разделение выгодно из-за мобильной специфики или вероятной передачи проекта классической команде разработки.

Выбирайте WeWeb, если план смены платформы нужен с первого дня

WeWeb — более гибкое решение для веб-приложений с точки зрения переносимости. План Essential стоит $20 в месяц и включает экспорт кода, селф-хостинг и синхронизацию с GitHub; хостинг только фронтенда через WeWeb Cloud начинается от дополнительных $13 в месяц. Команда также может подключить внешний бэкенд или перейти на более высокий уровень WeWeb Cloud.

Такое разделение требует больше архитектурных решений еще до запуска, но фронтенд и бэкенд оказываются не так жестко привязаны к одному вендору. Выбирайте WeWeb для кастомного веб-интерфейса, если селф-хостинг или передача проекта разработчикам — это осязаемая задача, а не отдаленная теория.

Выбирайте Softr для стандартного структурированного портала

Softr позволяет быстрее запустить клиентский портал, партнерский хаб или внутреннее приложение на базе таблиц, чья структура изначально ясна. Тариф Basic за $49 в месяц при ежегодной оплате включает 20 пользователей приложения, 50,000 записей в Softr Database и 2,500 действий в рабочих процессах. Понятные фиксированные лимиты упрощают принятие решения по сравнению с прогнозированием рабочей нагрузки в Bubble.

Расплачиваться приходится гибкостью. Если портал трансформируется в маркетплейс с нестандартными статусами транзакций, сложными правами доступа или нетипичными пользовательскими сценариями, Bubble предоставит несоизмеримо больше возможностей. Если же задача ограничивается порталом, детальный редактор Bubble лишь добавит трудозатрат без видимой пользы.

Возможность 1: визуальный дизайн интерфейса без отдельного фронтенда

Визуальный редактор Bubble раскрывает свой потенциал, когда интерфейс должен динамически реагировать на состояние системы, а не просто отображать статические страницы. Он поддерживает шаблоны, готовые блоки, переиспользуемые элементы (reusable elements), адаптивную верстку на базе CSS flexbox и конвертер из Figma. Переиспользуемый элемент — это компонент вроде навигационной панели или карточки бронирования, правки в котором синхронно применяются везде, где он размещен.

Возьмем для примера подписочный B2B-сервис. Публичная страница с тарифами, дашборд клиента, настройки профиля, счетчик использования ресурсов и панель администратора требуют общего дизайн-кода, но каждый экран обращается к разным данным пользователя и биллинга. Bubble позволяет настраивать эти состояния и условия непосредственно в среде компоновки интерфейса.

1. 1

   Сформируйте дизайн-систему повторяющихся элементов

   Задайте цвета, стили типографики, отступы, навигацию, кнопки, поля форм и компоненты учетных записей до отрисовки отдельных экранов. Это защитит от визуального хаоса по мере перерастания прототипа в полноценный продукт.

2. 2

   Привяжите интерфейс к состоянию системы

   Свяжите индикатор тарифа, шкалу лимитов, этап онбординга и уровни доступа с полями базы данных. Условное отображение (conditional visibility) покажет баннер апгрейда одной компании и функции суперадмина другой на одной и той же странице без ее дублирования.

3. 3

   Продуманно настройте брейкпоинты

   Поведение адаптивного flexbox требует контроля переноса строк, минимальной ширины блоков, переполнения (overflow) и приоритета контента. Редактор избавляет от ручного написания CSS, но не от понимания правил верстки.

4. 4

   Превратите самый сложный экран в переиспользуемый компонент

   Соберите наиболее нагруженный дашборд или экран транзакции до того, как шлифовать маркетинговые страницы. Если тяжелые сценарии продукта тяжело реализуются в Bubble, этот архитектурный сигнал важно выявить на старте.

Ограничения дают о себе знать, когда дизайн требует кастомного графического движка, экстремальной производительности на стороне клиента или экосистемы компонентов, которую Bubble не способен повторить нативно. Плагины расширяют возможности, но проект остается внутри модели рендеринга и деплоя Bubble. Для сложного корпоративного сервиса данных это допустимо. Для команды, строящей продукт, где сам фронтенд выступает ключевым техническим новшеством, это серьезный стоп-фактор.

Возможность 2: встроенная база данных, требующая внимания к безопасности

База данных Bubble снимает проблему интеграции сторонних хранилищ, но не отменяет грамотного проектирования связей и уровней доступа. Платформа берет на себя учетные записи пользователей, кастомные типы данных и поля, поиск, управление загруженными файлами, массовые операции с записями, privacy rules, API-соединения и возможность открывать собственное приложение как API.

Маркетплейс хорошо иллюстрирует эту ценность. Продукту нужны таблицы пользователей, объявлений, доступных слотов, бронирований, транзакций, отзывов и обращений в поддержку. Каждая запись должна быть жестко привязана к аккаунту, а каждая роль должна видеть только свой срез информации. Нахождение этой структуры рядом с визуальными процессами сокращает путь от изменения поля до корректировки экрана, который с ним работает.

Безопасная архитектура выстраивается до загрузки реальных данных:

1. 1

   Явно разграничьте права владения объектами

   Добавьте в каждую приватную запись поле прямого владельца, организации или роли, чтобы правила доступа (privacy rules) могли быстро его проверить. Избегайте длинных цепочек связанных записей при валидации, поскольку Bubble накладывает ограничения на многоуровневые поисковые запросы в privacy rules.

2. 2

   Создавайте новые типы данных как приватные

   Согласно документации Bubble, новые публичные типы данных по умолчанию доступны конечным пользователям. Сразу помечайте конфиденциальные типы приватными и настраивайте, что именно могут находить или просматривать владельцы, сотрудники и внешние гости, до заливки клиентской базы.

3. 3

   Защищайте как записи, так и прикрепленные файлы

   Скрыть поле ссылки на файл в интерфейсе недостаточно. Настройте загрузчик как приватный, привяжите файл к защищенной записи и включите проверку прав на вложения через privacy rules.

4. 4

   Запустите проверку безопасности и протестируйте сценарии

   Встроенный дашборд подсветит отсутствующие privacy rules, открытые поля, небезопасные параметры API и ошибки с секретными ключами. Он не способен просчитать вашу бизнес-логику целиком, поэтому ручная проверка неавторизованных путей доступа строго обязательна.

Последний нюанс критичен для продакшна. Инфраструктура Bubble защищена контролем SOC 2 Type II, регламентом GDPR DPA, шифрованием TLS при передаче и AES-256 в покое через RDS, а также защитой от DDoS. Все это закрывает инфраструктурный уровень. Но эти механизмы не спасут, если один продавец увидит выплаты другого только потому, что разработчик оставил тип данных публичным.

Возможность 3: воркфлоу, API и прием платежей в общем слое логики

Движок рабочих процессов (workflows) — главная причина предпочесть Bubble простым конструкторам порталов. Воркфлоу запускаются по действию пользователя, по расписанию, по изменению данных в базе, вызывают плагины и API, принимают оплату через такие шлюзы, как Stripe, и публикуют собственные эндпоинты приложения.

Возьмем платформу бронирования услуг. Одно нажатие кнопки клиентом может потребовать проверки доступности времени, создания бронирования, запуска транзакции, уведомления исполнителя, планирования напоминания и вывода данных в админку. В Bubble эти шаги остаются наглядной цепочкой действий, а не размазываются по клиентскому коду, серверным функциям и внешним интеграторам.

Правильный подход изолирует мгновенный отклик интерфейса от тяжелых фоновых задач:

1. 1

   Проверяйте условия до записи данных

   Убедитесь, что слот свободен, а текущий пользователь обладает правом на бронь. Визуальный воркфлоу — это полноценная логика, поэтому условия должны быть четко зафиксированы.

2. 2

   Создавайте основную запись за один шаг

   Запишите бронирование с понятным статусом и идентификатором транзакции. Лишние перезаписи и повторный поиск увеличивают вероятность сбоя и расход рабочей нагрузки.

3. 3

   Делегируйте медленные задачи бэкенду

   Отправку чеков, оповещений исполнителям, постановку напоминаний и сопутствующие задачи выносите в запланированные или backend workflows, чтобы пользователь не ждал ответа внешних служб.

4. 4

   Открывайте только необходимые эндпоинты

   Если бухгалтерии или сторонней CRM нужны данные о бронированиях, создайте точечный API workflow с жесткой авторизацией вместо выдачи прямого доступа к базе данных.

Именно здесь ценообразование Bubble превращается в архитектурную задачу. Workload Units (WU) суммируют серверные ресурсы, затраченные на поиски, выполнение воркфлоу, вызовы API и сопутствующие операции. Страница, бесконечно повторяющая тяжелый поиск по всей базе для каждой строки списка, снаружи выглядит рабочей, но сжигает ресурсы куда быстрее, чем оптимизированный запрос или кешированные значения. Bubble избавляет от настройки серверов, но делает чистоту архитектуры процессов частью ежемесячного счета.

Поэтому главный тест жизнеспособности идеи проводится не на лендинге. Соберите самый тяжелый процесс на тарифе Free, отследите динамику расхода WU и проверьте число затрагиваемых сервисов и запросов к базе. Это не покажет будущий трафик со 100% точностью, но сразу продемонстрирует экономичность архитектуры до того, как придут первые пользователи.

Возможность 4: нативный мобайл делит с вебом бэкенд, но уступает в зрелости

Bubble позволяет компилировать нативные приложения под iOS и Android, однако мобильный редактор платформы сохраняет статус beta. Он базируется на React Native, поддерживает push-уведомления, геолокацию, доступ к камере, предварительный просмотр на устройствах через приложение BubbleGo и процесс публикации в App Store и Google Play.

Наиболее практичный сценарий здесь — создание мобильного компаньона к существующему веб-сервису. Сервисная компания может оставить планирование, аналитику, управление аккаунтами и биллинг в веб-интерфейсе, а выездным мастерам выдать мобильное приложение для навигации, съемки фотоотчетов и получения пушей. При размещении в рамках одного проекта база данных, логика воркфлоу, интеграции по API и лимиты нагрузки являются общими.

Единый бэкенд исключает дублирование правил, но приводит к суммированию трафика из веба и мобайла. Пакет Starter при годовой оплате стоит $59 в месяц против $29 только за Web и $42 только за Mobile. Добавление мобильной среды к веб-тарифу Starter увеличивает чек на $360 в год. На тарифе Growth эта разница составляет уже $1,080 в год, а на тарифе Team — $2,400 в год.

Статус beta нельзя игнорировать. Сама документация Bubble отмечает, что поддержка ряда воркфлоу, плагинов, офлайн-режима, покупок внутри приложений (IAP), диплинков и функций редактирования через ИИ еще дорабатывается. Если веб-бизнесу требуется вспомогательный мобильный инструмент, этот риск оправдан. Если создается consumer-стартап с упором строго на мобильные устройства, надежнее выбрать FlutterFlow или классическую нативную разработку, пока все нужные функции не выйдут из статуса беты.

Точные тарифы Bubble в августе 2026 года

Тарифы Bubble фиксированы на уровне планов, но гибки в части фактического использования. Подписка приобретается на каждый отдельный проект с разделением на Web-only, Mobile-only и Web + Mobile. Актуальная сетка цен проверена по состоянию на 3 August 2026; годовые цены указаны в пересчете на стоимость одного месяца:

План Free предназначен исключительно для разработки, это не бесплатный продакшн. В него включены 50K единиц нагрузки (WU) в месяц, один редактор, шесть часов хранения логов сервера, 0.5 GB хранилища файлов и 200 записей (things) в базе данных. Для подключения собственного домена, запуска рабочего сайта, деплоя в TestFlight или релиза в сторы потребуется платный тариф.

Starter рассчитан на запуск проекта. Он дает 175K WU, одного редактора и два дня логов. При оплате за год это $348 в год за Web-only, $504 за Mobile-only или $708 за комбо-версию.

Growth ориентирован на командную работу. Он содержит 250K WU, двух редакторов, 10 веток версионирования (branches) и 14 дней логов. Стоимость Web + Mobile вырастает с $59 на Starter до $209 на Growth — разница в $150 в месяц ради дополнительных 75K WU, инструментов совместной работы и расширенных возможностей. Если повышать план только ради нагрузки, дополнительные мощности обойдутся в $2 за каждые 1K WU, что экономически нецелесообразно.

Team включает 500K WU, пять редакторов, 25 веток и 20 дней логов. Необходимость подключить третьего разработчика приводит к резкому скачку расходов, так как лимит Growth — два редактора. Переход проекта Web + Mobile с тарифа Growth ($209) на Team ($549) добавляет $340 в месяц, или $4,080 в год, хотя и дает больше нагрузки, веток и функций.

Enterprise рассчитывается по запросу. Он предлагает кастомный объем WU, выбор локации серверов, выделенные вычислительные мощности, персональную техподдержку и оплату по счету или через ACH.

Доплаты за перерасход и пакеты рабочей нагрузки (WU)

Базовая стоимость перерасхода на платных тарифах составляет $0.30 за каждые 1K WU. Проекты на тарифах Starter, Growth и Team могут превентивно докупать пакеты мощностей, а дополнительное место под файлы стоит $3 за каждые 100 GB в месяц. Bubble присылает уведомления о потреблении на отметках 75% и 100%, кроме того, в кабинете можно принудительно отключить овердрафт.

Текущие пакеты рабочей нагрузки при ежегодной оплате:

• Tier 1: 200K WU за $26 в месяц, далее $0.15 за каждые 1K WU перерасхода.
• Tier 2: 750K WU за $89 в месяц, далее $0.14 за каждые 1K WU перерасхода.
• Tier 3: 2.5M WU за $269 в месяц, далее $0.12 за каждые 1K WU перерасхода.
• Tier 4: 6M WU за $539 в месяц, далее $0.10 за каждые 1K WU перерасхода.

Отсюда следует практическое правило: основной тариф стоит повышать ради добавления редакторов, веток версионирования, глубины логов, лимитов мобильных сборок и продуктовых фич. Подключать пакеты нагрузки (WU Tiers) нужно под прогнозируемый рост трафика сверх лимитов плана. Повышение глобального тарифа только ради серверных мощностей приводит к лишним переплатам.

Ключевые ограничения платформы, влияющие на выбор

Слабые стороны Bubble проявляются уже после запуска: они затрагивают вопросы миграции, безопасности, операционных расходов и масштабирования штата. Сами по себе они не перечеркивают достоинства сервиса, но для ряда задач служат прямым поводом отказаться от него.

1. Отсутствие экспорта исходного кода

Приложения жестко привязаны к управляемой инфраструктуре Bubble; экспорт исходного кода платформой не предусмотрен. Базу данных можно выгрузить, а API позволяет отдавать данные во внешние системы, однако визуальный интерфейс и сценарии логики нельзя просто забрать в виде привычного репозитория и захостить на собственном сервере.

С этим можно мириться, пока облачная инфраструктура закрывает потребности бизнеса. Но это недопустимо, если планируется продажа компании, развертывание в изолированном контуре регулятора (on-premise) или поэтапная передача проекта инхаус-разработчикам. WeWeb и FlutterFlow требуют больше инженерных навыков на старте, но изначально предлагают понятный путь вывода кодовой базы наружу.

2. Зависимость ежемесячных расходов от оптимизации архитектуры

Модель Workload Units не делает платформу безусловно дорогой, но ее сложно оценить заранее, пока не ясна специфика поведения пользователей и паттерны чтения данных. Слишком широкие поисковые запросы, зацикленные воркфлоу и перегруженные страницы быстро превращают неоптимальный код в увеличивающийся ежемесячный чек.

Решение здесь сугубо прикладное: спроектируйте критические процессы в первую очередь, анализируйте дашборд потребления ресурсов, настраивайте алерты, фиксируйте лимиты расходов и докупайте пакеты WU на основе реальной статистики. Если команда не готова постоянно держать руку на пульсе архитектуры, платформа с отдельным внешним бэкендом и классической схемой оплаты серверов будет гораздо понятнее.

3. Безопасность данных ложится на плечи создателя

Документация Bubble предупреждает: новые публичные типы данных доступны конечным пользователям, пока они не ограничены через privacy rules. Тариф Starter находит лишь базовые уязвимости, а углубленные проверки (риски утечки БД, скомпрометированные токены API, незащищенные backend workflows) требуют тарифа Growth или выше. Часть инструментов аудита безопасности пока недоступна для мобильных сборок.

Дашборд безопасности полезен, но сам вендор указывает, что автоматика не видит всех ошибок архитектуры. Создатели проекта обязаны самостоятельно перепроверять права ролей, авторизацию в API, изоляцию файлов, тестовые окружения и публичные эндпоинты. Для чувствительных данных эти трудозатраты необходимо закладывать в бюджет точно так же, как работу бэкенд-инженера.

4. Дорогое масштабирование рабочих мест редакторов

Тариф Starter допускает одного редактора, а Growth — двух. Третий специалист вынуждает переходить на план Team, из-за чего годовая подписка на Web + Mobile взлетает с $209 до $549 в месяц. Прирост лимитов WU, веток и глубины логов ощутим, но для небольшой команды такая переплата только ради еще одного рабочего места часто оказывается чрезмерной.

Об этом стоит помнить еще до привлечения внешних подрядчиков. Сразу определите, кому действительно нужен доступ в редактор, кто может смотреть результаты без него и потребуется ли параллельная работа над проектом в разных ветках. Во WeWeb и FlutterFlow совместная разработка тоже платная, но предельная стоимость каждого нового места там прозрачнее.

5. Короткий период хранения серверных логов на базовых тарифах

Starter хранит логи сервера всего два дня, а Growth — 14 дней. Баг, о котором клиент сообщит спустя неделю, на тарифе Starter восстановить по логам уже невозможно. План Team расширяет этот период до 20 дней, тогда как бесплатный тариф хранит логи лишь шесть часов.

Для боевого SaaS критически важные события логичнее выгружать во внешние системы мониторинга и аудита, не надеясь на штатное окно хранения. На этапе прототипа это незаметно, но при разборе запоздалых жалоб реальных клиентов создает серьезные трудности.

6. Нативный мобайл запущен, но все еще находится в бете

Bubble компилирует мобильные приложения и дает доступ к ключевым возможностям смартфонов — утверждения о том, что сервис работает только в вебе, устарели. Однако статус публичной беты накладывает отпечаток на долгосрочные мобильные планы. Перед стартом проекта детально проверьте, как в бета-версии реализованы нужные вам плагины, офлайн-режим, платежи внутри приложений, диплинки и функции сборки интерфейса через нейросети.

Вердикт: когда стоит использовать Bubble

Bubble заслуживает однозначной рекомендации для кастомных веб-SaaS, маркетплейсов и сложных сервисов, когда один-два создателя хотят быстро собрать интерфейс, базу и логику в одном окне. Стартовая цена $29 в месяц за Web-only — крайне доступный вход для готового фулстека, а план Free дает проверить архитектуру до оплаты подписки.

Платформа перестает быть оптимальным выбором, когда критично право собственности на исходный код, продукт ориентирован строго на мобильные устройства или в штате планируется более двух редакторов. Также сервис не подойдет командам, где некому отвечать за настройку privacy rules и мониторинг расхода ресурсов — это не опциональные задачи, а ежедневная часть поддержки продукта на Bubble.

Используйте следующий четкий алгоритм:

• Выбирайте Bubble, если строится нестандартный веб-сервис, встроенный бэкенд экономит месяцы разработки, команда способна оптимизировать логику под лимиты мощностей, а управляемый хостинг важнее гипотетической смены платформы.
• Выбирайте FlutterFlow, если архитектура строится вокруг нативных приложений под iOS/Android или требуется выгрузка кодовой базы.
• Выбирайте WeWeb, если нужен кастомный веб-продукт, но критически важны селф-хостинг, экспорт кода или независимый собственный бэкенд.
• Выбирайте Softr, если задача укладывается в типичный портал или внутреннюю базу компании, а текущие лимиты пользователей и записей вас полностью устраивают.

Bubble — не универсальная таблетка для no-code разработки. Это мощный интегрированный комбайн для строго определенного класса IT-продуктов, и решение о его внедрении требует такой же взвешенности, как и выбор классического серверного стека.

Часто задаваемые вопросы

Сколько стоит Bubble в месяц?

Для целей разработки Bubble полностью бесплатен. Платные тарифы начинаются от $29 в месяц за Web, $42 за Mobile или $59 за Web + Mobile при оплате за год. Ежемесячная оплата плана Starter составляет $32, $49 и $69 соответственно, без учета возможного перерасхода Workload Units или платных опций.

Оправдан ли выбор Bubble сегодня?

Bubble оправдан для кастомных веб-SaaS, маркетплейсов и сервисов с насыщенной логикой, которым выгоден единый фулстек-стек из коробки. Он менее выгоден, если среди требований есть экспорт кода, полностью стабильный мобильный стек, фиксированные счета за инфраструктуру или работа большой команды редакторов.

Безопасно ли использовать Bubble?

Bubble предоставляет инфраструктуру с сертификацией SOC 2 Type II, шифрование данных, privacy rules, аудит уязвимостей и панель безопасности. Однако итоговая безопасность зависит от настроек: по умолчанию создаваемые типы данных могут оставаться открытыми, пока вы сами не ограничите к ним доступ.

Можно ли работать в Bubble бесплатно?

Да, в режиме проектирования и тестов. План Free включает 50K WU в месяц, но не позволяет запустить проект на внешнюю аудиторию. Для работы на своем домене, боевого запуска, деплоя в TestFlight, тестов в Google Play или релиза в магазины приложений требуется оформить платную подписку.

Что такое Workload Units в Bubble?

Workload Units (единицы рабочей нагрузки) — это совокупная метрика объема серверных ресурсов, которые сжигает проект. Запросы к базе данных, выполнение воркфлоу, обращение к API и серверные вычисления складываются в общий объем, при этом в комбо-проектах веб и мобильная версии делят лимит совместно.

Позволяет ли Bubble выгрузить исходный код?

Нет. Проекты на Bubble работают исключительно на управляемой инфраструктуре сервиса, площадка не позволяет выгрузить визуальный слой и воркфлоу в виде традиционного исходного кода. Если экспорт обязателен, используйте FlutterFlow или WeWeb.

Умеет ли Bubble собирать нативные мобильные приложения?

Да. Мобильный редактор на стадии public beta компилирует нативные приложения для iOS и Android на базе React Native, поддерживает камеру, службы геолокации, push-уведомления, живой предпросмотр на устройствах и публикацию в сторы. Перед стартом проверьте готовность платформы к вашим требованиям по плагинам, покупкам внутри приложения и офлайн-режиму.

Получите чек-лист аудита бизнес-процессов с ИИ и подпишитесь на рассылку для практиков.