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 direkt einspielt und keine Nutzer bindet, bei allem anderen sparen.

Genau das war nicht der Plan. Es ist nicht unsere erste Anwendung, wir wissen, was ein Produkt braucht, das Menschen täglich benutzen. Neu war zweierlei: 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.

Die sorgfältige Variante ist die günstige, wenn man früh das Richtige weglässt.

Das klingt nach einem Widerspruch, ist aber die eine Einsicht, die dieses Jahr am deutlichsten bestätigt hat. Fast nichts von dem, was den Betrieb sicher und günstig gehalten hat, war ein zusätzliches Werkzeug oder ein größeres Team. Es war fast immer eine Entscheidung, etwas wegzulassen, und zwar früh, bevor es teuer wird. Die folgenden Stationen zeigen, was das konkret heißt, von der Anmeldung über die Daten bis zu einer Bedrohungslage, die 2026 niemanden mehr verschont.

Das Login, das keines sein musste

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 halbe Runde ist abgelenkt, bevor das Meeting überhaupt 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 wandern. Ein Konto beantwortet, wer du dauerhaft bist. Für ein Meeting zählt aber nur, ob du gerade dorthin gehörst, und das lässt sich ohne dauerhafte Identität beantworten. Wer moderiert, legt einen Raum an und hält dafür einen Schlüssel, der nur im eigenen Browser liegt. Jeder Teilnehmer bekommt beim Beitreten automatisch seinen eigenen, ganz ohne Anmeldung. Über die Raum-Kennung wird der Zutritt angefragt, und der Moderator entscheidet, wer hereinkommt und wer wieder hinausfliegt. Die Kennung teilt er auf dem Weg, den die Runde ohnehin nutzt, per Slack, per 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 eine Ebene darunter, und sie lässt sich an einem Vorgang zeigen, den jeder aus solchen Meetings kennt: dem Abstimmen.

Eine Stimme abgeben, am Beispiel erklärt

In einer Retro sammelt die Runde Themen und stimmt dann ab, welche zuerst drankommen. Jeder hat eine begrenzte Zahl an Stimmen. Im Browser sorgt die Oberfläche dafür, dass niemand mehr Punkte vergibt, als ihm zustehen, die überzähligen lassen sich schlicht nicht mehr anklicken. Das ist normal und richtig, aber es ist nur die Hälfte.

Denn die Oberfläche läuft auf dem Gerät des Teilnehmers, und dort kann man alles verändern. Wer will, umgeht die Begrenzung im Browser mit ein paar Handgriffen. Deshalb prüft der Server beim Speichern noch einmal dasselbe: Gehört die Stimme zu einem echten Teilnehmer dieses Raums, und hat er überhaupt noch welche übrig? Auch das ist vielen klar, der Server ist die verbindliche Instanz, nicht der Browser.

Der Teil, der leicht vergessen wird, kommt jetzt. Die Berechtigung, eine Stimme zu speichern, ist nicht dauerhaft, sie ist an ein Zeitfenster gebunden. Sie gilt nur, solange die Abstimmungsphase läuft. Sobald der Moderator sie schließt, darf niemand mehr speichern, auch nicht der, der bis eben völlig legitim abstimmen durfte. „Darf abstimmen“ fühlt sich wie ein fester Besitz an, ist aber in Wahrheit ein Recht auf Zeit. Wer das übersieht, baut eine Prüfung, die fragt „ist das ein Teilnehmer?“, und vergisst die zweite, die fragt „ist jetzt überhaupt noch Abstimmung?“.

Und noch etwas steckt in diesem kleinen Vorgang. Der Moderator möchte sehen, wie die Abstimmung vorankommt, also bekommt er die Zahl der schon abgegebenen Stimmen. Aber eben nur die Zahl, nicht wer wie abgestimmt hat, denn für den Zweck, die Runde zu moderieren, ist das völlig gleichgültig. Die Berechtigung ist damit nicht nur zeitlich begrenzt, sondern auch im Umfang: Jeder sieht genau so viel, wie seine Rolle braucht, und keinen Deut mehr.

Das ist das Muster hinter fast jeder sicheren Funktion, und es ist größer als das Abstimmen. Die Frage ist selten nur „wer darf?“, sondern „wer darf, wie lange, und wie viel muss die Gegenseite überhaupt sehen?“. Wer so denkt, trifft die meisten Entscheidungen von selbst richtig, lange bevor es um konkrete Technik geht.

Dass Zugriff kein dauerhafter Besitz ist, sondern an Zweck und Zeit hängt, ist ein Gedanke, der weit über ein Meeting-Tool hinausträgt. Warum er mit jedem KI-Werkzeug im Haus wichtiger wird, vertiefen wir in einem eigenen Artikel.

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, so wenig wie möglich festhalten. Das klingt widersprüchlich, denn wie soll man aus der Nutzung lernen, ohne den Nutzern über die Schulter zu schauen?

Ein Meeting-Werkzeug sieht zwangsläufig, was Menschen hineinschreiben, und solange der Raum lebt, liegen diese Inhalte 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 Statistik, die sich bewusst nicht auf eine Person zurückrechnen lässt. Beim Verschwinden eines Raums 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 gezählt, aber die Angabe, die einen einzelnen Besucher verraten würde, seine Adresse im Netz, wird gar nicht erst gespeichert. Gezählt wird nur, dass ein Zugriff stattfand, nicht woher. Was nie in der Statistik landet, kann auch kein späterer Abgleich wieder einer Person zuordnen.

Der überraschende Teil ist, dass gerade dieser Verzicht den klareren Blick ergeben hat. Weil jeder angelegte Raum einen anonymen Punkt 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, ohne dass man 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 leicht gemacht: Es gab 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 gespeichert sind, auch nicht verloren gehen können.

Warum heute selbst die kleine App ein Ziel ist

In den ersten Betriebstagen fiel beim Blick in die Zugriffe etwas auf: Ein großer Teil 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: Warum klopft überhaupt jemand an bei einem Produkt, das für niemanden ein lohnendes Ziel sein dürfte?

Die Angriffslage hat sich grundlegend gedreht. 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 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. Ein dokumentierter Fall aus dem Herbst 2026 zeigt die Größenordnung: Ein einzelner Akteur brach mit frei verfügbaren KI-Agenten in fünf Tagen bei 27 Firmen ein, zu Kosten von im Schnitt rund 25 US-Dollar je Ziel (Dark Reading, 2026). Bei diesem Preis pro Ziel ist jeder, der online ist, 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, von denen jede eine Aufgabe hat. 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.

Was es bedeutet, dass der Loadbalancer die Verbindung neu aufbaut, lässt sich ohne Fachjargon sagen. Eine Anfrage aus dem Internet ist wie ein Paket, das durch viele Hände geht, und in jeder Schicht der Verpackung kann ein Trick stecken, der ein schlecht gebautes System aus dem Tritt bringt. Weil CDN und Loadbalancer das Paket komplett auspacken und sauber neu verschnüren, bekommt der Container nie das rohe Paket von der Straße zu sehen, sondern nur einen geprüften, wohlgeformten Inhalt aus dem eigenen Haus. Ganz ausschließen lässt sich nie etwas, aber die Wahrscheinlichkeit, auf dieser Ebene etwas auszunutzen, wird damit sehr gering. Übrig bleibt die Anwendung selbst, und dort greifen der saubere Abhängigkeitsbaum und die Firewall davor.

Und weil die Masse automatisiert kommt, zählt vor allem Tempo. Auf die Scanner aus den ersten Tagen war die Antwort deshalb kein 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.

Fremder Code ist geliehenes Risiko

Zur Angriffsfläche gehört nicht nur, was von außen erreichbar ist, sondern auch, was man sich an fremdem Code ins Haus holt. Montagmorgen, der Sicherheitsscanner meldet eine Schwachstelle in einem Paket, das tief in den Abhängigkeiten steckt. Der Reflex ist, schnell die neueste Version einzuspielen und weiterzumachen, Haken dran. Wir halten an dieser Stelle kurz inne und stellen zuerst eine andere Frage, 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? 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.

Ein eigenes Beispiel aus dem Betrieb: Zur Überwachung der Lizenzen in unseren Projekten lief lange das Werkzeug license-checker. Es wird 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 veraltete, teils als verwundbar gemeldete Pakete 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.

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

Dass die Anwendung von der ersten Zeile an vollständig mit KI entstanden ist, ändert an all dem nichts. Die KI senkt die Hürde zum Bauen, nicht die zum Betreiben: Getrennte Umgebungen, eine prüfende Pipeline und eine saubere Abhängigkeitshygiene bleiben Entscheidungen, die man selbst trifft und verantwortet. Wie das schnelle Starten mit KI gelingt, zeigen wir in Klein starten im KI-Zeitalter, und wie sich die Auslieferung verändert, wenn die KI mitarbeitet, in Continuous Integration im Zeitalter der KI.

Was von Tag eins stehen muss, und was reifen darf

Bei all der Sorgfalt lohnt eine Entwarnung. Nicht alles muss zum Start perfekt sein, und die Kunst liegt darin, das eine vom anderen zu trennen. Sicherheit und Datenschutz müssen von Tag eins sitzen, weil ein Fehler dort teuer und schwer zu heilen ist. Das Gefühl einer Oberfläche dagegen darf über die Zeit wachsen, und genau das ist passiert.

Den kürzesten Weg dahin öffnet ein direkter Rückkanal im Produkt selbst. Von Anfang an gibt es 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 eine der wichtigsten Funktionen überhaupt, und sie sollte zu den ersten gehören, die man baut, nicht zu den letzten. In der Praxis kam eine Rückmeldung oft morgens herein und war wenige Tage später als Verbesserung wieder draußen, die dann allen half und nicht nur dem einen, der sich gemeldet hatte.

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

Ein kleines Beispiel zeigt, wie beides 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.

Was du mitnehmen kannst

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.

Dass wir das so klar sehen konnten, lag an einer Entscheidung, die wir ganz am Anfang getroffen und dann durchgehalten haben. 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 mit einer klaren Maßgabe: Kundenfeedback schnell bewerten und umsetzen. Dass ein Budget weniger eine Zahl als eine Entscheidung darüber ist, wie viel Risiko man wo eingeht, vertiefen wir in einem eigenen Artikel.

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 groß baut und erst hinterher absichert. 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 ihr Geschäft trägt, 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 klare Einschätzung und eine überschaubare Liste nächster Schritte, nach Wirkung geordnet.