Arbeitsweise

Wie wir arbeiten

Wie gearbeitet wird, entscheidet mehr über das Ergebnis als die Wahl des Frameworks. Deshalb steht hier ausführlich, wie wir es tun und woran man es nachprüfen kann. Der Kern: Eine Regel gilt bei uns erst als durchgesetzt, wenn ein Test rot wird, sobald jemand sie bricht.

Phase 01

Analyse

Wir verstehen Ziel, Nutzer und Rahmenbedingungen, bevor wir bauen.

Am Anfang steht nicht die Frage, was gebaut werden soll, sondern welches Problem verschwinden muss. Teure Fehlentwicklungen entstehen meist, weil eine Lösung beschrieben wurde, bevor das Problem verstanden war. Wir fragen deshalb hartnäckig nach dem Ablauf dahinter — wer macht heute was, womit, und woran scheitert es.

Genauso wichtig sind die Rahmenbedingungen, die niemand freiwillig erwähnt: Budgetgrenzen, ein kleines Team, eine Frist, ein Altsystem, das bleiben muss. In einem unserer Projekte hat genau diese Liste die gesamte Architektur geprägt — kein Budget für Fremddienste hieß, dass Karten, Adresssuche und Fehlertracking selbst betrieben werden mussten; ein kleines Team hieß, dass Regeln maschinell erzwingbar sein mussten, weil nicht immer ein zweites Augenpaar mitliest.

Und wir halten fest, was ausdrücklich nicht gebaut wird: In einem Projekt gibt es dafür ein eigenes Dokument mit Begründung je Punkt, in einem anderen eine Dauer-Ausschlussliste. Das verhindert die teuerste Sorte von Nachforderungen — die, bei der sich hinterher niemand erinnert, wer sie eigentlich beschlossen hat.

Was am Ende vorliegt

Ein gemeinsames Verständnis von Problem, Rahmenbedingungen und Nicht-Zielen — schriftlich, mit Datum und Begründung.

Phase 02

Architektur

Wir entwerfen eine tragfähige, skalierbare Grundlage.

Architektur ist die Menge der Entscheidungen, die später teuer zu ändern sind. Genau deshalb treffen wir sie bewusst und schreiben sie auf. In der RetterApp liegen 70 solcher Architekturentscheidungen dokumentiert vor (Stand 16.08.2026) — jede mit Kontext, Alternativen und Begründung. Der Nutzen zeigt sich ein Jahr später, wenn jemand fragt „warum eigentlich so?“, und die Antwort nicht „das war historisch so“ lautet.

Wir entwerfen dabei die Schnittstellen zuerst und die Oberfläche darauf. Das macht die Schnittstelle zu der einen Stelle, an der Sicherheit und Datenschutz durchgesetzt werden. Sicherheitsgrenzen und Datenmodell gehören in diese Phase, nicht in die Umsetzung: Ein nachträglich eingezogenes Berechtigungsmodell hinterlässt fast immer Lücken.

Und wir überbauen nicht. Wenn eine verteilte Lösung heute nicht gebraucht wird, wird sie nicht gebaut — aber die bekannte Grenze wird dokumentiert, damit später jemand weiß, wo anzusetzen ist.

Was am Ende vorliegt

Ein Architekturbild mit begründeten Entscheidungen, ein Datenmodell und klar gezogene Sicherheitsgrenzen — dokumentiert statt im Kopf.

Phase 03

Entwicklung

Wir setzen iterativ um — transparent und testgetrieben.

Hier arbeiten wir KI-unterstützt, und wir sagen das offen. Die KI schreibt den Code, den wir ihr vorgeben; Architektur, Entscheidungen und Verantwortung bleiben bei uns.

Das funktioniert nur mit einem objektiven Netz darunter, und das sind Tests. Wir vertrauen keinem Code, nur weil er plausibel aussieht — egal von wem er stammt. In der RetterApp laufen rund 7.280 automatisierte Tests über drei Codebasen (Stand 16.08.2026), und die Backend-Tests laufen gegen eine echte Datenbank statt gegen Attrappen. Attrappen prüfen, ob der Code tut, was man erwartet; eine echte Datenbank prüft, ob es auch stimmt.

Die kritischen Regeln überlassen wir nicht der Aufmerksamkeit. Über zwei Dutzend Wächter-Tests laufen über die real registrierten Schnittstellen und färben rot, sobald jemand eine Regel bricht. Was einen Wächter von einem Ritual unterscheidet, steht weiter unten bei den Prinzipien.

Was am Ende vorliegt

Lauffähige Zwischenstände in kurzen Abständen, mit Testabdeckung und maschinell erzwungenen Regeln statt mündlicher Absprachen.

Phase 04

Skalierung

Wir bringen die Lösung sicher in Produktion und unter Last.

Vor dem Produktivgang steht die unbequeme Prüfung. Für unseren Mailserver haben wir ein adversariales Sicherheitsreview durchgeführt, bevor gebaut wurde, mit einer Fixliste, die abgearbeitet und nachweislich in den Dateien adressiert wurde: erst prüfen, was schiefgehen kann, dann bauen.

Bei Reviews arbeiten wir gegen die eigene Bestätigungsneigung — jeder schwere Befund bekommt einen Gegenprüfer. Das Ergebnis des Pre-Launch-Vollaudits der RetterApp ab 27.07.2026: Von 24 gegengelesenen Befunden wurden 6 bestätigt, 16 abgeschwächt und 2 widerlegt — zwei weitere zog der Autor selbst zurück, einen davon mit der Begründung, die eigene Prüfmethode sei fehlerhaft gewesen.

Leistung behandeln wir als messbare Größe. Eine strukturierte Adresssuche in unserer Geoplattform brauchte ursprünglich rund 1,4 Sekunden; nach gezielter Umstellung auf eine indexgestützte Suche liegt sie bei etwa 6 Millisekunden (Stand 06/2026). Solche Zahlen entstehen durch messen, gezielt ändern, wieder messen.

Und die Auslieferung selbst wird abgesichert. Vor jedem Store-Bau stehen Wächter, die aus realen Vorfällen entstanden sind: einer prüft, dass alle Pflichtangaben gesetzt sind — weil einmal nur die Server-Adresse gesetzt war und die Kartenadresse still auf die Entwicklungsumgebung zurückfiel — ein Store-Paket mit funktionierender Schnittstelle und toter Karte.

Was am Ende vorliegt

Ein geprüfter, reproduzierbarer Produktivgang — mit Messwerten statt Zusagen und einer Liste dessen, was noch offen ist.

Phase 05

Betrieb

Wir betreiben, überwachen und entwickeln kontinuierlich weiter.

Software endet nicht mit dem Produktivgang, sie beginnt dort. Wir betreiben gehärtet: Container mit schreibgeschütztem Dateisystem und ohne unnötige Berechtigungen, Datenbanken nie öffentlich erreichbar, Zugang nur per Schlüssel. Der Härtungsindex unseres Produktivservers liegt bei 82 von 100 Punkten im automatisierten Lynis-Scan (Stand 24.06.2026).

Bei der Überwachung setzen wir auf zwei gegenläufige Wege. Ein Wächter auf dem Host — bewusst nicht im Container — prüft regelmäßig Plattenplatz, Container-Zustand, Rückstau je Warteschlange und das Alter der letzten Sicherung. Und bei Ruhe sendet er ein Lebenszeichen. Dieses Detail ist der eigentliche Trick: Bleibt das Lebenszeichen aus, fällt auch der Ausfall des Servers selbst auf. Ein System, das nur bei Fehlern meldet, schweigt auch dann, wenn es tot ist.

Und wir schreiben Fehlschläge als Regeln fest, meist an drei Orten gleichzeitig: im Kommentar des Wächter-Tests, im Arbeitsprotokoll und in der Regeldatei. Eine Auswahl belegter Lehren: „Gebaut und getestet ist nicht in Produktion aktiv“ — der SMS-Versand stand monatelang auf Attrappe, weil die Anleitung diesen Wert als Produktiveinstellung führte. Und, nachdem dieselbe Zeile über vier Anleitungen wieder zurückkam: „Anleitungen sind gefährlicher als Code“ — seither prüft ein Wächter jeden Codeblock in der gesamten Dokumentation.

Was am Ende vorliegt

Ein überwachter, gesicherter Betrieb — mit dokumentierten Lehren statt wiederholter Fehler.

Die Prinzipien dahinter

Acht Regeln, die wir uns selbst auferlegt haben.

Die meisten davon sind die Antwort auf einen realen Vorfall, die übrigen bewusste Festlegungen.

Eine Regel gilt erst, wenn ein Test sie erzwingt

In einem kleinen Team ist jede Regel, die nur in einem Dokument steht, eine Regel auf Bewährung. Deshalb werden die kritischen Invarianten maschinell durchgesetzt — über die real registrierten Schnittstellen, nicht über Stichproben.

Kein leerlaufender Erfolg

Jede Prüfung, die Dateien durchsucht, prüft zuerst, dass sie überhaupt etwas gefunden hat. Null Treffer heißt kaputte Prüfung, nicht saubere Codebasis.

Jeder Wächter wird mutiert

Ein Test, der immer grün ist, prüft nichts. Deshalb wird jede Regel testweise gebrochen — erst wenn genau der erwartete Test dabei rot wird, gilt er als wirksam.

Befunde bekommen einen Gegenprüfer

Jeder schwere Review-Befund wird von einem zweiten Prüfer mit dem Auftrag gelesen, ihn zu widerlegen. Das kostet Zeit und verhindert, dass plausibel klingende, aber falsche Befunde Arbeit auslösen.

Nicht-Ziele werden aufgeschrieben

Was ein System bewusst nicht tut, gehört dokumentiert — mit Datum und Begründung, und mit dem Vermerk, dass es eine Auftraggeber- und keine Entwicklerentscheidung war.

Was nicht automatisch prüfbar ist, kommt auf eine Liste

Zustellung echter Mitteilungen auf echten Geräten, Abläufe mit zwei Konten, visuelle Abnahme — das erreicht kein automatischer Lauf. Diese Punkte stehen versioniert auf einer Liste, statt sich in einer grünen Testsuite zu verstecken.

Das Skript ist die zweite Instanz

In einem kleinen Team gibt es keine Vier-Augen-Freigabe. Wir ersetzen sie technisch: Kritische Aktionen laufen ausschließlich über dokumentierte Runbook-Skripte, nie über ad-hoc-Befehle. Das Skript prüft die Vorbedingungen, erzwingt Wartezeiten und schreibt den Protokolleintrag. In der Bauvorgabe unserer eigenen Plattform (in Entwicklung) ist festgelegt: Eine Organisations-Löschung soll über Soft-Delete, sieben Tage Karenz und eine zweite bewusste Bestätigung nach Ablauf gehen — mit Alarm über einen externen Kanal schon beim Einleiten.

Ein Betrieb hat einen Takt, keine Anlässe

Wartung passiert nach Rhythmus statt nach Zuruf. Heute laufen Sicherung und Prüfung täglich automatisch. Für unsere eigene Plattform ist der weitere Takt im Bauplan festgelegt: wöchentlich ein fixes Fenster für Alarm-Durchsicht und Patch-Sichtung, monatlich ein Patch-Fenster mit protokolliertem Wiederherstellungstest, quartalsweise Ersatzhardware-Test und Schlüsselinventur. Was keinen Termin hat, passiert irgendwann nicht mehr.

Grenzen

Wo unsere Grenzen liegen.

Diese Punkte gehören zur Arbeitsweise dazu:

Maschinell erzwungene Regeln und die Runbook-Pflicht halten unsere Arbeit verlässlich. Eine Grenze gibt es trotzdem: Für Vorhaben, die mehrere parallele Entwicklungsstränge über Monate brauchen, sind wir nicht die richtige Adresse, und wir sagen das lieber vorher.
In einem Projekt ist die Absicherung gegen versehentliches Zusammenführen nur durch Disziplin und lokale Prüf-Hooks gewährleistet, weil der genutzte Tarif keine erzwungenen Regeln für private Repositories bietet. Zweimal hat das real nicht gehalten — beide Fälle sind dokumentiert.
Der Wiederherstellungstest der nächtlichen Sicherung steht in einem Bestandsprojekt noch aus. Die Sicherung läuft verschlüsselt, der belegte Rückspiel-Nachweis fehlt. In der Bauvorgabe für unsere eigene Plattform ist genau dieser Nachweis inzwischen ein Abnahmekriterium vor dem Produktivgang; die Lehre daraus wandert also nach vorne.

Wie das fertig aussieht.

Die vier Systeme auf der Referenzseite zeigen es — mit Zahlen und benanntem Stand.

Referenzen ansehen Alle Leistungen Kontakt