Может ли нейросеть собрать приложение с базой данных

Да. Опишите приложение текстом, подключите коннектор Supabase, и Zugo соберёт интерфейс, схему данных и связку между ними: записи сохраняются в вашем Postgres, а не в памяти вкладки. Проверка стоит одну сборку, то есть 1 100 кредитов. Сложная бизнес-логика при этом всё равно доводится правками, а не одним промптом.

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

Что на практике значит «приложение с базой данных»?

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

Нейросеть закрывает обе половины сразу. По описанию вроде «учёт заявок для мастерской: приёмщик заводит заявку, мастер меняет статус, владелец видит список за месяц» генерируется и интерфейс, и структура таблиц, и запросы между ними. Писать SQL или React для этого не требуется.

Формулировка «без кода» здесь означает не «кода нет», а «вам не обязательно его писать». Код лежит в проекте, его видно и можно править руками, а потом забрать в свой репозиторий на GitHub. В этом и состоит практический смысл владения: проект продолжает работать на вашей инфраструктуре независимо от того, пользуетесь вы билдером дальше или нет.

Где именно оказываются данные?

В вашем проекте Supabase, если подключён соответствующий коннектор. Supabase это Postgres плюс авторизация плюс файловое хранилище, доступные приложению через API. Ключевое слово здесь «вашем»: аккаунт заводите вы, дашборд открываете вы, и записи остаются доступными независимо от того, откроете ли вы Zugo ещё хоть раз.

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

Читать таблицу стоит как карту ответственности, а не как список пробелов. Почти всё, что не генерируется, уже лежит в аккаунте, которым вы и так управляете.

Как описать приложение, чтобы схема получилась правильной?

Назвать три вещи: кто пользователь, какие сущности он создаёт и кто их видит. Половина неудачных сборок начинается с промпта, где есть только первое. «Приложение для учёта клиентов» не содержит ни одной подсказки о структуре, поэтому структура получится случайной.

Слабый промпт: «CRM для салона». Сильный: «Учёт записей для салона красоты. Администратор заводит клиента с именем и телефоном, ставит запись на дату и мастера, мастер видит только свои записи на сегодня, владелец видит все записи за месяц». Здесь названы три роли, две сущности и правило видимости.

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

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

Какие приложения с базой получаются лучше всего?

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

Три примера, которые ложатся хорошо, и что в них важно назвать.

Внутренний учёт. «Журнал заявок мастерской: заявка с клиентом, устройством, статусом и датой. Приёмщик заводит, мастер меняет статус, владелец смотрит список за период». Одна сущность, три роли, никакой публичной части. Такие приложения доходят до рабочего состояния быстрее всего.

Личный трекер. «Дневник тренировок: пользователь видит только свои записи, у записи дата, тип нагрузки и заметка». Фраза про «только свои» здесь несущая конструкция, а не пожелание, потому что именно она определяет модель доступа.

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

Сколько стоит приложение с базой в кредитах?

Столько же, сколько любое другое приложение того же размера: база не тарифицируется отдельно. Одностраничная сборка стоит 1 100 кредитов, правка 550, а многостраничная платформа 2 200 за первые три страницы и по 550 кредитов за каждую следующую. Режим Hi-Fi удваивает оба числа: сборка 2 200, правка 1 100.

Тарифы устроены так: Pro стоит $25 в месяц и даёт 20 000 кредитов, Business стоит $50 в месяц.

Практическая арифметика важнее прайса. 20 000 кредитов Pro это примерно 9 полных платформ, или 18 быстрых сборок, или 36 правок, если тратить их только на правки. Приложение с базой обычно живёт по третьему сценарию: одна сборка в начале и длинный хвост уточнений, пока модель данных не перестанет меняться каждый день.

Сам аккаунт Supabase оплачивается отдельно и у него есть свой бесплатный уровень. Полный разбор цен собран в статье сколько стоит сайт или приложение нейросетью.

Что происходит перед тем, как сборку отдадут вам?

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

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

Поэтому первым делом после сборки заведите одну тестовую запись руками и посмотрите на неё в дашборде Supabase. Минута такой проверки экономит неделю, потому что переименовать таблицу на первой неделе дешевле, чем на шестом месяце с накопленными данными.

Чего нейросеть не сделает за вас?

Четыре вещи, и знать о них лучше заранее.

• Не решит за вас модель данных. Сгенерированная схема это разумная отправная точка по вашему описанию, а не результат проектирования. Просмотрите таблицы сами, пока в них не набежали месяцы записей.
• Не заменит команду разработки на сложном продукте. Zugo быстро даёт работающую первую версию. Продукт с десятком ролей, интеграций и нетривиальных расчётов после этого ведёт команда, а не промпт.
• Не угадает специфичную бизнес-логику. Правило вроде «скидка действует только на второй заказ в том же месяце и не суммируется с промокодом» появляется через последовательные правки, а не из одного описания.
• Не проверит за вас права доступа. Кто какие строки может читать, стоит пересмотреть руками до того, как в базу попадут чужие персональные данные. В дашборде Supabase политики видно и можно ужесточить.

Ничего из этого не аргумент против такого способа сборки. Это аргумент за то, чтобы относиться к минутному результату как к сильному черновику, а не как к готовой продакшен-системе.

Что делать дальше?

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

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