Das operative Geschäft wird in einer Oberfläche sichtbar.
Schematische, anonymisierte Ansicht. Die dargestellten Werte sind illustrativ; Funktionsumfang und Zusammenspiel entsprechen dem realen System.
Ausgangslage, Aufgabe, Umsetzung.
- Buchhaltung in Tabellen
- Zeiterfassung in Einzeldateien
- Belege im Mailordner
- Projektstände verteilt über Cloud-Dienste
- Kein gemeinsamer Stand, keine belastbare Auswertung
- Ein System auf eigenem Server
- Beleg bis Umsatzsteuervoranmeldung durchgängig
- Rechnungen als PDF auf echtem Briefbogen
- Tagesbriefings automatisch erzeugt
- Kontext bleibt über Monate erhalten
| Rolle | Auftraggeber, Architekt und Betreiber in einer Person — kein Dienstleister beteiligt |
| Laufzeit | Mai 2026 bis heute, durchgehend im Einsatz |
| Umfang | 6 fachliche Bereiche, 355 Seiten · Stand Juli 2026: rund 2.100 Commits |
| Besonderheit | Persistentes Gedächtnis über mehr als 1.900 Notizen (Stand Juli 2026) — der eigentliche Kern des Systems |
Sechs Bereiche, ein System.
Gewachsen entlang echter Anforderungen — jeder Bereich entstand, weil eine konkrete Aufgabe ihn gebraucht hat, nicht aus einem Featureplan.
- Buchhaltung & Belege Kreditoren, Belegerfassung per Texterkennung aus einem Scan-Ordner, Kontoabgleich über automatisierten Bankabruf, Umsatzsteuervoranmeldung je Quartal.
- Stundenerfassung & Rechnungen Zeiterfassung je Mandat, Auswertung nach Kunde und Zeitraum, Rechnungserstellung als PDF auf echtem Geschäftsbriefbogen.
- Mandats- & Kontaktsteuerung Laufende Mandate, Angebote mit mehrseitigen PDF-Ausgaben, Kontakte, Ausschreibungs-Monitoring über externe Portale.
- Tägliche Lagebriefings Automatisch erzeugte Briefings zu Technologie, Marktlage und offenen Punkten — server-seitig zeitgesteuert, mit Qualitätsprüfung vor Veröffentlichung.
- Wissens- & Analyseseiten Aufbereitete Fachthemen, Auswertungen und Dokumentationen als dauerhaft verfügbare Seiten statt als verstreute Einzeldateien.
- Betrieb & Systemgesundheit Statusübersichten zu Servern, Diensten, Backups und Datenaktualität — inklusive Warnung bei veralteten Datenständen.
Warum ein Gedächtnis den Unterschied macht.
- Das Problem: Jede neue Sitzung mit einer AI beginnt bei null — Vorgeschichte, Entscheidungen und Begründungen sind weg. Bei einer Einzelfrage egal, bei einem System über Monate der entscheidende Engpass.
- Die Lösung: Drei Ebenen mit unterschiedlicher Aufgabe — schneller Index zum Einstieg, semantische Suche bei unscharfer Frage, vollständige Ablage als Wahrheit.
- Der Effekt: „Warum haben wir das damals so entschieden?" ist in Sekunden beantwortet — mit der Originalbegründung, nicht mit einer Rekonstruktion.
„Derselbe Mechanismus, den ein Projekt braucht, wenn nach zwölf Monaten jemand fragt, warum eine Architekturentscheidung so getroffen wurde."
Technischer Deep-Dive.
Architektur, Stack und Betriebsmodell im Detail. Für alle, die wissen wollen, wie es tatsächlich gebaut ist.
Architektur & Stack aufklappen
| Ebene | Umsetzung |
|---|---|
| Hosting | Eigener Cloud-Server in Deutschland, vollständige Betriebsverantwortung inklusive Härtung und Sicherheitsupdates |
| Laufzeit | Docker-Container hinter einem Reverse-Proxy mit automatischer Zertifikatsverwaltung |
| Anwendung | Python/Flask mit modularen Blueprints je Fachbereich |
| Daten | DuckDB für analytische Auswertungen, SQLite für Authentifizierung und Stammdaten; getrennte Datenbanken je Domäne |
| Frontend | Statisches HTML mit gemeinsamem Design-System, keine Framework-Abhängigkeit, keine externen Schrift- oder Skript-Ressourcen |
| Zugang | JWT-basierte Authentifizierung mit Zwei-Faktor-Schutz und rollenbasierten Seitenrechten |
| Automatisierung | Zeitgesteuerte Jobs für Datenabruf, Briefing-Erzeugung, Bankabgleich und Datenqualitätsprüfung |
Deploy-Kette & Qualitätssicherung aufklappen
Weg vom Rechner auf den Server
Ausschließlich über Git: Push auf den Hauptzweig, Pipeline zieht den Server auf den exakten Repository-Stand. Manuelles Kopieren ist bewusst ausgeschlossen — es war die häufigste Ursache für auseinanderlaufende Stände.
Vier Gates vor dem Deploy
- Secret-Scan — ein Pre-Commit-Hook blockiert Commits, die Zugangsdaten, API-Schlüssel oder Tokens im Klartext enthalten
- Syntaxprüfung — Python-Dateien werden vor dem Neustart kompiliert; ein Fehler verhindert den Deploy statt den Dienst zu stoppen
- Testlauf — ein Pre-Push-Hook führt die Testsuite aus; rote Tests blockieren den Push
- Substanzprüfung der Briefings — automatisch erzeugte Inhalte werden auf Mindestumfang und Struktur geprüft, bevor sie veröffentlicht werden
Warum das vierte Gate existiert
Die ursprüngliche Prüfung testete nur Frische und Form — nicht, ob überhaupt Inhalt da war. Ein fehlgeschlagener Generator lieferte eine formal korrekte, praktisch leere Seite: Ampel grün. Ein Gate, das die falsche Dimension misst, ist gefährlicher als gar keins.
Das Gedächtnissystem im Detail aufklappen
Warum drei Ebenen statt einer
| Ebene | Umfang | Stärke | Grenze |
|---|---|---|---|
| Schnellindex | 1.646 Einträge | billig, sofort beim Start | findet nur bewusst Angelegtes |
| Semantische Suche | 28.255 Abschnitte | findet auch Unerwartetes | langsamer, Treffer prüfbedürftig |
| Wissensablage | über 1.900 Notizen | die Wahrheit, mit Begründung | zu groß zum Volleinlesen |
Befund aus dem Betrieb
Bei der semantischen Suche liefert die umgangssprachliche Originalfrage bessere Treffer als eine in Fachbegriffe übersetzte Suchanfrage. Der Reflex, die Frage vorher zu „optimieren", verschlechtert das Ergebnis messbar.
114 wiederverwendbare Arbeitsanweisungen
Versionierte Anweisungen für Deploys, Sicherheitsprüfungen, Dokumenterstellung und Datenqualität. Tritt ein Fehler auf, wird die zuständige Anweisung nachgeschärft. Deshalb entsteht das vierte System schneller als das erste.
Fehlerkultur: was schiefging und was daraus wurde aufklappen
Zu jedem behobenen Fehler wird ein Eintrag mit Ursache und Gegenmaßnahme geschrieben. Wiederkehrende Muster führen nicht zu einer weiteren Ermahnung, sondern zu einer technischen Sperre. Drei Beispiele aus dem laufenden Betrieb:
- Vorgetäuschte Aktualität — Seiten zeigten das Änderungsdatum der Datei statt des Datenstands. Eine Seite meldete „aktuell", obwohl die zugrundeliegenden Daten Tage alt waren. Gegenmaßnahme: Der Stand kommt jetzt aus der Datenquelle, nicht aus dem Dateisystem.
- Anzeige- und Entscheidungsgrundlage liefen auseinander — eine Kennzahl wurde auf der Oberfläche anders berechnet als in der Regel, die eine Warnung auslöste. Ergebnis: grüne Ampel bei rotem Sachverhalt. Gegenmaßnahme: Beide müssen dieselbe Quelle und denselben Nenner verwenden.
- Stille Fehlschläge — ein Datenbankfeld wurde ohne Fehlermeldung nicht gespeichert, das System meldete Erfolg. Gegenmaßnahme: Pflichtprüfung des tatsächlichen Endzustands nach jedem Schreibvorgang, nicht nur des Rückgabewerts.
Diese Systematik ist direkt auf Mandate übertragbar: Ein Fehler, der nur besprochen wird, wiederholt sich. Ein Fehler, der in eine Prüfung übersetzt wird, nicht.