Premium: zum ersten Mal über Geld nachdenken

Bis 2023 war Yurna vollständig kostenlos, und das war nie eine Entscheidung, sondern der Ausgangszustand. Irgendwann habe ich zusammengerechnet, was das Projekt tatsächlich kostet — nicht an Geld, sondern insgesamt.

Die Rechnung

Geld: Server, Domain, Sicherungsspeicher. Ein überschaubarer zweistelliger Betrag im Monat. Nicht schön, aber tragbar.

Zeit: Deutlich mehr. Support, Fehlersuche, Migrationen, Updates. Grob geschätzt mehrere Stunden pro Woche, in Migrationsphasen ein Vielfaches. Das ist der Posten, der wehtut.

Verpflichtung: Der schwerste Punkt, und der unsichtbarste. Es gibt Leute, die den Bot benutzen. Wenn ich drei Wochen nichts mache, läuft er zwar weiter, aber Anfragen bleiben liegen, und irgendwann ist das keine Kulanz mehr, sondern schlechter Service.

Die ehrliche Frage lautete: Kann ich das die nächsten fünf Jahre so weitermachen? Die Antwort war nein.

Die Modelle, die ich durchgespielt habe

Spenden. Am einfachsten umzusetzen und in der Praxis unzuverlässig. Wer spendet, erwartet trotzdem Support, und die Einnahmen schwanken so stark, dass sie keine Planung erlauben. Als Ergänzung sinnvoll, als Grundlage nicht.

Werbung. Ausgeschlossen. In einem Bot, der auf fremden Servern läuft und dort Nachrichten schreibt, ist Werbung eine Zumutung für Leute, die nie zugestimmt haben.

Kostenpflichtig ab Größe X. Der Bot ist kostenlos, ab einer bestimmten Servergröße kostet er. Klingt fair und bestraft genau die, die den größten Aufwand verursachen und gleichzeitig am meisten Reichweite bringen.

Funktionsbasiert. Der Kern bleibt kostenlos, bestimmte Zusatzfunktionen kosten. Das ist der verbreitete Weg, und ich habe mich dafür entschieden — mit einer Einschränkung, auf die ich gleich komme.

Bezahlte Instanz. Wer will, bekommt eine eigene Installation mit eigener Datenbank, betreut. Das ist eher Dienstleistung als Produkt und passt nicht zu einem Nebenprojekt.

Meine Einschränkung: Was niemals hinter Bezahlung gehört

Das war der Teil, über den ich am längsten nachgedacht habe. Es gibt Funktionen, die man technisch begrenzen kann, bei denen es sich aber falsch anfühlt.

Moderationswerkzeuge nicht. Ein Server, der sich gegen Spam wehren muss, darf nicht dafür bezahlen müssen. Das ist keine Zusatzfunktion, sondern Grundausstattung.

Datenexport nicht. Seine eigenen Daten mitnehmen zu können, darf nie eine Bezahlfunktion sein. Sonst ist es keine Funktion, sondern eine Geisel.

Verfügbarkeit nicht. Der kostenlose Bot darf nicht künstlich schlechter laufen. Wenn er wackelt, wackelt er für alle.

Was übrig bleibt, sind Funktionen, die Komfort, Umfang oder Rechenaufwand betreffen: mehr gleichzeitige Verlosungen, längere Aufbewahrung von Abschriften, ausführlichere Statistiken, eigene Gestaltung von Nachrichten. Sachen, die schön sind, ohne die aber niemand aufgeschmissen ist.

Infobox

Diese Liste ist bis heute meine Richtschnur bei allem, was Geld kostet — auch bei den Minecraft-Servern und dem Laden, der später dazukam. Die Frage lautet nie „was kann ich begrenzen", sondern „was darf ich nicht begrenzen, ohne dass es unfair wird". Der Rest ergibt sich daraus.

Was technisch dranhing

Ich hatte unterschätzt, wie viel Aufbau ein Bezahlmodell braucht, bevor man den ersten Euro sieht.

Ein Rechtemodell für Funktionen, das an einer Stelle entscheidet, ob eine Funktion verfügbar ist — nicht verstreut in dreißig Befehlen.
Ein Zustand pro Server, der nicht nur „ja/nein" kennt, sondern auch „läuft ab am", „gekündigt, aber noch gültig bis", „Zahlung fehlgeschlagen, Nachfrist".
Ein Weg, Zugang ohne Zahlung zu vergeben — für Tester, für Freunde, für Community-Partner. Und ein Protokoll darüber, wer wem was gegeben hat.
Ein sauberes Verhalten beim Ablauf. Was passiert mit den zehn Verlosungen, wenn das Limit wieder bei drei liegt? Meine Antwort: Bestehendes läuft aus, Neues wird begrenzt. Nichts wird gelöscht, nichts bricht ab.

Der letzte Punkt hat mich am meisten Zeit gekostet und ist der, den Nutzer am ehesten bemerken. Ein Modell, das beim Auslaufen Daten wegwirft, ist ein Modell, dem man nicht traut.

Die Zustände, die ein Bezahlmodell braucht

Der Teil, den ich am meisten unterschätzt hatte: Ein Zugang ist kein Schalter, sondern ein Zustand mit Übergängen.

Zustand	Bedeutung	Was gilt
kostenlos	nie bezahlt	Grundumfang
aktiv	bezahlt, läuft	voller Umfang
gekündigt	bezahlt, läuft aus	voller Umfang bis zum Ende
Zahlung offen	Abbuchung fehlgeschlagen	voller Umfang, Nachfrist
abgelaufen	Zeitraum vorbei	Grundumfang, Daten bleiben
geschenkt	vergeben ohne Zahlung	voller Umfang, eigener Vermerk

Sechs Zustände statt zwei. Und jeder Übergang dazwischen braucht eine Entscheidung: Was passiert mit dem, was über dem Grundumfang liegt?

Meine Antwort war durchgehend dieselbe: Bestehendes läuft aus, Neues wird begrenzt. Wer zehn Verlosungen laufen hat und auf ein Limit von drei zurückfällt, verliert keine davon — er kann nur keine neuen anlegen, bis er unter dem Limit ist.

Warum ich den Zahlungsteil aufgeschoben habe

Ehrlich: nicht aus technischen Gründen. Sondern weil ich vor dem gewechselten Verhältnis zurückgeschreckt bin.

Solange etwas kostenlos ist, ist jede Hilfe Kulanz. Sobald jemand bezahlt, ist sie eine Leistung. Ein Ausfall ist dann nicht mehr ärgerlich, sondern ein Mangel. Und die Frage, wann ich antworte, ist keine Frage meiner Zeit mehr.

Das ist keine technische Hürde, sondern eine Entscheidung darüber, wie viel Verpflichtung man neben allem anderen tragen will. Ich habe sie lange nicht getroffen und stattdessen die Struktur gebaut — was rückblickend die richtige Reihenfolge war, aber auch eine bequeme Art, der Entscheidung auszuweichen.

Was ich mir dabei angewöhnt habe: Wenn ein Punkt mehrere Jahresrückblicke übersteht, ist der Grund selten Zeitmangel. Dann ist es besser, ihn ausdrücklich als „will ich gerade nicht" zu benennen, statt ihn wieder als Vorsatz mitzuschleppen.

Wo ich Ende 2023 stand

Ehrlich gesagt: mitten drin. Die Struktur stand — Funktionsrechte, Zustände, Vergabe ohne Zahlung, Ablaufverhalten. Der Zahlungsteil selbst war noch nicht scharf geschaltet.

Rückblickend war genau diese Reihenfolge richtig. Die Frage „wie nehme ich Geld ein" ist gelöst, sobald man einen Anbieter einbindet. Die Frage „was passiert mit einem Server, dessen Zahlung ausläuft" ist nicht gelöst, sondern durchdacht — und wer damit anfängt, baut ein Modell, das man später nicht bereut.