Changelog-Seite ohne Code erstellen: Anleitung mit KI

Changelog-Seite ohne Code erstellen: Aufbau, Pflege, Benachrichtigung

Eine Changelog-Seite entsteht ohne Code, indem Sie einem KI-Builder beschreiben, wie ein Eintrag aussehen soll, welche Kategorien es gibt und wie Nutzer benachrichtigt werden. Zugo baut daraus eine Seite mit datierten Einträgen, Filter und Abonnement-Formular. Eine einzelne Seite kostet 6 Credits, eine mehrseitige Version 12 Credits.

Der schwierige Teil ist nicht der Bau, sondern die Pflege. Ein Changelog, der drei Monate stillsteht, schadet dem Vertrauen mehr, als gar keiner ihn beschädigt hätte. Deshalb behandelt dieser Text die Frage, woher die Einträge kommen, ausführlicher als die Gestaltung.

Wozu braucht ein Produkt eine öffentliche Changelog-Seite?

Ein Changelog beantwortet drei Fragen gleichzeitig, und zwar für unterschiedliche Menschen. Bestandskunden sehen, dass ihr Geld in ein Produkt fließt, das sich bewegt. Interessenten sehen die Entwicklungsgeschwindigkeit, was bei einem jungen Anbieter oft das stärkste Argument ist. Und der Support sieht einen Ort, auf den er verlinken kann, statt dieselbe Antwort zwanzigmal zu schreiben.

Dazu kommt ein interner Nutzen, den viele Teams erst später bemerken. Wer jede Woche zwei Sätze über die eigene Arbeit schreiben muss, merkt schneller, wenn eine Woche nur aus Wartung bestand. Der Changelog wird damit zu einer sehr billigen Form der Selbstkontrolle.

Der ehrliche Gegenpunkt: Ein Changelog ersetzt keine Dokumentation. Er sagt, was sich geändert hat, nicht wie etwas benutzt wird. Diese Trennung sollte auch sichtbar sein, sonst wächst der Changelog zu einem Handbuch mit Datumsangaben. Wie eine saubere Dokumentation daneben aussieht, steht im Text zur Doku-Seite.

Wie ist ein Eintrag aufgebaut, den Nutzer wirklich lesen?

Ein guter Eintrag hat vier Teile und passt in fünf Zeilen. Alles darüber wird überflogen, und zwar auch von interessierten Nutzern.

Drei Kategorien reichen für fast jedes Produkt. Wer mehr einführt, verbringt Zeit mit der Zuordnung statt mit dem Schreiben. Sinnvoll ist eine vierte Markierung nur dann, wenn Sie regelmäßig Dinge entfernen: „Entfällt" ist für Nutzer die wichtigste Kategorie überhaupt, weil sie planen müssen.

Schreiben Sie aus Sicht der Person, die das Produkt benutzt, nicht aus Sicht des Teams. „Wir haben den Cache-Layer refaktoriert" ist für niemanden außerhalb der Firma eine Information. „Listen mit vielen Einträgen öffnen sich deutlich schneller" ist dieselbe Arbeit, verständlich erzählt.

Woher kommen die Einträge: fest eingebaut oder aus einer Datenbank?

Das ist die eigentliche Architekturentscheidung, und sie hängt allein von der Veröffentlichungsfrequenz ab.

Bei wenigen Einträgen im Monat genügt eine feste Seite. Ein neuer Eintrag entsteht per Bearbeitung für 3 Credits und ist in einer Minute online. Der Vorteil ist, dass nichts anzubinden ist. Der Nachteil zeigt sich, sobald mehrere Personen schreiben sollen.

Bei wöchentlicher Veröffentlichung oder mehreren Autoren gehören die Einträge in eine Datenbank. Supabase übernimmt das: Jeder Eintrag ist ein Datensatz mit Datum, Kategorie, Titel und Text, die Seite liest die Liste aus und sortiert sie. Neue Einträge entstehen dann über eine geschützte Eingabemaske, ohne dass jemand den Builder öffnen muss und ohne dass dabei Credits anfallen.

Der zweite Aufbau ist auch der einzige, der Filter und Suche sinnvoll macht. Solange zehn Einträge fest im Text stehen, ist ein Filter Dekoration. Ab fünfzig Einträgen ist er die Funktion, wegen der die Seite überhaupt benutzt wird.

Wie sieht der Prompt für den ersten Build aus?

Beschreiben Sie Struktur und Sprache, nicht die Farben. Ein Changelog ist eine der wenigen Seiten, bei denen die Textregeln wichtiger sind als das Aussehen.

Changelog-Seite für ein Rechnungsprogramm für Kleinbetriebe. Umgekehrt chronologische Liste, neueste Einträge oben, gruppiert nach Monat. Jeder Eintrag mit Datum, Kategorie aus Neu, Verbessert oder Behoben, kurzem Titel und zwei Sätzen Erklärung in Nutzersprache. Filter nach Kategorie oben. Am Ende ein Formular, um Änderungen per E-Mail zu abonnieren, mit Feld für die Adresse. Nüchterner Ton, keine Werbesprache, keine Ausrufezeichen. Zehn Beispieleinträge zum Ersetzen.

Die letzte Zeile spart Zeit: Mit Beispieleinträgen sehen Sie sofort, wie die Seite mit echtem Inhalt wirkt, und tauschen die Texte anschließend aus. Vor der Auslieferung prüft eine Sandbox, ob das Projekt startet: Ein Build, der sich nicht öffnen lässt, wird nicht ausgegeben.

Was kostet eine Changelog-Seite an Credits?

Abgerechnet wird pro Aktion, nicht pro Eintrag und nicht pro Besucher.

Free enthält 5 Credits und reicht für den ersten Bau. Pro kostet $25 im Monat mit 200 Credits, was etwa 66 Bearbeitungen entspricht. Business liegt bei $99 im Monat mit 800 Credits.

Rechnen Sie einmal nach, bevor Sie sich für die feste Seite entscheiden: Ein Eintrag pro Woche sind über fünfzig Bearbeitungen im Jahr. Genau an dieser Stelle wird die Datenbanklösung günstiger und gleichzeitig bequemer.

Wie erfahren Nutzer von neuen Einträgen?

Eine Changelog-Seite, die niemand aufruft, ist ein Archiv. Der Weg zum Leser führt über drei Kanäle, und der wichtigste ist der unauffälligste.

Der erste ist der Link im Produkt selbst, meist im Menü unter dem Kontonamen oder in der Fußzeile. Er kostet nichts und bringt die meisten Aufrufe. Der zweite ist die E-Mail: ein kurzes Abonnement-Formular auf der Seite, die Adressen in Supabase, der Versand über Resend. Wie die Anbindung eingerichtet wird, steht im Text zu Resend im KI-Builder.

Der dritte Kanal ist die Benachrichtigung im Produkt selbst, etwa ein kleiner Punkt am Menüeintrag, wenn es etwas Neues gibt. Das ist die wirksamste Variante und zugleich die aufwendigste, weil sie Zustand pro Nutzer braucht.

Ein Hinweis zur Ehrlichkeit: Einen fertigen Feed für Newsreader bringt der Builder nicht mit. Wenn Sie ihn brauchen, ist er zusätzliche Arbeit. Für die meisten Produkte trägt der E-Mail-Weg weiter, weil er die Leser dort erreicht, wo sie ohnehin nachsehen.

Welche Fehler machen Changelogs unlesbar?

Vier Muster tauchen fast überall auf, wo Changelogs einschlafen.

• Interne Kürzel. Ticketnummern und Modulnamen sagen außerhalb des Teams nichts.
• Sammelposten. „Diverse Fehlerbehebungen und Verbesserungen" ist die höfliche Form von Schweigen.
• Werbesprache. Ein Changelog, der jede Zeile feiert, wird nicht mehr geglaubt, wenn wirklich etwas Großes kommt.
• Fehlende Daten. Ohne Datum ist ein Eintrag nicht überprüfbar, und genau die Überprüfbarkeit ist der Zweck der Seite.

Ein fünfter Punkt betrifft die Stille. Wenn zwei Monate nichts erscheint, schreiben Sie lieber einen kurzen Eintrag über Wartung und Stabilität, als die Lücke stehen zu lassen. Leser deuten Lücken schlechter, als sie sind.

Wo liegen die Grenzen dieser Lösung?

Drei Grenzen sollten Sie kennen. Erstens entstehen die Einträge nicht automatisch aus Ihren Commits oder Tickets. Es gibt keine fertige Verbindung zum Issue-Tracker, die aus einem Prompt erwächst. Das Schreiben bleibt Handarbeit, und das ist im Ergebnis meist ein Vorteil.

Zweitens ersetzt Zugo bei einem komplexen Produktivbetrieb kein Entwicklungsteam. Ein Changelog mit Mandantentrennung, Rechten pro Nutzergruppe und Übersetzungen in mehrere Sprachen ist ein eigenes Projekt.

Drittens braucht sehr spezifische Logik mehrere Bearbeitungen, etwa eine Zuordnung von Einträgen zu Produktversionen oder ein Archiv, das nach Jahr und Kategorie blättert. Wer daneben auch den Betriebszustand zeigen will, findet den passenden Aufbau im Text zur Statusseite.

Was folgt nach dem Veröffentlichen?

Nach dem Veröffentlichen liegt die Seite unter einer Adresse wie changelog-ihrprodukt.zugo.run. Verbinden Sie danach eine eigene Adresse, verlinken Sie die Seite im Produkt und legen Sie einen festen Termin für das Schreiben fest, am besten denselben Wochentag. Der Termin ist wichtiger als jede Funktion auf der Seite.

Ein erster Entwurf passt in die 5 Credits des Free-Tarifs auf https://zugo.dev. Wie die Seite mit echten Einträgen wirkt, sehen Sie am schnellsten, indem Sie die letzten zehn Änderungen aus Ihrem Ticketsystem eintragen und danach entscheiden.