Kostenlos heißt nicht anspruchslos: eine Web-App nach einem Jahr Produktion

Vor gut einem Jahr haben wir grounds-up.coffee an den Start gebracht, ein Werkzeug für Meetings und Retros, die zu einem Ergebnis führen. Es bricht bewusst mit fast allem, was als Pflicht gilt, wenn man eine Web-App „richtig“ baut. Es kostet nichts und wird es auch bleiben, es verlangt keine Anmeldung, und was Menschen darin eingeben, lebt nur so lange, wie es der Zweck erfordert. Nach der üblichen Rechnung müsste ein Produkt, das nichts einspielt und keine Nutzer bindet, bei allem anderen sparen.

Genau das war nicht der Plan. Das ist nicht unsere erste Anwendung, und wir wissen, was ein Produkt braucht, das Menschen täglich benutzen. Neu waren zwei Dinge: Diese Anwendung ist von der ersten Zeile an vollständig mit KI entwickelt worden, und sie war von Anfang an als dauerhaft kostenfrei geplant. An den Standards, die wir an jedes produktive Kundenprodukt anlegen, sollte beides nichts ändern.

Ein Produkt muss dein Problem lösen, nicht deine Daten sammeln.

Ein Jahr Produktion war der ehrliche Test für diesen Anspruch, und es hat eine Reihe von Entscheidungen bestätigt, die du für deine eigene Web-App mitnehmen kannst. Im Folgenden geht es nicht um das Produkt, sondern um genau diese Entscheidungen.

Kostenlos war eine Entscheidung, kein Rabatt

Kostenlos und ohne Anmeldung war keine Preisfrage, sondern eine über Reibung: Jede Hürde vor dem Moment, in dem ein Werkzeug sein Problem löst, kostet Nutzung, und ein Konto ist so eine Hürde. Dass es sich nicht selbst bezahlen muss, liegt daran, dass wir es selbst nutzen, in der Arbeit mit unseren Kunden. Es erleichtert diese Zusammenarbeit so spürbar, dass sich der Betrieb über diesen Nutzen trägt und nicht über eine Rechnung. Und viele Kunden bleiben dabei: Sie mögen das Werkzeug so sehr, dass sie es auch für ihre eigenen Meetings weiterverwenden, ganz ohne uns.

Daraus folgt der eigentliche Druck, Standards zu halten, und er ist größer als bei einem bezahlten Nebenprodukt. Dieses Werkzeug steht im direkten Kontakt mit unseren Kunden, es ist ein Stück unseres Rufs. Ein Sicherheits- oder Datenschutzvorfall hier wäre kein ärgerlicher Bug, sondern ein Reputationsschaden an genau der Stelle, von der wir leben. Kostenlos senkt also nicht den Anspruch, es hebt ihn. Die Frage, die den Rest dieses Artikels trägt, lautet deshalb: Wie hält man die höchsten Standards mit einem Aufwand, der zu einem Produkt ohne eigene, direkte Einnahmen passt? Die folgenden Abschnitte sind die Antworten, eine pro Entscheidung.

Ohne Konto, trotzdem sicher

Stell dir vor, jemand will in zwei Minuten eine Retro mit vier Leuten starten und landet zuerst auf einer Registrierungsmaske, danach im Postfach, auf der Suche nach der Bestätigungsmail. Die Hälfte der Runde ist schon abgelenkt, bevor das eigentliche Meeting beginnt. Die naheliegende Frage lautet: Wie kann ein Zugang sicher sein, wenn wir auf genau diese Anmeldung verzichten?

Die Antwort beginnt damit, zwei Dinge zu trennen, die oft in einen Topf geworfen werden. Ein Konto beantwortet, wer du dauerhaft bist. Für ein Meeting ist aber nur die Frage wichtig, ob du dort hingehörst oder nicht, und die lässt sich ohne dauerhafte Identität beantworten.

Das läuft so: Wer moderiert, legt einen Raum an und hält dafür einen eigenen Schlüssel, der nur lokal in seinem Browser liegt. Jeder Teilnehmer bekommt beim Beitreten automatisch seinen eigenen, ohne irgendeine Anmeldung. Über die Raum-Kennung wird dann der Zutritt angefragt, und der Moderator entscheidet, wer hereinkommt und wer wieder hinausfliegt. Die Kennung selbst teilt er auf dem Weg, den die Runde ohnehin nutzt, per Slack, Teams, Mail oder einfach im Videochat, in dem alle längst sitzen. Kein Konto, kein Passwort, kein E-Mail-Pingpong, bis man endlich loslegen darf.

So weit die Idee, die sich auf viele Produkte übertragen lässt. Die eigentliche Sorgfalt steckt aber darunter, an den Stellen, die der Nutzer nie sieht.

Sie folgt einem Prinzip, das man auf jede Web-App übertragen kann: Der Browser ist Feindgebiet, nur der Server entscheidet. Alles, was im Browser läuft, kann ein Nutzer verändern, also darf nichts Wichtiges allein dort hängen. Die Uhr, die eine Meeting-Phase begrenzt, läuft deshalb auf dem Server und nicht im Browser, sonst könnte man sich mit einem Handgriff in den Entwicklerwerkzeugen mehr Zeit verschaffen. Der Schlüssel des Moderators gibt im Browser nur vor, wer er ist; ob er wirklich moderieren darf, prüft jedes Mal der Server.

Wer dieses Prinzip einmal verinnerlicht hat, trifft die meisten Sicherheitsentscheidungen fast von selbst richtig. Es ist mehr wert als jede einzelne Maßnahme, weil es erklärt, warum eine Anmeldung allein nichts sichert: Ein Login beantwortet nur, wer jemand ist, nicht, ob der Server bei jeder Aktion noch einmal nachprüft.

Daten, die sich nicht zurückrechnen lassen

Jedes Produkt steht irgendwann vor derselben Versuchung: Man möchte verstehen, wie es benutzt wird, und der einfachste Weg scheint zu sein, möglichst viel mitzuschneiden. Wir wollten das Gegenteil, nämlich so wenig wie möglich festhalten. Das klingt zunächst widersprüchlich, denn wie soll man aus der Nutzung lernen, ohne den Nutzern dabei über die Schulter zu schauen?

Ein Meeting-Werkzeug sieht zwangsläufig, was Menschen hineinschreiben, und solange der Raum lebt, liegen diese Inhalte auch gespeichert, damit ein Neustart die Sitzung nicht zerstört. Der Unterschied liegt darin, was danach passiert. Läuft der Raum ab, wird er samt Inhalt automatisch gelöscht, ohne dass jemand eine Taste drücken muss.

Was übrig bleibt, ist eine reine Statistik, und die ist so gebaut, dass sie sich nicht auf eine Person zurückrechnen lässt. In dem Moment, in dem ein Raum verschwindet, wird festgehalten, wie lange die Phasen gedauert haben und wie viele Themen besprochen wurden, nicht aber, was besprochen wurde oder von wem. Auch die Zugriffe auf die Anwendung werden mitgezählt, aber die Adressen, die einen einzelnen Besucher verraten würden, sind da längst durch neutrale Platzhalter ersetzt.

Der überraschende Teil ist, dass gerade dieser Verzicht den klareren Blick ergeben hat. Weil jeder angelegte Raum einen anonymen Punkt in der Statistik hinterlässt, sieht man den ganzen Trichter: wie viele Räume eröffnet, wie viele wirklich gestartet und wie viele bis zum Ende durchgezogen wurden. Wo viele abbrechen, stimmt etwas nicht, und das zeigt sich hier, ohne dass man auch nur einem einzigen Menschen über die Schulter geschaut hätte.

Diese Datensparsamkeit ist bei uns kein nachträglicher Datenschutz-Anstrich, sondern ein Prinzip, nach dem wir ohnehin arbeiten. Wir betreiben und entwickeln unsere Produkte nach den Grundsätzen der ISO 27001, auch ohne dafür ein Zertifikat an der Wand zu haben. Nur das zu erheben, was eine Funktion wirklich braucht, und es nach Ablauf wieder loszuwerden, ist genau so ein Grundsatz. Dass gerade kein Umsatz an den Daten hing, hat die Entscheidung übrigens leicht gemacht: Es gab schlicht keinen Grund, etwas aufzuheben, mit dem man später vielleicht hätte Geld verdienen wollen. Der Grundsatz schützt die Nutzer, und nebenbei schützt er uns, weil Daten, die gar nicht erst liegen bleiben, auch nicht verloren gehen können.

Der kürzeste Draht: Feedback im Produkt

Wenn man anonym misst, sieht man zwar, dass Menschen an einer Stelle abbrechen, aber nicht, warum. Diese Lücke schließt kein noch so ausgefeiltes Analyse-Dashboard, sondern ein kurzer Draht zu den Menschen selbst. Deshalb gibt es im Produkt von Anfang an eine unkomplizierte Möglichkeit, einen Fehler oder einen Wunsch loszuwerden, ohne das Werkzeug zu verlassen und ohne ein Formular auf einer fremden Seite zu suchen.

Das ist aus unserer Sicht die wichtigste Funktion überhaupt, und sie sollte das Erste sein, was man baut, nicht das Letzte. Ein direkter Rückkanal verwandelt Nutzung in Gespräch. In der Praxis kam so eine Rückmeldung oft morgens herein und war innerhalb weniger Tage als Verbesserung wieder draußen, die dann allen half und nicht nur dem einen, der sich gemeldet hatte.

Dieser enge Kreislauf aus echter Nutzung, direktem Feedback und schneller Verbesserung ist etwas anderes als eine Roadmap, die einmal im Quartal in einer Sitzung weit weg vom Nutzen entsteht. Er hält das Produkt an der Wirklichkeit, und er ist der Grund, warum ein kleines, kostenloses Werkzeug über ein Jahr hinweg genau dort reifen konnte, wo es die Menschen drückte.

Ein direkter Rückkanal verwandelt Nutzung in ein Gespräch, aus dem in Tagen Verbesserungen werden.

Gebaut mit KI, von der Idee bis zum Deploy

Heute entsteht ein erstes lauffähiges Ding oft an einem Wochenende, mit KI an jeder Stelle: beim Schärfen des Konzepts, beim Formulieren der Anforderungen, beim Schreiben des Codes, beim Testen. Diese Anwendung ist von der ersten Zeile an so entstanden. Wenn das Bauen aber so schnell geht, drängt sich die Frage auf, warum ein Produkt trotzdem Monate braucht, bis man es guten Gewissens live lässt. Was fehlt zwischen „läuft bei mir“ und „läuft verlässlich für alle“?

Die Antwort ist, dass der Code nie der schwierige Teil war. Der schwierige Teil ist alles, was ihn verlässlich in Produktion hält, und genau hier zahlt sich Erfahrung aus, die kein Modell mitbringt. Es gibt bei uns, wie bei jedem ernsthaften Produkt, getrennte Umgebungen für Entwicklung, für die Erprobung und für den echten Betrieb, und eine Bereitstellung läuft über eine Pipeline, die prüft, bevor sie ausliefert. Die KI beschleunigt jeden einzelnen Schritt darin, aber dass es diese Schritte überhaupt gibt und in welcher Reihenfolge sie greifen, ist eine Entscheidung, die man selbst treffen und verantworten muss.

Wie dieses schnelle Starten mit KI gelingt und wie sich eine Deployment-Pipeline verändert, wenn die KI mitarbeitet, haben wir an anderer Stelle beschrieben. Wie du klein startest, ohne dich zu übernehmen, und was Continuous Integration im Zeitalter der KI bedeutet, vertiefen zwei eigene Artikel. Hier zählt nur der eine Punkt: Die KI senkt die Hürde zum Bauen, nicht die zum Betreiben.

Abhängigkeiten sauber halten

Montagmorgen, der Sicherheitsscanner meldet eine Schwachstelle in einem Paket, das irgendwo tief in den Abhängigkeiten steckt. Der Reflex ist, schnell die neueste Version einzuspielen und weiterzumachen, Haken dran. Wir haben uns angewöhnt, an dieser Stelle kurz innezuhalten und eine andere Frage zuerst zu stellen, und diese Gewohnheit hat sich als eine der tragenden herausgestellt.

Vor dem Aktualisieren steht bei uns eine Inventur. Welchen Zweck erfüllt diese Bibliothek, wird sie überhaupt noch gepflegt, und nutzen wir ihren vollen Umfang oder nur einen kleinen Teil davon? Oft lautet die ehrliche Antwort, dass sie eine Kleinigkeit erledigt, die man genauso gut selbst schreiben kann, und dann fliegt sie raus. Lässt sie sich nicht entfernen, gehört sie vielleicht nur in die Entwicklung und nicht in das ausgelieferte Produkt, womit sie aus der Schusslinie ist. Eigener Code ist nicht automatisch sicherer als eine Bibliothek, aber er ist im eigenen Kontext leichter zu prüfen und zu verantworten.

Dass gerade die Pflege den Ausschlag gibt, ist kein nebensächlicher Punkt. Open-Source-Bibliotheken sind großartig, in ihnen steckt oft viel Wissen und Arbeit, die niemand sinnvoll noch einmal selbst leisten will. Genau dieselbe Bibliothek wird aber zum Risiko, sobald sie niemand mehr pflegt, weil dann bekannte Lücken offen bleiben und niemand mehr reagiert.

Ein eigenes Beispiel aus dem Betrieb: Zur Überwachung der Lizenzen in unseren Projekten lief lange das Werkzeug license-checker. Es ist seit Jahren nicht mehr gepflegt, was man schon daran sieht, dass die Gemeinschaft es in zahlreiche Forks aufgespalten hat. Mit der fehlenden Pflege schleppte es über seine eigenen Abhängigkeiten bekannte Schwachstellen mit, ausgerechnet ein Werkzeug, das Sorgfalt sicherstellen sollte. Die Konsequenz war der Wechsel in allen Projekten, und das ist genau die Art von Entscheidung, die eine Inventur auslöst und ein Schnellschuss übersieht.

Dazu kommt ein fester Blick auf die Lizenzen: Jede eingesetzte Bibliothek muss mit dem Produkt vereinbar sein, und dafür haben wir einen Standard, den wir konsequent anwenden. Das ist unspektakulär und wird oft übersehen, aber es ist Teil derselben Sorgfalt. Ein sauberer Abhängigkeitsbaum ist nicht nur sicherer, er ist auch ehrlicher darüber, worauf ein Produkt wirklich steht.

Warum das 2026 mehr zählt als je

In den ersten Betriebstagen fiel beim Blick in die Zugriffe etwas auf: Ein großer Teil davon kam gar nicht von Nutzern, sondern von automatischen Scannern, die wahllos nach bekannten Lücken suchten. Das wirft eine unbequeme Frage auf, gerade für ein kleines, kostenloses Werkzeug, das niemandem wehtut: Warum klopft überhaupt jemand an, bei einem Produkt, das für niemanden ein lohnendes Ziel sein dürfte?

Die Antwort liegt darin, dass sich die Angriffslage grundlegend gedreht hat. Früher brauchte ein Angriff ein Ziel, das sich lohnte, denn hinter der Tastatur saß ein Mensch, dessen Zeit Geld kostete. Ein kleines, kostenloses Werkzeug war schlicht zu unwichtig, um ins Visier zu geraten.

Das hat sich umgekehrt. Automatisierung und inzwischen auch KI haben die Kosten eines Angriffs pro Ziel so weit gedrückt, dass es sich lohnt, einfach das gesamte Internet abzuklopfen und mitzunehmen, was antwortet. Sicherheitsforscher beschreiben, wie KI-gestützte Angriffe die Kosten pro Ziel auf wenige Dollar senken und damit Massenangriffe möglich machen, die früher zu teuer waren (Dark Reading, 2026). Wer online ist, ist damit ein Ziel, egal wie klein oder unscheinbar.

Wie real das ist, zeigte sich Ende 2026 an einer unerwarteten Stelle. Im Oktober und November wurden über die Grenzen vieler europäischer Länder hinweg die ans Internet angeschlossenen Kühlsteuerungen hunderter Supermärkte angegriffen, Temperaturen hochgedreht, Ware verdarb (Palo Alto Unit 42, 2026). Niemand hatte es auf eine bestimmte Filiale abgesehen. Verwundbar und erreichbar zu sein, genügte, und Sicherheitsforscher fanden Tausende solcher Steuerungen offen im Netz (Euronews, 2026).

Gegen diese Art von Druck hilft kein großes Sicherheitsteam, sondern eine nüchterne Bauweise. Die Anwendung steht hinter mehreren Schichten, die jeweils eine Aufgabe haben: Ein vorgelagertes CDN mit einer Web Application Firewall fängt den groben Unfug schon weit draußen ab. Dahinter nimmt ein Loadbalancer die Verbindungen entgegen und baut sie neu auf, bevor etwas den Container erreicht. Und der eigentliche Container läuft auf einem bewusst minimalen, aktuellen Basis-Image, das kaum Angriffsfläche bietet.

Dass der Loadbalancer die Verbindung terminiert, ist dabei mehr als Technik-Detail. Eine Anfrage durchläuft viele Schichten, IP, TCP, TLS, HTTP, die Header, und in jeder davon steckt potenziell eine Lücke. Weil diese Schichten aber am CDN und am Loadbalancer aufgelöst und sauber neu aufgebaut werden, bekommt der Container nie eine rohe Verbindung aus dem Internet zu sehen, sondern nur geprüften, wohlgeformten Verkehr aus dem eigenen Netz. Ausschließen lässt sich nie etwas, aber die Wahrscheinlichkeit, auf dieser Ebene wirklich etwas auszunutzen, wird damit sehr gering. Was übrig bleibt, ist die Anwendungsebene, und genau dort greifen der saubere Abhängigkeitsbaum und die Firewall davor.

Und weil Masse automatisiert kommt, zählt heute vor allem Tempo. Auf die Scanner aus den ersten Betriebstagen war die Antwort deshalb nicht ein Mensch, der nachts eingreift, sondern eine Regel, die eine auffällige Adresse von selbst für eine Weile aussperrt, zusammen mit regelmäßigen, automatischen Prüfungen, die ohnehin laufen. Angriffsfläche klein halten und schnell, automatisch reagieren: beides ist wieder Weglassen und Vorsorge, nicht Aufrüsten.

Die Oberfläche darf reifen

Bei all der Sorgfalt an Sicherheit und Betrieb lohnt eine Entwarnung an einer anderen Stelle. Die Oberfläche musste zum Start nicht perfekt sein, und sie war es auch nicht. Wo Sicherheit und Datenschutz von Tag eins stehen müssen, weil ein Fehler dort teuer und schwer zu heilen ist, darf das Gefühl einer Oberfläche über die Zeit wachsen.

Genau das ist passiert. Viele der kleinen Verbesserungen an Führung, Beschriftung und Abläufen kamen aus dem direkten Feedback und aus dem anonymen Blick darauf, wo Menschen zögern. Eine Oberfläche, die mit echter Nutzung reift, ist am Ende passgenauer als eine, die man vorab am Reißbrett perfektioniert, und sie entlastet ungemein, weil nicht alles gleichzeitig fertig sein muss.

Ein kleines Beispiel zeigt, wie das zusammenspielt. Dass jede Eingabe serverseitig geprüft wird, war von Anfang an gesetzt, und zwar nicht nur auf den Inhalt, sondern auch auf die Länge eines Feldes. Was zuerst fehlte, war die Rückmeldung an den Menschen davor: Der Server verweigerte eine zu lange Eingabe erst, nachdem jemand sich einen Wolf getippt hatte. Die Reife lag dann nicht in einer neuen Regel, sondern in einem schlichten „321 von 500 Zeichen“ direkt im Feld, abgeleitet aus genau der Grenze, die die Sicherheitsprüfung ohnehin kennt.

Die eigentliche Arbeit war nicht dieser eine Zähler, sondern ihn für jedes Feld konsequent durchzuziehen, damit die Oberfläche überall dasselbe verspricht, was der Server am Ende durchsetzt. So bleibt die Prüfung dort, wo sie hingehört, nämlich auf dem Server, und der Mensch erfährt trotzdem früh, woran er ist. Eine Kleinigkeit im Ergebnis, aber genau die Art von Reife, die echte Nutzung sichtbar macht und die man vorher selten auf dem Zettel hat.

Sicherheit duldet keinen Aufschub, die Oberfläche darf reifen.

Was du mitnehmen kannst

Ein Jahr Produktion lässt sich zu einer Handvoll Entscheidungen verdichten, die für fast jede Web-App taugen, nicht nur für eine kostenlose. Sie sind ein Angebot, keine Vorschrift, und niemand muss sie auf einmal umsetzen.

Sieben haben sich besonders bewährt:

• Das Login hinterfragen: bei jeder Anmeldung klären, welche Frage sie wirklich beantwortet, und darauf verzichten, wo ein zufälliger, geheimer Zugangsschlüssel genügt.
• Daten sparsam halten: nur erheben, was eine Funktion wirklich braucht, und wieder löschen, sobald der Zweck erfüllt ist.
• Anonym messen: die Nutzung so erfassen, dass die Nutzungshürden sichtbar werden, ohne auf die echten Daten zuzugreifen.
• Der kurze Draht zum Nutzer: die direkte Rückmeldung als eine der ersten Funktionen bauen und die internen Abläufe so gestalten, dass eine schnelle Anpassung möglich wird.
• Fremden Code inventarisieren: bei jeder eingesetzten Bibliothek klären, welchen Zweck sie erfüllt, ob sie noch gepflegt wird und ob man ihren vollen Umfang nutzt oder nur einen kleinen Teil davon.
• Angriffsfläche klein halten und lieber automatisch und sofort reagieren als heldenhaft von Hand.
• Die Oberfläche reifen lassen, während die Dinge, die schwer zu heilen sind, von Anfang an sitzen.

Das meiste davon ist kein Mehraufwand, sondern eine andere Reihenfolge und der Mut, Dinge wegzulassen. Genau das macht aus „kostenlos“ kein Sparprogramm, sondern eine bewusste, saubere Bauweise.

Was wir eigentlich gelernt haben

Die überraschendste Einsicht aus diesem Jahr ist, dass fast nichts von dem, was getragen hat, mehr kostet als eine Entscheidung zum richtigen Zeitpunkt. Kein Login einzubauen ist billiger, als eines zu bauen. Keine Daten zu sammeln ist billiger, als sie zu schützen. Den Draht zum Nutzer früh zu legen ist billiger, als später zu raten, warum niemand bleibt. Wer wartet, bis ein Produkt „wichtig genug“ für Sorgfalt ist, baut am Ende die teure Variante. Die sorgfältige Variante ist die günstige, wenn man sie früh wählt.

Dass wir das so klar sehen konnten, lag an einer bewussten Setzung von Anfang an. Wir wollten das Produkt, weil es uns hilft und ein echtes Problem löst, aber nicht um jeden Preis. Das operative Budget für den Betrieb war deshalb schnell und eng definiert, die Entwicklungsleistung dagegen bewusst nicht gedeckelt, allerdings auch nicht als Nebenbei-Bastelei, sondern mit einer klaren Maßgabe: Kundenfeedback schnell bewerten und umsetzen. Dass ein Budget weniger eine Zahl als eine bewusste Entscheidung darüber ist, wie viel Risiko man wo eingeht, vertiefen wir in einem eigenen Artikel. Diese Kombination, enger Betriebsrahmen und entschlossene Entwicklung mit kurzem Draht zum Nutzer, hat jede der Entscheidungen oben überhaupt erst erzwungen.

Die sorgfältige Variante ist die günstige, wenn man sie früh genug wählt.

Und noch etwas hat das Jahr gezeigt: 2026 war kein ruhiges Jahr, um online zu sein. Die Werkzeuge, mit denen man heute baut, sind dieselben, mit denen andere angreifen, und beides ist schneller und billiger geworden. Genau deshalb trägt eine Bauweise, die wenig Fläche bietet und schnell reagiert, weiter als eine, die auf Größe und Nachrüsten setzt. Weniger ist hier nicht die sparsame Wahl, sondern die robuste.

Wir machen das jeden Tag, für eigene Produkte wie Grounds Up und für Kunden, deren Produkt wirklich produktiv tragen muss, von der sauberen Bauweise bis zur Reife in Richtung einer ISO-27001-Zertifizierung.

Wenn du wissen willst, wo deine eigene Web-App bei genau diesen Punkten steht, schauen wir sie uns in einem Health-Check gemeinsam an: Zugänge und Datenhaltung, Abhängigkeiten und Angriffsfläche, Betrieb und Monitoring. Am Ende hast du eine ehrliche Einschätzung und eine überschaubare Liste nächster Schritte, nach Wirkung geordnet.