How to Build a Product Changelog Page Without Code
To build a product changelog page without code, describe the entry format you want, the labels you use for each kind of change, and where the page links back to your product. An AI builder generates the page, you publish it in one click, and you add each new release afterwards by describing it in chat.
A changelog is the cheapest trust signal a software product has. It shows the thing is alive, it answers "did you fix that yet" without a support ticket, and it gives search engines and language models something concrete to quote. This guide is about building one and, more importantly, keeping it alive.
What actually belongs on a changelog page?
A changelog entry is not a commit message and not a blog post. It sits between the two: written for a user who wants to know what changed for them, dated, and skimmable in five seconds. Four elements carry nearly all the value.
- A date and a version. Both, not one. The date is what a human scans for, the version is what a support conversation refers to.
- A change type label. Added, Fixed, Changed, Removed. Colour-coded labels let a reader filter the page with their eyes instead of reading every line.
- A user-facing sentence. "Exports now include archived projects" beats "refactor export selector." If you cannot write the user-facing version, the change probably does not belong on the page.
- A link where it matters. To the affected screen, to docs, to the issue. Optional, but it turns a note into something actionable.
Anything longer than a paragraph is a blog post with a link from the changelog, not a changelog entry. Keeping that boundary is what stops the page from rotting into an abandoned news feed after six weeks.
What should the prompt say?
The builder needs your format, not your history. Give it the entry shape and three sample entries, and it will generate a page you can extend for years without redesigning anything.
Build a single-page product changelog for [product name].
Layout: reverse-chronological list, newest at top, sticky header
with product name and a link back to [product URL].
Each entry: date, version number, one or more items, each item
tagged Added / Fixed / Changed / Removed with a coloured pill.
Add a year divider between entries from different years.
Include 3 example entries so I can see the pattern, and an
email subscribe field in the header.
Tone: plain, factual, no marketing adjectives.
Dark theme, monospace for version numbers.
Two details are worth naming explicitly. Ask for the year divider up front, because retrofitting it once the page holds forty entries is a fiddly edit. And ask for the tag pills as a fixed set, otherwise later entries drift into inventing new labels and the visual filter stops working.
Which changelog format fits your product?
Not every product needs the same page. The table compares the three shapes people actually ship, so you can pick before you write the prompt rather than after.
| Format | Best for | What it costs you |
|---|---|---|
| Single page, all entries | Products shipping weekly or less | Nothing until the page gets long, then it needs a search box |
| Page plus per-release detail pages | Products with big, explainable releases | A multi-page build, and a new page per major version |
| Changelog inside a hosted tool | Teams who want in-app widgets and email digests out of the box | A monthly fee and a third-party domain in front of your notes |
Most small products should start in the first row. The single page is one build, it lives on your own domain, and it is trivially quotable. Move to the second row only when a release genuinely needs screenshots and migration notes.
How do you add a new release after publishing?
This is the part that decides whether the page survives. In Zugo you add an entry by describing it: "add an entry dated 12 August, version 1.4, one Added item about CSV export and one Fixed item about the timezone bug on the billing screen." The agent inserts it in the right place and keeps the existing formatting.
Each edit consumes credits and each edit is re-verified, which has a useful side effect: you cannot accidentally publish a page that fails to render because you fat-fingered the markup. The build is booted in a sandbox first, and a failure is reported as a failure rather than shown to you as a working page. That lowers the risk of a broken release note, it does not remove it.
If your release cadence is daily, editing by chat every time will feel like friction. Two better options exist: batch a week of changes into one entry, which most readers prefer anyway, or store entries in Supabase and have the page read them, so publishing a release becomes adding a row rather than editing a site.
How do people find out about a new entry?
A changelog nobody revisits is a museum. Three mechanisms cover almost every product, and none of them need code.
Email. The Resend connector lets the subscribe field on the page actually send. Even a monthly digest of what shipped outperforms a page users have to remember to check.
A link from inside the product. The highest-traffic route by far. Put "What's new" in your app's footer or user menu, pointing at your changelog URL on your own domain.
Analytics. Google Analytics tells you whether anyone reads it. If nobody does, the problem is usually placement inside the product, not the page.
What does it cost, and where does it live?
A single-page changelog is a quick build: 6 credits on Zugo. The free tier gives 5 starter credits, Pro is $25 per month with 200 credits, and Business is $99 per month. A custom domain comes with the paid tiers, so the page can sit at changelog.yourproduct.com instead of a builder subdomain.
The code is not locked in. GitHub export creates a real repository you own, which matters for a page you intend to keep for years. The mechanics of that are covered in the guide to exporting an AI-built site to GitHub, and the sandbox check behind the verified label is explained in how verified builds work.
When is a dedicated changelog tool the better choice?
Honest limits, because a changelog is a small page with some genuinely awkward requirements.
In-app widgets and unread badges. Hosted changelog services embed a bell icon in your product and track who has seen what. That is their whole business, and rebuilding it is not a good use of an evening.
Per-customer targeting. Showing enterprise notes only to enterprise accounts means auth, roles, and content rules. Reachable with Supabase, but through a sequence of edits rather than one prompt, and worth a developer's attention if it is business critical.
High-frequency automated publishing. If entries should be generated from merged pull requests without a human writing them, you want a script and an API, not a chat interface.
For a product team that ships a handful of visible changes a week and wants them on its own domain in an hour, building the page yourself is the right call. If you are also standing up a place for users to talk back, the companion guide on building a community site covers that. You can write the first prompt at zugo.dev.