Sliph: Wie aus einer Excel-Liste eine Schul-App wurde – mit KI, aber nicht von KI

Wie alles anfing

Sliph ist eine Schließfachverwaltung für Schulen und ist an der Schule meiner älteren Tochter in Berlin entstanden.

Dort kümmert sich der Förderverein um die Vermietung der Schließfächer, und zwar ehrenamtlich durch Eltern. Über die Jahre war daraus ein ziemliches Chaos geworden, mit Papierformularen, mehreren Excel-Listen mit unterschiedlichen Datenständen und Überweisungen, die jemand von Hand abgleichen musste. Das hat viel Zeit gekostet und war entsprechend fehleranfällig.

Irgendwann waren die Eltern, die das gemacht haben, nicht mehr bereit, diese Zeit zu investieren, und im Förderverein wurde diskutiert, die Schließfächer ganz abzuschaffen. Das wäre allerdings schwierig geworden, denn die Einnahmen aus der Vermietung sind ein wichtiges Budget, mit dem der Förderverein vieles an der Schule finanziert.

Meine Idee war deshalb, den gesamten Ablauf in eine Anwendung zu bringen, von der Anmeldung bis zum Wechsel ins neue Schuljahr, damit der Aufwand für die Ehrenamtlichen deutlich kleiner wird.

Die Konzeption

Auf den ersten Blick ist eine Schließfachvermietung nicht viel mehr als ein Formular und eine Liste. Wenn man genauer hinschaut, steckt aber einiges an Fachlichkeit dahinter:

• Die Anmeldung läuft online, mit Mieter:in, Schüler:in, Klasse und gewünschter Fachgröße. Bezahlt wird per SEPA-Lastschrift, die Preise kommen aus dem Tarif des jeweiligen Schuljahres.
• Die Fächer werden über einen Belegungsplan nach Gebäude, Etage und Schrank vergeben. Dazu kommen Reservierungen mit Ablaufdatum, die Schlüsselausgabe und Umzüge in ein anderes Fach.
• Im Eltern-Portal meldet man sich ohne Passwort über einen Einmal-Link an. Dort sieht man alle Verträge, auch für mehrere Kinder, und kann zum Beispiel die Bankverbindung ändern.
• Gekündigt wird zum Schuljahresende. Die Kaution wird zurücküberwiesen oder auf Wunsch an den Förderverein gespendet.
• Beim Schuljahreswechsel gibt es eine Vorschau auf Verlängerungen, neue Klassen und Abgänge, bevor alle Verträge übernommen werden.
• Weil Bankdaten und Daten von Minderjährigen verarbeitet werden, braucht es außerdem ein Audit-Log, ein Rollen- und Rechtekonzept, ein Löschkonzept und Auskunft nach DSGVO.

Am Anfang ging es deshalb vor allem darum, die Abläufe zu verstehen. Was passiert wann, wer entscheidet was und was darf auf keinen Fall schiefgehen? Ein Fach darf zum Beispiel nie doppelt vergeben werden, und eine IBAN darf nirgends im Klartext auftauchen. Neben den Spezifikationen sind dabei auch Klick-Dummies für die Oberflächen entstanden.

Mein Setup mit Claude und Spec-driven Development

Entwickelt habe ich Sliph mit Claude Code. Wichtiger als das Werkzeug selbst war für mich aber der Prozess drumherum, denn jede Änderung beginnt bei mir mit einer Spezifikation und nicht mit einem spontanen Prompt.

Der Ablauf ist dabei für jedes Feature gleich:

1. In der Spezifikation steht, was das Feature leisten soll, welche Regeln gelten und welche Fälle nicht eintreten dürfen.
2. Daraus entsteht ein Ticket mit Aufgaben, Abhängigkeiten, Teststrategie und einer Definition of Done.
3. Claude setzt das Ticket um. Projektregeln geben Architektur, Konventionen und Sicherheitsanforderungen vor, damit die Ergebnisse auch über viele Sitzungen hinweg zueinander passen.
4. Tests gehören zu jedem Ticket dazu, also Unit-, Integrations- und End-to-End-Tests, und werden nicht auf später verschoben.
5. Am Ende prüfe ich, ob das Ergebnis zur Spezifikation passt, und erst danach wird committet.

1. 1SpezifikationRegeln und was nie passieren darf
2. 2TicketAufgaben, Teststrategie, Definition of Done
3. 3UmsetzungClaude Code nach den Projektregeln
4. 4TestsUnit, Integration, End-to-End
5. 5AbnahmeIch prüfe gegen die Spezifikation, erst dann der Commit

Mit der Zeit lief immer mehr davon selbstständig. Seit Ende August committet meistens Claude Code, auch wenn ich gar nicht am Rechner sitze. Architektur, Sicherheit, fachliche Entscheidungen und die Abnahme liegen trotzdem bei mir. Claude ist ein sehr schneller Entwickler, aber die Verantwortung für das Produkt übernimmt es nicht, und wo die Spezifikation unscharf ist, wird es das Ergebnis meistens auch.

Aufwand und Kosten

Sliph ist zwischen dem ersten Commit am 4. Juli 2026 und Ende Oktober 2026 entstanden, also in knapp vier Monaten. Die Version 1.0.0 ging nach 31 Arbeitstagen am 15. August an der Schule live, seitdem ist die Anwendung im Betrieb und wird weiter ausgebaut.

Allein und ohne KI hätte ich nach meiner Schätzung mindestens sechs Monate in Vollzeit gebraucht. Als Hobbyprojekt wäre Sliph vermutlich erst in Jahren fertig geworden, oder es wäre unfertig, fehlerhaft und mit deutlich weniger Funktionen live gegangen, zum Frust aller Beteiligten und Nutzer.

Gezählt habe ich dabei Commit-Sitzungen. Weil seit Ende August meistens Claude Code selbstständig committet, ist das nicht dasselbe wie meine eigene Zeit. Die lässt sich ab dem 24. August aus den Zeitpunkten meiner Prompts ermitteln und liegt seitdem bei mindestens 159 Stunden.

Bei den Kosten nutze ich eine Claude-Max-Lizenz, anfangs die x5-Variante für 100 €, später die x20-Variante für 200 € im Monat. Über die knapp vier Monate sind das zusammen ungefähr 600 €. Hätte ich die gleiche Nutzung über API-Token bezahlt, wären es nach meiner Hochrechnung rund 10.000 US-Dollar gewesen.

Die Zahlen beziehen sich auf den Stand Ende Oktober 2026. Nicht eingerechnet sind rund 19.000 Zeilen Spezifikationen und Dokumentation in Markdown und rund 17.000 Zeilen Klick-Dummies in HTML.

Was auffällt, ist das Verhältnis zwischen Produktiv- und Testcode. Ohne die Doku-Zeilen kommen auf eine Zeile Produktivcode etwa 1,25 Zeilen Testcode, und das war eine bewusste Entscheidung, weil ich KI-generiertem Code ohne dieses Sicherheitsnetz nicht vertrauen würde. Außerdem ist knapp ein Drittel des Produktivcodes Dokumentation.

Schneller bin ich dabei an allen Stellen, auch die Spezifikationen und die Dokumentation erstelle ich zusammen mit Claude. Der größte Unterschied liegt aber beim Schreiben des Codes und vor allem beim Finden und Beheben von Bugs, das geht um ein Vielfaches schneller als früher.

Herausforderungen

Sensible Daten. Sliph verarbeitet Bankverbindungen und Daten von Schüler:innen. Die IBAN wird verschlüsselt gespeichert und überall nur maskiert angezeigt, jede relevante Aktion landet im Audit-Log, die Rechte sind fein verteilt und es gibt ein Löschkonzept. In dieser Tiefe schlägt eine KI das nicht von sich aus vor. Es musste in der Spezifikation stehen und wird über Tests geprüft. Zusätzlich prüft ein eigener DSGVO-Agent vor jedem Deployment auf Staging den Code. Kleinere Probleme korrigiert er direkt, und bei schweren DSGVO-Verstößen stoppt er das Deployment.

Die Lizenz. Sliph soll für Schulen und Fördervereine kostenlos sein, wer aber ein bezahltes Hosting für Dritte anbietet, soll eine Lizenz brauchen. Mit einer Open-Source-Lizenz wie der AGPL lässt sich das nicht abbilden, deshalb bin ich auf die Business Source License 1.1 gewechselt. Das hatte direkt technische Folgen, weil der eingesetzte Rich-Text-Editor unter GPL stand und nicht mehr dazu gepasst hat. Er musste ersetzt werden. Ich würde mir die Lizenzen der Abhängigkeiten heute deutlich früher ansehen und nicht erst kurz vor dem Release.

Die Größe der Codebasis. Wenn Code billig zu schreiben ist, entsteht auch viel davon. Eine einzelne Datei für die Verwaltungsansichten ist zwischendurch auf über 5.700 Zeilen gewachsen. Auf die Laufzeit hat das keinen Einfluss, auf die Wartbarkeit aber schon, und auch darauf, wie gut KI-Agenten mit dem Code arbeiten können. Regelmäßige Architektur-Reviews und das Aufteilen solcher Dateien gehören deshalb fest zum Prozess.

Performance. Bei einer Analyse habe ich klassische N+1-Abfragen gefunden. Auf einer Übersichtsseite stieg die Zahl der Datenbankabfragen mit wachsender Datenmenge auf über 370. Die Tests waren trotzdem grün, weil das Ergebnis ja gestimmt hat. Solche Probleme findet man nur, wenn man gezielt danach sucht.

Die Veröffentlichung. Interne Spezifikationen, Arbeitsdokumente und die öffentliche Dokumentation sauber voneinander zu trennen, war mehr Arbeit als gedacht. Verweise zwischen Dateien, Lizenzhinweise in Hunderten von Dateien und ein reproduzierbarer Export haben jeweils eigene Tickets gebraucht.

Was ich gelernt habe

• Die Qualität der Spezifikation entscheidet über die Qualität des Ergebnisses. Präzise Anforderungen werden schnell zu gutem Code, unscharfe genauso schnell zu unscharfem Code.
• Tests sind Pflicht. Sie sind der einzige belastbare Nachweis, dass generierter Code das tut, was er soll, auch nach der zwanzigsten Änderung. Welche Tests nötig sind und wie sie aussehen sollen, muss man allerdings selbst spezifizieren, denn von sich aus lässt Claude große Testlücken offen.
• Sicherheit und Datenschutz muss man ausdrücklich fordern. Was nicht in der Spezifikation steht, wird auch nicht in der nötigen Tiefe umgesetzt.
• Die Architektur braucht regelmäßige Pflege. Die KI optimiert für das aktuelle Ticket, den Blick auf das Ganze muss man selbst behalten.
• Die eigene Rolle verschiebt sich. Ich schreibe weniger Code und entscheide, prüfe und nehme dafür mehr ab. Erfahrung in Architektur und Sicherheit wird dadurch eher wichtiger.

Was mich am meisten überrascht hat, ist die Qualität des Codes. Im Laufe des Jahres 2026 bin ich immer seltener auf Stellen gestoßen, bei denen ich gesagt hätte, das würde ich so nicht machen, oder auch, das ist Unsinn.

Ausblick

Sliph wird als Source-Available-Software veröffentlicht. Schulen, ihre Fördervereine und Schulträger können die Anwendung kostenlos betreiben, jeweils mit einer eigenen Instanz pro Schule im eigenen Design. Wer Sliph als bezahlten Dienst für Dritte anbieten möchte, braucht eine Lizenz, und nach vier Jahren wird jede Version automatisch unter einer Open-Source-Lizenz frei.

Für mich persönlich war das Projekt aber vor allem ein Test für die Arbeitsweise. Spec-driven Development mit KI ersetzt keine Erfahrung, es verstärkt sie. Mit klaren Spezifikationen, konsequenten Tests und jemandem, der die Verantwortung behält, ist in knapp vier Monaten eine Anwendung entstanden, für die ich allein sonst mindestens ein halbes Jahr in Vollzeit gebraucht hätte.

Mehr zu Sliph gibt es auf sliph.app. Wer die Anwendung selbst ausprobieren möchte, findet eine Demo unter demo.sliph.app, und der Quellcode erscheint auf GitHub unter github.com/solick/sliph.

← Alle Beiträge