Переросли Base44 или Bubble? Как спланировать следующий релиз без переписывания вслепую

MVP помог вам понять, чего хотят клиенты. Теперь какая-то интеграция даётся с трудом, мобильный опыт становится важным или вы хотите больше контроля над кодом. Переход с Base44 или Bubble на собственный код должен начинаться именно с такого конкретного требования. Сам факт, что продукт собран в конструкторе, ещё не повод его выбрасывать.

Как понять, что вы переросли свою платформу?

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

Сформулируйте требование как наблюдаемый результат. Например: клиент загружает документ, позже получает обработанный результат и видит его статус на телефоне. Определите, какая часть сейчас не работает. Причиной может быть недоделанная реализация, ограничение тарифа, граница интеграции или модель выполнения самой платформы. Эти выводы ведут к разным решениям.

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

Расширить, интегрировать или переписать?

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

Собственный сервис тоже добавляет эксплуатационную работу: деплой, обработку ошибок, учётные данные и мониторинг. Учитывайте её при сравнении. Точно так же у переписывания должен быть намеренно сокращённый первый объём — на основе сценариев, которыми клиенты реально пользуются, а не всех экранов, которые вы когда-то сгенерировали.

Что на самом деле можно забрать из Base44 или Bubble?

Проверяйте доступ к исходному коду, доступ к данным и зависимости от бэкенда по отдельности. То, что продукт принадлежит вам или вы можете скачать файлы, ещё не означает, что вся работающая система перенесена.

По состоянию на октябрь 2026 года документация Base44 по GitHub описывает двустороннюю синхронизацию кода на тарифе Builder и выше и указывает, что подключать или переподключать репозиторий могут только владельцы приложения. В руководстве по инструментам разработчика также описан код, который продолжает зависеть от инфраструктуры и API Base44. Изучите реальный проект, прежде чем обещать независимый хостинг.

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

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

Что должно быть в задании на миграцию?

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

1. Пути клиентов: покажите минимальные сквозные сценарии, которые должны работать на запуске, включая пустые состояния, ошибки и уведомления.
2. Карта данных: перечислите сущности, стабильные идентификаторы, связи, обязательные поля, места хранения файлов и ожидаемое количество записей.
3. Правила доступа: объясните, что клиенты, сотрудники и администраторы могут читать или изменять. Включите приглашения и восстановление аккаунта.
4. Внешние системы: перечислите платежи, email, аналитику, API, вебхуки и фоновые задачи, указав владельца каждого аккаунта.
5. Приёмка и передача: определите, как будет проверяться релиз, кто будет его эксплуатировать и какую документацию и доступ к исходному коду вы получите.

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

Как перенести данные клиентов без догадок?

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

Документация Base44 по управлению данными описывает экспорт в CSV и отмечает, что активные фильтры могут ограничивать экспортируемые записи. Убедитесь, что вы выгрузили весь нужный набор данных. Задокументированные в Bubble пути через CSV и API также требуют плана по сохранению связей и проверке полноты.

1. Экспортируйте репрезентативные записи, включая связанные объекты, длинный текст, даты, необязательные поля и ссылки на файлы.
2. Задокументируйте, как идентификаторы и связи отображаются в новой системе; посчитайте строки до и после импорта.
3. Проверьте реальное поведение продукта на импортированной копии, включая права доступа и обновление записей.
4. Спланируйте аутентификацию и коммуникацию с пользователями отдельно. Не рассчитывайте, что пароли или активные сессии перейдут от одного провайдера к другому.
5. Договоритесь о финальном экспорте и периоде контроля записи данных, чтобы записи не потерялись между репетицией и переключением.

Можно ли заменять приложение поэтапно?

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

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

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

О чём договориться до начала разработки?

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

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

Используйте чек-лист запуска AI MVP, чтобы определить критерии приёмки релиза. Если настоящая цель — вывести приложение на Base44 на телефоны, прочитайте руководство по публикации Base44 в App Store, прежде чем решать о переписывании. Чтобы разобрать ваши варианты, запишитесь на звонок о вашем приложении на Base44 или MVP на Bubble. Приходите с описанием заблокированного результата для клиента и демонстрацией того, что уже работает.