Страница обновлений продукта без кода: сборка за минуты

Страница обновлений продукта собирается по текстовому описанию: вы говорите, какие поля есть у записи, как они группируются по датам и версиям, а билдер собирает ленту с фильтрами. Простая версия в Zugo появляется примерно за минуту, публикация на адрес вида ваш-проект.zugo.run в один клик.

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

Зачем продукту отдельная страница обновлений?

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

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

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

Что писать в промпте для changelog?

Ключевое отличие changelog от блога в том, что у записи есть структура, а не только текст. Опишите поля явно, и вы получите ленту, которую можно фильтровать. Опишите «сделай страницу обновлений», и получите пять абзацев подряд без всякой структуры.

Страница обновлений для [название продукта].
Запись: дата, номер версии, тип (новое / улучшение / исправление),
заголовок, текст на 2-4 предложения, необязательная картинка.
Лента: записи по убыванию даты, сгруппированы по месяцам,
цветная метка типа, фильтр по типу сверху, поиск по заголовку.
Сверху: короткое описание продукта и кнопка «Получать письма об обновлениях».
Снизу: ссылка на документацию и на форму пожеланий.
Тон: сухой и конкретный, без слов «мы рады представить».

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

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

Какие поля должны быть у записи?

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

Где хранить записи и как их добавлять?

Развилка здесь важнее, чем кажется. Простой вариант: записи лежат прямо в собранной странице, а новая добавляется правкой в чате. «Добавь запись от 12 августа, версия 2.4, тип улучшение, заголовок такой, текст такой». Правка стоит 3 кредита и пересобирает только страницу.

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

Разница ощущается на второй месяц. С базой вы правите одну запись, не пересобирая страницу и не тратя кредит. Без базы каждое обновление это правка сборки. Как подключается база и вход, разобрано в гайде про AI-приложение с Supabase.

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

Как сделать подписку на обновления?

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

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

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

Хранение списка ложится на Supabase, если подписчиков больше горстки. Иначе адреса будут приходить только письмами, и собрать из них список станет отдельной работой.

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

Сколько это стоит?

Бесплатный тариф даёт 5 кредитов на пробу. Pro стоит $25 в месяц за 200 кредитов, это 33 быстрых сборок или 16 платформ, плюс подключение своего домена. Business стоит $99 в месяц.

Одностраничная лента обновлений это обычная сборка за 6 кредитов. Если страница обновлений часть большого сайта продукта с документацией и тарифами, это уже платформа: 12 кредитов за первые три страницы и по 3 за каждую следующую. Каждая последующая правка стоит 3 кредита, в режиме Hi-Fi сборка и правка стоят вдвое дороже.

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

Как писать записи, чтобы их читали?

Сборка страницы это половина дела, вторая половина это дисциплина письма. Тут работают три правила, и все три идут против привычки писать релиз-ноты изнутри команды.

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

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

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

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

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

Где такая страница перестаёт справляться?

Три границы, о которых честно стоит знать заранее.

Автоматическая генерация из коммитов. Changelog, который сам собирается из истории git или из закрытых задач в трекере, это не страница, а конвейер в CI. Билдер соберёт витрину, а конвейер строит разработчик. Экспорт в GitHub отдаёт обычный репозиторий, так что подключить такой конвейер потом можно.

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

Публичная дорожная карта с голосованием. Голоса, дубликаты, модерация и статусы это отдельный продукт со своей логикой. Начать можно доской пожеланий, но не ждите, что она вырастет в полноценный сервис одним промптом.

Для обычного случая, когда продукту нужна честная лента изменений с фильтром и подпиской, вечера достаточно. Если следом планируется сайт сообщества вокруг продукта, тот же подход разобран в гайде про сайт сообщества без кода. Что даёт пометка «проверено» на сборке, объяснено в разборе проверенных сборок Zugo. Начните с описания одной записи на zugo.dev.