Нейросети для создания приложений: что выбрать и как запустить веб-приложение

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

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

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

Чтобы сравнение не расползлось на десятки функций, оставим у студии одну услугу, одного сотрудника и несколько заранее открытых слотов. Клиент выбирает время, оставляет контакт и получает подтверждение; администратор входит и находит ту же запись в своём расписании. Абонементы, оплату и отчёты пока можно записать в список будущих задач. Если ещё не работает эта короткая цепочка, новые экраны только затруднят поиск причины.

Попробуйте объяснить выбранный путь агенту своими словами, а затем попросите показать, какие данные он собирается хранить. Получатся как минимум услуга, сотрудник, клиент и запись, связывающая их с выбранным временем и статусом. У сотрудника должен быть устойчивый идентификатор, чтобы после переименования его расписание оставалось на месте. Иначе с появлением двух Александров в команде придётся разбираться, какому из них достался клиент. Такие детали проще обсудить сейчас, пока вы ещё не заполнили календарь.

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

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

AI-конструктор обычно объединяет несколько вещей, которые в обычном чате пришлось бы собирать по отдельности: агента, редактор, подключение к данным и способ опубликовать результат. Но состав этого набора отличается. Где-то вход и база уже находятся рядом, где-то нужно выбрать внешний сервис, а где-то основной сценарий рассчитан прежде всего на страницы и лендинги. В таблице собраны возможности из официальной документации на 7 октября 2026 года; она поможет выбрать кандидатов для проверки нашей записи в студию.

С Amvera Polide есть практическая сложность: продуктовая страница уже сообщает о запуске агента и подключённом инференсе, а инструкция браузерной IDE ещё предлагает свой API-ключ и описывает будущий запуск. Если собираетесь выбрать этот вариант, откройте доступный вам режим в аккаунте и уточните, какой путь сейчас поддерживается. Иначе легко принять решение по инструкции, которая отстала от самого продукта.

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

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

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

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

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

Если проверка не прошла, опишите ошибку так, чтобы её можно было воспроизвести: под каким аккаунтом вошли, что открыли, чего ожидали и что увидели. Например, «под клиентом Б открыл запись А и получил телефон» уже задаёт понятное направление расследования. После исправления повторите этот же путь. Заодно посмотрите, объясняет ли агент причину и показывает ли результат проверки: с таким разбором легче продолжать работу, чем с бесконечным обменом «поправь» и «готово».

Когда основной сценарий понятен, можно переходить к условиям, из-за которых подходящий на первый взгляд сервис иногда приходится исключать. Для работы из России или другой страны СНГ отдельно выясните, как оплачивать подписку, где будут храниться данные и через какого поставщика идут запросы к модели. Русский интерфейс ничего не говорит о двух последних пунктах, как и удобная рублёвая оплата. У одной платформы может подходить размещение базы, но не способ оплаты, у другой всё будет наоборот.

Например, WUNA описывает встроенные базу и файлы на серверах в России. Если вы подключите свой Supabase, его размещение уже будет зависеть от выбранной вами инфраструктуры, а существующие записи автоматически в него не переедут. У Lovable регион Cloud выбирается до включения и затем не меняется, поэтому этот вопрос лучше решить до наполнения проекта. При этом выбранное место хранения Cloud само по себе не определяет, где обрабатываются AI-запросы.

У Replit географию публикации, в том числе Европу, можно выбирать на планах Core, Pro и Enterprise; бесплатный вариант публикуется в Северной Америке. Но размещение опубликованного приложения и место, где находятся среда разработки или уже созданное хранилище, могут различаться. Если для проекта принципиально, куда попадают данные, посмотрите всю цепочку от браузера до базы и модели, вместо того чтобы ограничиться одним переключателем региона.

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

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

В документации Lovable перенос кода и backend разобран отдельно: новым приложениям на TanStack Start требуется серверный runtime, а старые проекты на React/Vite могут собираться в статические файлы. У Bolt есть выгрузка проекта в ZIP, но для переезда базы и аккаунтов всё равно нужно выяснить отдельный порядок. WUNA и Lork связывают доступ к исходникам со старшими тарифами. То есть полезно заранее скачать доступный вам проект и разобраться, какие части понадобятся, чтобы запустить его вне редактора.

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

До покупки подписки разберите, что вы получаете в бесплатном режиме и когда он заканчивается. У WUNA предусмотрен ограниченный пробный период, у Bolt работа агента ограничена токенами, а Lovable отдельно учитывает build, Cloud и AI-возможности самого приложения. По крупной цене на карточке трудно понять будущий счёт, потому что в одном случае она описывает работу над кодом, в другом включает часть размещения, а дополнительные расходы остаются за пределами подписки.

Для студии удобно начать с небольшого расчёта: сколько уйдёт на создание и исправления с агентом, на работающий сервер, на базу с файлами и на внешние действия вроде уведомлений. Если приложение само будет отвечать клиентам через модель, её использование тоже нужно добавить. Агент, который помог написать код, может больше не участвовать в работе готовой формы, а встроенный AI-помощник будет обращаться к модели при каждом разговоре. Это разные расходы, и смешивать их в одной строке «нейросеть» неудобно.

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

Теперь соберём ту же задачу для Agnostic. Записи можно хранить в Data, вход клиентов и сотрудников организовать через App Auth, а действия после сохранения вынести в Automations. Для работы над кодом вы подключаете своего агента из Cursor, Codex или Claude Code к проекту через MCP и проверяете результат в Preview. Правила студии при этом нужно описать явно, особенно защиту от двойного бронирования: одно наличие хранилища ещё не даёт нужной гарантии при одновременной записи.

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

Создай веб-приложение записи в студию в Agnostic.
Сначала назови выбранные проект и окружение.
Проверь Agnostic MCP. Если подключения нет, помоги выбрать
проект и окружение, получить инструкцию из меню MCP,
покажи план настройки и дождись авторизации в браузере.
Инструкция: https://agn0.ru/blog/connect-cursor/.
Прочитай контекст проекта и доступные действия.
Для кода используй workspace этого проекта, полученный через
Agnostic CLI; если его нет, помоги получить его.
Если App ещё нет, новый стартовый App создавай только в Live;
сначала покажи состав этого шага. Создание не означает публикацию.
Затем отдельно готовь код, сборку и проверку в нужном окружении.

Начни с одной услуги, сотрудника и нескольких слотов.
Храни услуги, клиентов и записи в Data Agnostic.
Вход реализуй через App Auth; клиент видит свои записи,
сотрудник — только разрешённое расписание.
Проверяй права на сервере. Для данных и автоматизаций используй
текущий Runtime SDK Agnostic в серверном коде.

До реализации объясни модель данных и защиту от двух разных
клиентов на одном слоте. Отдельно объясни обработку повторной
отправки одной заявки. Не считай наличие Data доказательством
нужной атомарности. Если механизма не хватает, назови ограничение
и предложи подходящий серверный вариант в рамках проекта.
Уведомление запускай через Automations после сохранения записи.
Секреты оставь на сервере, используй вымышленные контакты.

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

В бесплатное предложение Agnostic входят черновик и временный Preview, а агент, вычисления, данные, сборки и CDN оплачиваются отдельно. Если работаете с внешним агентом, добавьте его подписку или расход модели к своему расчёту. После проверки сохраните нужную версию и сверьте окружение перед публикацией. Затем откройте уже рабочую ссылку и ещё раз создайте тестовую запись: так вы увидите, что вместе с кодом выпущено именно то подключение к данным, которое ожидали.

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