Build in Public: So entwickeln wir unser Kassensystem

Wer eine Software einsetzt, will wissen, ob sie noch lebt. Bei einem Kassensystem fürs Festival, Vereinsfest oder den Weihnachtsmarkt ist das doppelt wichtig: Es geht um euer Geld, euer Personal, euren Abend. Deshalb entwickeln wir ebing als Build in Public Kassensystem — mit öffentlichen Release Notes, einer einsehbaren Roadmap und einem kurzen Draht für eure Wünsche.

Warum Software hinter verschlossenen Türen scheitert

Die meisten SaaS-Produkte machen es so: Nach dem Login gibt's hin und wieder ein „What's new"-Popup, hin und wieder einen Newsletter, ansonsten Stille. Was geplant ist, weiß nur das Produkt-Team. Ob das Feedback aus dem Support-Chat irgendwo angekommen ist, bleibt unklar. Und wenn drei Monate kein Update kommt, fragt man sich, ob der Anbieter überhaupt noch existiert.

Für ein Tool, das ihr im Live-Betrieb einer Veranstaltung benutzt, ist diese Intransparenz ein echtes Problem. Ihr braucht Verlässlichkeit: Was wurde diese Woche verbessert? Wird die Wunsch-Funktion, die ihr letzten Sommer angefragt habt, eigentlich noch umgesetzt? Und kann ich kurzfristig melden, dass etwas hakt — mit der Aussicht, dass jemand das auch wirklich liest?

Build in Public bei einem Kassensystem — was das konkret heißt

Build in Public bedeutet nicht „wir bloggen viel über uns selbst". Es bedeutet, dass die Bausteine, mit denen das Produkt entsteht, sichtbar sind. Bei einem Build in Public Kassensystem heißt das drei Dinge:

• Release Notes, die jeder lesen kann — nicht versteckt im Login-Bereich, sondern öffentlich unter /changelog.
• Eine öffentliche Roadmap unter /roadmap, die zeigt, was vorgeschlagen, geplant oder schon erledigt ist — inklusive der Frage, woher die Idee kam.
• Ein schneller Feedback-Weg, über den jede Anfrage entweder umgesetzt wird oder zumindest sichtbar in der Roadmap landet.

Im Dashboard signalisiert eine Glocke, sobald es neue Einträge gibt. So sehen aktive Nutzer Updates direkt im Arbeitsfluss, ohne dass wir mailen müssen.

Release Notes statt Versionsnummern

Klassische Versionsnummern wie „v2.4.1" sagen euch wenig. Was hat sich geändert? Müsst ihr aufpassen? Lohnt das Reinschauen? Ein Build in Public Kassensystem ersetzt Versionsnummern durch lesbare Release Notes mit konkretem Nutzen: Was kann das Tool jetzt, was vorher nicht ging — und für wen ist die Änderung relevant?

Bugfixes und Sicherheits-Patches landen bewusst nicht in den Release Notes. Das wäre Rauschen und würde die interessanten Updates untergehen lassen. Sichtbar wird nur, was eure Arbeit am Veranstaltungstag verändert: neue Funktionen, größere Verbesserungen, Anpassungen, die einen Workflow umkrempeln. Wer mag, kann jederzeit in den Release Notes nachschlagen, was zuletzt passiert ist.

Die öffentliche Roadmap: Wünsche werden sichtbar

Die Roadmap zeigt, wohin sich ebing entwickelt — geordnet nach Status: Vorgeschlagen, Geplant, In Arbeit, Erledigt. Jeder Eintrag enthält, woher die Idee kam (mit Zustimmung gerne namentlich), wann sie hereinkam und woran wir gerade arbeiten.

Beispiel: Die Anbindung an ein VR-Pay-Me-Kartenterminal ist ein Wunsch eines Vereinsfest-Veranstalters von Mai 2026 — sichtbar unter „Vorgeschlagen", inklusive Kontext, warum die manuelle Verbuchung über das Lesegerät heute nervt. Wer dieselbe Funktion braucht, sieht sofort: Andere haben das auch gefragt, und es ist im Blick.

Wichtig ist uns dabei: Ein Roadmap-Eintrag ist kein Liefertermin, sondern eine ehrliche Zustandsanzeige. Das ist mehr wert als ein optimistisches Marketing-Datum, das später kassiert wird.

User Activation: Vom passiven Nutzer zum Mitgestalter

Der vielleicht wichtigste Effekt von einem Build in Public Kassensystem ist nicht SEO oder Marketing — es ist User Activation. Wer sieht, dass die eigene Anfrage in der Roadmap auftaucht, später als „In Arbeit" markiert wird und schließlich in den Release Notes auftaucht, fühlt sich anders an das Produkt gebunden als jemand, der nur ein anonymes Standard-Tool benutzt.

Der Feedback-Loop ist dabei bewusst kurz:

1. Wunsch reinmelden — formlos, per Mail oder Chat.
2. Eintrag in der Roadmap mit Status „Vorgeschlagen".
3. Statuswechsel sichtbar (Geplant → In Arbeit), sobald der Wunsch ins Backlog rückt.
4. Release Notes plus Glocke im Dashboard, wenn die Funktion live ist.

Aus dem passiven Nutzer wird auf diesem Weg ein Mitgestalter — ohne Slack-Community, ohne Forum, ohne Aufwand auf eurer Seite.

So gebt ihr Feedback

Wenn ihr eine Funktion braucht, die ebing noch nicht hat, oder wenn etwas hakt: Ein kurzer Hinweis reicht. Auf der Über-uns-Seite findet ihr den direkten Draht. Wir tragen den Wunsch in die Roadmap ein — auf Wunsch namentlich, sonst anonym. Damit landet eure Idee da, wo sie nicht vergessen wird, und ihr seht selbst, wenn sich der Status bewegt.

Fazit

Ein Build in Public Kassensystem nimmt etwas Kontrolle aus dem Anbieter-Team und gibt sie an die Leute, die das Tool tatsächlich am Tresen, am Stand oder an der Kasse benutzen. Wer reinguckt, sieht: Was kommt, was läuft, was schon geht. Wer mitredet, sieht das Eigene wiederauftauchen.

ebing ist kostenlos für Veranstalter. Jetzt registrieren und die Release Notes mitlesen — keine Kreditkarte nötig.