Как сделать панель SaaS без кода: экраны, данные, цена

Опишите текстом, кто заходит в панель, что он там видит и что может изменить. Zugo соберёт платформу с входом, списками, карточками записей и сводкой, прогонит её в песочнице и опубликует на адресе вида yourapp.zugo.run. Многостраничная платформа стоит 12 кредитов за первые три страницы и по 3 за каждую следующую.

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

Что такое панель SaaS и из чего она состоит?

За словом «панель» обычно скрываются четыре разные вещи. Сводка с показателями. Списки сущностей с фильтрами. Карточка отдельной записи, где что-то редактируют. И настройки, включая профиль и биллинг.

Конструктор делает все четыре, но с разной уверенностью. Списки и карточки механические: из описания «у клиента есть проекты, у проекта есть статус» экраны следуют напрямую. Сводка требует, чтобы вы назвали конкретные показатели. Права доступа требуют, чтобы вы назвали правила.

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

Полезное упражнение перед сборкой: написать, какое действие человек совершит после того, как увидел каждый показатель. Если действия нет, показателя быть не должно. Это сокращает первый экран вдвое и делает его полезнее.

Какие экраны нужны в первой версии?

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

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

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

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

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

Второй вариант фиксирует сущности, кардинальность связи, набор значений статуса, экраны и правило доступа. Именно фраза «видит только своих» превращает панель из демо в рабочий инструмент, и её пропускают чаще всего.

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

Сколько стоит панель SaaS в кредитах?

Панель это всегда многостраничная платформа. Вход, список, карточка и настройки дают четыре страницы: 12 за первые три плюс 3 за четвёртую, итого 15 кредитов. Шесть страниц дают 12 плюс 9, итого 21. Сборка занимает несколько минут, а не одну.

Free даёт 5 кредитов, поэтому панель начинается с платного тарифа. Pro стоит $25 в месяц и включает 200 кредитов. Business стоит $99 в месяц. Основной расход здесь не первая сборка, а правки: панели доводят до ума итерациями, и каждая стоит 3 кредита.

Как устроены вход, роли и доступ к данным?

Вход, база и файлы закрываются одним коннектором Supabase. Это удобно тем, что «залогинить пользователя и показать ему только его строки» становится одной связанной задачей, а не двумя системами, которые надо знакомить друг с другом. Устройство разобрано в статье про приложение с Supabase.

Роли описывают словами, и описывать надо через данные, а не через названия. «Админ видит всё» это не правило, а лозунг. «Пользователь с ролью admin видит все строки таблицы clients, пользователь с ролью member видит только строки, где owner_id равен его идентификатору» это правило, которое можно проверить.

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

Что проверить самому перед тем, как пускать пользователей?

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

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

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

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

Как показывать данные: таблица, карточки или график?

Форма подачи должна следовать из задачи, а не из вкуса. Таблица нужна, когда данные сравнивают между собой построчно и когда важна плотность. Карточки нужны, когда у записи есть картинка или когда строк мало. График нужен, когда важна динамика во времени, и почти никогда в других случаях.

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

Вторая частая ошибка это таблица без сортировки и фильтра. Список из двухсот строк, который нельзя отсортировать, бесполезен, и добавление сортировки это одна правка за 3 кредита. Просить её стоит сразу в первом промпте вместе с описанием колонок.

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

И назовите значения по умолчанию: какая сортировка стоит при открытии и какой период показывает сводка. Не назовёте, получите произвольный выбор, который потом будете объяснять пользователям.

Чего конструктор не сделает?

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

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

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

С чего начать

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