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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тарифы устроены так: Free даёт 5 кредитов единоразово, Pro стоит $25 в месяц и даёт 200 кредитов, Business стоит $99 в месяц. Честная оговорка про Free: 5 кредитов это чуть меньше одной сборки, поэтому первый настоящий прогон начинается на платном тарифе.

Практическая арифметика важнее прайса. 200 кредитов Pro это примерно 16 полных платформ, или 33 быстрых сборок, или 66 правок, если тратить их только на правки. Приложение с базой обычно живёт по третьему сценарию: одна сборка в начале и длинный хвост уточнений, пока модель данных не перестанет меняться каждый день.

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

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

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

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

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

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

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

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

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

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

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

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