Промпт для SaaS MVP с авторизацией и тарифами 2026

Промпт для SaaS MVP без четких ролей почти всегда превращается в хаотичный код: агент сам выдумывает таблицы пользователей, сам решает, что делать с подпиской при отмене, и через три итерации переписывает половину бэкенда. Разберем, как собрать один PRD-промпт с auth, ролями и billing, чтобы Cursor или Lovable поняли архитектуру сразу, без угадывания. Ниже — готовый шаблон, разбор реальных стеков (Clerk, Supabase, Stripe, Schematic) и таблица «кому что выбрать».

Структурированный промпт с ролями, авторизацией и тарифами экономит 2-3 итерации переделки бэкенда. В статье: готовый шаблон PRD-промпта, сравнение Clerk и Supabase Auth, разбор Stripe против Schematic для биллинга и разбор частых ошибок при описании ролей агенту.

Зачем вообще нужен структурированный промпт для SaaS MVP?

Без явного описания ролей и тарифов агент по умолчанию выбирает самую простую схему авторизации и часто не разделяет free и pro доступ на уровне бэкенда, только на уровне UI.

Cursor и Lovable отлично пишут код, но не читают мысли. Если в промпте написано просто «сделай подписку», агент выберет один способ проверки доступа и зашьет его в компоненты интерфейса. Заказчик хочет проверку на уровне API — а получает кнопку, которая просто скрывается в CSS.

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

Хорошая новость: один правильно собранный промпт с ролями, auth и billing снимает большую часть этих вопросов на старте. Дальше агент строит план, а не гадает.

Максим: «У Нейроскрайба фичу от разработчика ждали неделю-две. У Нейроштата с целой командой ждали ту же фичу месяцами и в итоге разочаровались, потому что сроки реализации оказались критичны. Чем четче агент понимает архитектуру до старта, тем меньше таких историй.»

Что обязательно описать в PRD-промпте перед стартом?

PRD-промпт для SaaS MVP держится на пяти блоках: продукт и роли, модель авторизации, тарифы с лимитами, онбординг и структура дашборда. Пропуск любого блока агент заполнит собственным дефолтом.

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

Роли определяют, какие таблицы и права доступа появятся в базе. Модель авторизации задает конкретный сервис, а не абстрактный «логин через почту». Тарифы с лимитами превращаются в entitlements — правила, которые агент может проверить в коде, а не просто нарисовать в UI. Онбординг фиксирует первый экран после регистрации, чтобы агент не придумывал произвольный редирект. Структура дашборда закрывает вопрос «что видно на каждом тарифе».

Без явного порядка агент может начать с UI и добавить auth в конце, что почти всегда требует переписывать формы. Правильный порядок в промпте: сначала роли, потом auth, потом billing, и только потом экраны.

Как объяснить агенту роли пользователей, чтобы он не путал доступы?

Роль описывается тремя вещами: название, что видит, что может делать. Без этой триады агент чаще всего создает одну общую таблицу users без разделения прав.

В промпте роль — это не просто слово «админ». Это конкретный набор действий, доступных именно этой роли, и явное перечисление того, что ей недоступно. Агент неплохо считывает такие структуры, если они даны таблицей, а не абзацем текста.

Часть ролей завязана на функции продукта (admin, member), часть — на тариф (free, pro). Это разные оси, и путать их в промпте не стоит: агент должен обрабатывать их отдельно, иначе получится один флаг вместо двух.

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

Формат, который агент читает без уточняющих вопросов: «Роль [название]: видит [что], может [что делать], не может [что]». Три роли на MVP обычно достаточно — усложнять до пяти-шести на старте смысла нет, лишние роли добавляются позже без перестройки схемы.

Как встроить авторизацию в промпт правильно?

Для MVP на Next.js в 2026 году два рабочих варианта — Clerk и Supabase Auth. Clerk дает готовые UI-компоненты и бесплатен до 50 000 MRU, Supabase Auth встроен в ту же базу данных, что и остальные таблицы.

Разница между сервисами авторизации сильно влияет на то, что агент напишет. Если в промпте просто «сделай логин», Cursor выберет что-то из двух и не спросит, почему выбрал именно это.

Оба варианта закрывают вход через почту и Google, но архитектурно они разные: Clerk держит пользователей у себя и синхронизирует их с базой через webhook, Supabase Auth сразу пишет пользователя в ту же Postgres-таблицу, где лежат остальные данные продукта. Для промпта это значит одно: указывайте сервис явно, а не абстрактную «авторизацию».

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

Как описать тарифы и billing, чтобы агент не изобретал архитектуру сам?

Для биллинга в 2026 году три рабочих пути: чистый Stripe с вебхуками, Clerk Billing поверх готовой авторизации, или Schematic как надстройка над Stripe с drag-and-drop управлением лимитами.

Биллинг — самая частая причина, по которой MVP приходится переписывать. Агент без четкого промпта либо забудет про вебхуки, либо привяжет доступ к фиче прямо в компоненте, а не в базе.

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

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

Что писать про лимиты в промпте

Для каждого тарифа явно укажите не только цену, но и числовой лимит фичи: «Free — 3 проекта в месяц, Pro — безлимит». Абстрактное «больше возможностей на Pro» агент интерпретирует произвольно, часто просто убирая одну кнопку из UI вместо реальной проверки на бэкенде.

Готовый промпт для SaaS MVP с auth и тарифами

Промпт ниже собирает продукт, роли, auth и billing в одну структуру. Копируйте целиком в Cursor или Lovable, замените плейсхолдеры в квадратных скобках на свои данные.

Собери PRD и построй MVP для SaaS-продукта [название].

ПРОДУКТ: [одно предложение о том, что делает продукт]

РОЛИ ПОЛЬЗОВАТЕЛЕЙ:
- Owner: полный доступ, управление тарифом и участниками
- Member: доступ только к своим данным, создание и редактирование
- Viewer: только просмотр
Для каждой роли — отдельная проверка прав на уровне API, не только в UI.

АВТОРИЗАЦИЯ: используй [Clerk / Supabase Auth].
Способы входа: email + пароль, Google OAuth.
После регистрации создавай запись профиля в базе через webhook.
Защищенные страницы — через middleware, редирект на /login для неавторизованных.

ТАРИФЫ И BILLING:
- Free: [конкретный лимит, например 3 проекта]
- Pro ($[цена]/мес): [конкретный лимит или безлимит]
Используй [Stripe напрямую / Schematic] для подписок.
Обработай события: успешная оплата, отмена подписки, неудачный платеж.
Проверка тарифа — на уровне API endpoint, не только скрытие кнопки в интерфейсе.

ONBOARDING: после регистрации показывай [конкретный первый экран].

DASHBOARD: опиши, что видит Free-пользователь и что дополнительно видит Pro.

Сначала создай план в Plan-режиме и покажи архитектуру базы данных.
Не начинай генерацию кода, пока я не подтвержу план.

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

Cursor или Lovable — что выбрать для этого промпта?

Cursor подходит, если нужен полный контроль над кодом и работа с MCP-плагинами для Stripe и Supabase. Lovable быстрее для первого прототипа UI, но потом код обычно переносят в Cursor для тонкой настройки.

Оба инструмента понимают промпт выше, но по-разному его отрабатывают. Cursor — полноценный редактор кода с плагинами: маркетплейс уже содержит готовые MCP-интеграции для Stripe и Supabase, которые подключаются в пару кликов и дают агенту прямой доступ к дашбордам этих сервисов. Lovable исторически быстрее собирает первый визуальный прототип и хорошо стартует с Supabase «из коробки».

Практика вайбкодеров, которая регулярно всплывает в гайдах: собрать лендинг и первые экраны в Lovable, а затем экспортировать код в Cursor для доработки биллинга и ролей. Комбинация экономит время на UI, но оставляет тонкую настройку auth и лимитов там, где удобнее работать с MCP.

Cursor Pro стоит $20 в месяц, Lovable в 2026 году тоже держит бесплатный старт с ограничением по генерациям. Для промпта с ролями и billing выше хватает базового платного тарифа любого из инструментов — тяжелые модели тут не обязательны, основная работа приходится на структурирование, а не на объем кода.

Какие ошибки убивают промпт для SaaS MVP?

Три частые ошибки: смешивание ролей и тарифов в один флаг, проверка доступа только в интерфейсе, и отсутствие явного списка webhook-событий для подписки.

Первая ошибка — писать «сделай premium-доступ» без разделения на функциональную роль и тарифный план. Агент в итоге зашивает оба смысла в одно поле is_pro, и через пару фич становится невозможно завести отдельного admin на free-тарифе.

Вторая — доверять проверку доступа только фронтенду. Кнопка спрятана, но API endpoint отвечает любому, кто знает URL. В промпте нужно явно требовать серверную проверку.

Третья — забыть про отмену и неуспешный платеж. Агент по умолчанию обрабатывает только успешную оплату, потому что это самый очевидный сценарий. Отписавшийся пользователь без обработки события customer.subscription.deleted продолжит видеть Pro-функции до случайной проверки вручную.

Итог — что взять с собой при написании промпта

Главное правило: роли, auth и тарифы описываются до того, как агент увидит запрос на UI. Порядок в промпте определяет порядок в архитектуре.

Каталог живых обзоров всех этих инструментов, включая связки с Cursor и Lovable, собран в каталоге AI-инструментов VibeCoderz. Если промпт не заводится с первого раза или тарифная логика путается на реальном проекте, можно разобрать это точечно на консультации с Максимом.

Глоссарий

PRD — Product Requirements Document, документ с требованиями к продукту, в вайбкодинге чаще заменяется структурированным промптом.

Entitlement — правило доступа к конкретной фиче в зависимости от тарифа, проверяется на бэкенде.

Webhook — уведомление, которое сервис вроде Stripe отправляет приложению о событии в реальном времени, например об отмене подписки.

RBAC — Role-Based Access Control, модель доступа на основе ролей пользователя.

MRU / MAU — Monthly Retained Users / Monthly Active Users, единицы, по которым сервисы авторизации считают бесплатный лимит.

FAQ

Чем промпт для SaaS MVP отличается от обычного промпта на фичу? Промпт для SaaS MVP описывает архитектуру целиком: роли, auth и billing связаны между собой, и агент должен учитывать все три блока одновременно, а не по одному.

Можно ли использовать один промпт и для Cursor, и для Lovable? Да, структура промпта не завязана на инструмент. Разница только в том, что Cursor лучше отработает MCP-плагины для Stripe и Supabase, а Lovable быстрее соберет первый визуальный слой.

Нужен ли Stripe, если используется Clerk Billing? Clerk Billing работает поверх Stripe и скрывает часть настройки, но сам аккаунт Stripe и продукты в нем все равно нужно создать.

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

Что делать, если агент все равно проверяет доступ только в UI? Явно указать в промпте: «проверка тарифа обязательна на уровне API endpoint». Без этой фразы агент часто ограничивается скрытием элемента интерфейса.

Сколько ролей закладывать в MVP на старте? Обычно достаточно двух-трех: owner, member и опционально viewer. Дополнительные роли проще добавить позже, чем закладывать сразу шесть невостребованных.

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

Обновлено: июль 2026.