На чём собран проект технически: разбор по слоям

На чём собран проект технически

Результат это обычный веб-проект, который открывается в браузере по адресу вида имя.zugo.run. Исходники выгружаются в репозиторий GitHub под вашим аккаунтом, поэтому точный состав файлов вы видите глазами, а не со слов продукта. Данные и вход приходят из Supabase, оплата из Stripe, хостинг переносится на ваш Vercel.

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

Что именно вы получаете на выходе?

Работающий веб-проект и адрес, по которому он открывается. Это не макет, не экспорт картинок и не конструктор, живущий только внутри редактора. Публикация даёт поддомен вида имя.zugo.run сразу, свой домен подключается сверху.

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

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

Как узнать точный стек своего проекта?

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

Такой ответ полезнее, чем список технологий в маркетинговом тексте, ещё по одной причине. Разработчику, которого вы позовёте, нужен не список, а репозиторий: он открывает проект, ставит зависимости и видит всё сам. Как устроена выгрузка, разобрано в статье про экспорт исходников.

Если разработчика пока нет, репозиторий всё равно стоит завести на первой же удачной версии. Он превращает проект из состояния «живёт в чужом продукте» в состояние «лежит у меня», и это решение, которое дешевле принять заранее.

Из каких слоёв состоит собранный проект?

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

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

Что означает «база и вход через Supabase»?

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

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

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

Можно ли перенести проект на свой хостинг?

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

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

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

Стоит заранее понимать, во что обходится сама итерация. Сборка стоит 6 кредитов, правка 3, многостраничная платформа 12 за первые три страницы и по 3 за каждую следующую. Режим Hi-Fi вдвое дороже. На тарифе Pro за $25 в месяц это 200 кредитов, то есть около 33 сборок или 66 правок, и техническая часть переноса на свой хостинг кредитов не расходует вовсе.

Что нужно разработчику, чтобы подхватить проект?

Три вещи, и все три у вас уже есть. Репозиторий с исходниками, доступ к проекту Supabase, где лежат данные и правила входа, и доступ к аккаунту, куда проект деплоится. Дальше он работает так же, как с любым другим веб-проектом.

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

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

Чем это отличается от конструктора со своим форматом?

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

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

Где границы этого стека?

Первая граница браузерная. Всё, что собирается, работает в вебе, поэтому нативное приложение для сторов это другая задача и другие инструменты. Игры двумерные.

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

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

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