Это 2-я часть серии о создании реальных веб-сервисов с помощью ИИ-инструментов, таких как Cursor.
Первая часть будет полезна, если вы не понимаете что такое frontend и backend, базы данных, HTML/CSS/JavaScript и React, но очень хотите сделать проект.
Перед тем, как писать техническое задание для вашего продукта, необходимо ответить на один важный вопрос:
Какой стек вы будете использовать?
Это может казаться чисто техническим решением, но когда вы создаёте ПО с помощью Cursor, стек фактически становится частью инструкции для ИИ. Если вы не определите его заранее, ИИ будет импровизировать. Не хочу даже думать, к чему это приведет.
Здесь опишу стек, который в итоге использовал сам. Такая конфигурация отлично сработала и, возможно, поможет вам избежать проблем, с которыми я столкнулся в начале.
Прикреплю опросы под статьей, чтобы вы могли отметить свой любимый стек, или посмотреть кто и что использует для ИИ и не только.
Выбор фреймворка
Если у вашего продукта есть веб-интерфейс (то есть, пользователи работают с ним через браузер), нужен фреймворк, который обрабатывает и frontend, и backend.
Для обоих сервисов, которые построил, я выбрал Next.js. И ни разу не пожалел об этом.
Могу сказать, что прежде никогда не работал с Next.js (мне были знакомы вещи типа PHP, Laravel, JavaScript и т.п., но я просто последовал рекомендации ChatGPT, и это сработало). Это я к тому, что если вы разбираетесь в какой-то другой технологии, тут можно попробовать новое.
Если вы были далеки от разработки вообще, вы можете столкнуться со сложностями кеширования на клиенте и управления состояниями приложения (это необходимо, чтобы полностью уйти, например, от перезагрузки страниц в браузере, когда пользователь работает с вашим сервисом), но тут уже только опыт поможет. В следующих частях я опишу основные вещи, которые делал. В конечном счете, такого рода полировка уж точно не является необходимой для вывода решения на рынок. Появятся пользователи, появится выручка, наймете фронтэндера.
Где будет работать ваш сервер?
Когда фреймворк выбран, следующий вопрос: где приложение будет запускаться. Тут отмечу, что оба проекта я делал под глобальный рынок. Для России рекомендуют Timeweb, но я не пробовал.
Vercel
Для моего первого проекта я использовал Vercel.
Это довольно естественный выбор при работе с Next.js. Деплой (выгрузка на сервер) происходит при пуше (команда git push) автоматически "из коробки".
Однако со временем я столкнулся с неожиданной проблемой. В некоторых регионах (например, Россия) приложение недоступно без VPN. Поэтому первый проект остался на Vercel, но для второго я решил попробовать что-то другое.
Fly.io
Во втором проекте я перешёл на Fly.io.
Деплой там немного сложнее, чем в Vercel, но его можно автоматизировать. В итоге, мне даже больше понравился Fly.io. Он кажется более удобным для масштабирования, если проект начнёт расти.
Интересно, что у Fly.io формально нет бесплатного тарифа, но если ежемесячные расходы ниже $5, они вообще ничего не списывают.
Выбор базы данных
Есть два основных подхода:
Первый: запускать собственную базу данных на своём сервере. Это даёт полный контроль и может быть полностью бесплатным.
Второй: использовать Database as a Service.
В обоих своих проектах я выбрал второй вариант, потому что хотел двигаться максимально быстро. Я использовал Supabase.
Supabase предоставляет базу PostgreSQL, а также несколько очень полезных инструментов.
Почему Supabase оказался удобным
Во-первых, Supabase поддерживает векторное хранение данных. Это оказалось важно для одного из моих проектов, где данные хранились в виде эмбеддингов, созданных с помощью модели OpenAI embedding-3-small. По мере того как ИИ всё глубже интегрируется в программные продукты, нативная поддержка векторных данных становится неожиданно полезной.
Во-вторых, Supabase включает встроенную систему аутентификации. Пользователи могут входить через Google, GitHub, email "из коробки". Вам и вашему Курсору даже код писать не надо. Можно добавить и вход через Яндекс и ВК через Generic OAuth-авторизацию.
Supabase также предоставляет хранилище файлов, позволяющее пользователям загружать изображения и другие файлы без необходимости строить отдельную инфраструктуру.
Ещё одна полезная функция: поддержка RPC-функций. Во втором проекте я полностью отказался от того, чтобы мой бэкенд делал запросы напрямую в таблицы БД, и сделал все через RPC. На практике, ошибок при генерации кода сейчас практически нет.
Также Supabase поддерживает Row Level Security (RLS). Это важно для безопасности, чтобы злоумышленник не мог "дернуть" ваши таблицы напрямую, минуя ваш бэкенд. При включении RLS, права пользователя будут проверены самой базой данных (например, если редактировать статью может только ее автор, Supabase сама проверит и запретит третьим лицам вносить изменения в чужую статью, даже если они будут "притворяться" вашим сервисом и требовать внести изменения, раздобыв anon-ключ вашего приложения).
Неожиданный и приятный плюс: недавно они обновили своего ИИ-ассистента поддержки, переключив его на ChatGPT движок. Он разбирается в их продукте лучше, чем чат внутри Курсора. Таким образом, вы можете организовать обсуждение двумя ботами ваших проблем, копируя текст ответа одного бота другому, и решить практически любую задачу. Еще летом 2025 в Supabase был просто ужасный бот поддержки, но сейчас стало прям ок.
Недостатки Supabase
Первая проблема, с которой я столкнулся, связана со встроенной системой аутентификации: вход через Google (и через любого другого провайдера авторизации) работает нестабильно у пользователей, которые заходят через Safari на iPhone.
Я обнаружил это только спустя примерно 2 месяца разработки, и, фактически, это оказалось невозможно исправить. Суть в том, что если на айфоне у человека уже открыта вкладка в браузере с вашим сервисом, нажимая где-либо на ссылку и открывая еще одну новую вкладку браузера, сессия не подхватывается, происходит сбой авторизации. Не получается сделать стабильный процесс - один раз вошёл в свой аккаунт и всё, сервис запоминает это. Это крайне важно как раз для тестирования гипотез и замера конверсий. Можно использовать обходные методы типа специальных ссылок в почтовых рассылках с редиректом и принудительной авторизацией, но что если пользователь просто решит еще раз найти ваш сервис через поиск...
Во втором проекте я в итоге использовал только часть системы аутентификации Supabase (проблема решается тем, что токены для авторизации пользователей мы создаем сами, не доверяя это Supabase и используя строго серверные куки).
Второй недостаток — цена. Формально у Supabase есть бесплатный тариф, но на практике вы можете всё равно платить около $25 - 40 в месяц, даже если приложение ещё находится в разработке и у него нет пользователей. Не огромная сумма, но об этом стоит помнить.
Cursor и ChatGPT: разные роли
Cursor для меня, это основная среда разработки. Существуют и другие IDE, но Cursor показал себя хорошо. Переходить на VS Code, например, и общаться с ботом через командную строку, мне совершенно не хочется пробовать.
Серьёзные минусы: стоимость и постоянные обновления.
Иногда мои расходы на Cursor доходили до $100 в день. Со временем, я научился снижать их. Сейчас, реалистичная оценка $300 в месяц, если использовать мощные модели.
Понятно, что у Cursor есть базовая подписка за $20, но пользоваться их бесплатной моделью просто невозможно, а лимиты на платные очень маленькие.
ChatGPT всё равно нужен
Даже если вы используете Cursor, всё равно рекомендую иметь подписку ChatGPT Plus.
Cursor → написание и изменение кода
ChatGPT → обсуждение идей и архитектуры
Таким способом вы сэкономите много денег, так как в ChatGPT вы не платите за каждый запрос, в отличие от Курсора.
Внутри Cursor модель оптимизирована для генерации кода и стабильности.
Вне Cursor ChatGPT работает более творчески.
Есть простое правило: не просите ChatGPT писать production-код, это бессмысленно, тот же ChatGPT внутри Курсора, а тем более Opus, напишет код точно лучше.
ChatGPT для визуала
Ещё одно неожиданное применение ChatGPT, генерация изображений.
Второй мой проект представляет собой визуальные пространства, цифровые парки с монументами, дорожками и декоративными объектами. Для этого требовалось много графических ассетов.
Вместо покупки ассетов или найма дизайнеров на каждую итерацию я генерировал большую часть визуалов напрямую через ChatGPT.
Поскольку генерация изображений включена в подписку ChatGPT Plus, это позволило сэкономить довольно много денег на этапе разработки, да и просто было удобно.
Инструменты дизайна
Многие используют Figma, чтобы спроектировать интерфейс перед написанием кода.
Лично я почти не пользовался этим. Cursor генерирует разумные UI-макеты самостоятельно, после чего корректирую их вручную.
Тем не менее, если вы предпочитаете сначала проектировать интерфейсы, Figma может быть очень полезна. У Google также есть полезный проект Google Stitch, который превращает дизайн в рабочий код.
Теоретически вы можете:
сделать дизайн в Figma
сгенерировать шаблоны через Stitch
затем превратить эти шаблоны в React-компоненты
Email и ещё кое что
Большинству приложений рано или поздно нужно отправлять email. Для этого я использовал простой сервис Resend.
Позже может возникнуть необходимость добавить кеширование через Redis, но в обоих проектах я отложил этот шаг. Если архитектура изначально спроектирована правильно, кеширование всегда можно добавить позже.
Нужен ли Docker?
В обоих проектах мне удалось полностью обойтись без Docker. Vercel сам собирает проект (это сервис, созданный самими разработчиками Next.js, как понял). Во fly.io вы можете использовать Docker для сборки вашего продукта локально на вашем ПК, но можете и загружать туда файлы "как есть", сборка может происходить на их сервере.
Один раз что-то сломалось, и Fly.io перестал подхватывать файлы и начинать сборку. Рекомендации в интернете - либо сменить регион сервера в настройках Fly, либо переключиться на локальные сборки (вот в этом случае вам может пригодиться Docker). Но я использовал какой-то флаг для команды деплоя на Fly, и мне не пришлось делать ни то, ни другое. Вы тоже можете просто спросить Opus как обойтись малыми усилиями (не меняя сервер и не устанавливая Докер), чтобы починить деплой, он вам ответит.
Железо важнее, чем кажется
Ваше железо имеет значение. Курсором удобно пользоваться, когда у вас достаточно пространства на экране, чтобы видеть несколько панелей одновременно. Я начал разработку на маленьком 13-дюймовом планшете. Технически это работало, но было крайне неудобно. Переход на 27-дюймовый монитор радикально улучшил рабочий процесс.
Cursor также может быть довольно требовательным к ресурсам, поэтому мощный компьютер действительно помогает. Например, мой планшет Surface Pro 8 с i7/16/1Tb отлично справлялся во всеми "менеджескими" задачами, и даже видео на нем монтировал, но работа в Курсоре превратилась в утоминельную историю: вентилятор постоянно гудит, все подвисает. Пытаясь разобраться в чем дело, понял, что вероятно это связано с индексированием и постоянными обновлениями, но отключать индексирование тоже так себе идея.
Операционная система
Для контекста, весь этот эксперимент я проводил на Windows.
Однако, ничего в этом стеке не зависит конкретно от Windows, кроме постоянных попыток ИИ писать команды через символ && (но это лечится правилами, о которых напишу позже). Та же конфигурация отлично работает и на macOS или Linux.
Минимальный стек
Если сильно сжать, мой стек выглядит так:
Framework: Next.js
Database: Supabase
Hosting: Fly.io
IDE: Cursor
Chat: ChatGPT
Email: Resend
Этого оказалось более чем достаточно, чтобы построить реально работающие продукты.
Что дальше
Теперь можно перейти к следующему шагу.
Перед тем, как писать код, нужно чётко описать продукт.
Большинство людей, используя ИИ, сразу начинают писать код. По моему опыту, это самый быстрый способ получить хаотичную систему.
В следующей статье поговорим о том, как превратить идею в чёткое техническое задание, которое Cursor действительно сможет понять.
