Wogegen sich das vergleicht
| Excel und Ordner | Fertige Projektsoftware | Anwendung nach diesem Aufbau | |
|---|---|---|---|
| Einrichtung | sofort, aber jeder macht es anders | Wochen, Module einzeln | auf euren Ablauf gebaut |
| Was ein Sprachmodell davon sieht | nichts, außer jemand kopiert es hinein | Rohdaten über eine Schnittstelle, teuer je Frage | fertigen Projektstand, direkt lesbar |
| Ihr zahlt | nichts extra | Lizenz pro Nutzer, Module einzeln | Entwicklung einmal, Betrieb nach Verbrauch |
| Ein Mitarbeiter mehr | kostet nichts | kostet extra | kostet nichts |
| Daten liegen | in euren Ordnern | beim Anbieter | in eurem Konto |
| Wenn ihr wechselt | Dateien bleiben | Zugang endet | läuft weiter, ohne uns |
Was der Demonstrator zeigt
- Eine vollständige Anwendung im Browser: Kunden, Projekte, Aufgaben, Stunden, Ansprechpartner, Gesprächsnotizen, Ideensammlung, Glossar. Anmeldung über ein Google-Konto.
- Jedes Projekt bekommt beim Anlegen seinen Ordner in der Ablage, mit fester Struktur.
- Bei jeder Änderung entsteht der Projektstand als Textdatei im selben Ordner, dazu eine Gesamtübersicht über alle Projekte.
- Claude beantwortet Fragen ausschließlich aus diesen Dateien, auch die Frage, warum eine Aufgabe hängt. Die Antwort steht in einer Gesprächsnotiz, nicht in einem Bericht.
Was ihr anschließen könnt
Die Anwendung selbst hängt an wenigen Stellen, und jede davon ist austauschbar. Interessanter ist die zweite Seite: Das Sprachmodell steht daneben, nicht darin. Was dort angeschlossen ist, kann mit dem Projektstand arbeiten.
An der Anwendung
| Bereich | Beispiele |
|---|---|
| Ablage | Google Drive, SharePoint, OneDrive, Nextcloud, S3 |
| Datenbank | Postgres, als verwalteter Dienst oder im eigenen Haus |
| Anmeldung | Google Workspace, Microsoft 365 |
Am Sprachmodell daneben
| Bereich | Beispiele |
|---|---|
| Mail und Kalender | Google Workspace, Microsoft 365 |
| Kunden und Vertrieb | HubSpot, Pipedrive, Monday, Salesforce |
| Buchhaltung | DATEV, BMD, sevDesk, lexoffice |
| Kommunikation | Slack, Teams |
| Aufgaben und Tickets | Asana, Jira, Zendesk |
| Dateien und Wissen | Drive, SharePoint, Confluence, Notion |
Beispiele für Systeme mit offener Schnittstelle, keine fertigen Anbindungen.
Im Demonstrator angeschlossen: Google Drive und die Google-Anmeldung an der Anwendung; Claude über den Zugang zum Drive. An Claude selbst hängen Mail und Kalender. Das bringt das Werkzeug mit, dafür musste nichts gebaut werden.
- Nachfassmail nach einem Telefonat: der Verlauf steht schon im Projektstand.
- Angebotsentwurf aus Umfang und Laufzeit eines Projekts.
- Monatsrechnung aus den gebuchten Stunden, im Hausdesign.
- Terminvorschläge: offene Aufgaben gegen freie Zeiten im Kalender.
- Wochenbericht je Kunde, ohne dass jemand ihn zusammenstellt.
- Auslastung: wer hat nächste Woche Luft, wo staut es sich.
- Übergabe: alles zu einem Projekt in einem Dokument, für Urlaub oder Wechsel.
- Einarbeitung: neue Leute fragen sich in ein Projekt ein, statt zu suchen.
Keines davon braucht eine Erweiterung der Software. Der Projektstand liegt als Datei bereit; was daraus wird, entscheidet das Werkzeug daneben.
Was es kostet
Gebaut wird für euch. Der Demonstrator ist die Grundlage. Das spart den größten Teil der Entwicklungszeit, die eigentliche Arbeit ist der Zuschnitt auf eure Abläufe.
Danach läuft die Anwendung in eurem Konto: Datenbank und Ablage nach Verbrauch, Modellaufrufe nach Verbrauch. Keine Lizenz pro Nutzer, keine Module, die einzeln freigeschaltet werden. Ein Mitarbeiter mehr kostet nichts. Betreuung und Weiterbau auf Wunsch.
Wie es gebaut ist
Eine Anwendung im Browser, Anmeldung über ein Google-Konto. Darunter eine Postgres-Datenbank. Beim Anlegen eines Projekts entsteht automatisch der Ordner in der Ablage, mit fester Struktur.
Ändert jemand etwas (bucht Stunden, verschiebt eine Aufgabe, schreibt eine Notiz), merkt sich die Datenbank, dass dieses Projekt sich verändert hat. Ein Hintergrundprozess prüft das im Minutentakt und schreibt für jedes betroffene Projekt eine Textdatei in dessen Ordner.
Diese Dateien entstehen ohne Sprachmodell. Es ist Formatierung: Daten aus der Datenbank in eine feste Vorlage, immer dieselbe Reihenfolge, immer dieselben Überschriften. Jede beginnt mit einem Kopf, der sagt, woher sie kommt und wie alt sie ist.
Warum es verlässlich läuft
Dieselben Daten ergeben immer dieselbe Datei. Nichts wird weggelassen, zusammengefasst oder umformuliert. Genau das würde passieren, wenn ein Modell die Datei schriebe.
Die Datenbank bleibt die einzige Wahrheit, die Datei ist ihre Ableitung. Kein zweiter Datenbestand, der auseinanderlaufen kann; geht sie verloren, entsteht sie beim nächsten Lauf neu. Zeitstempel und Versionsnummer stehen drin. Man sieht, ob der Stand aktuell ist, statt es zu vermuten.
Wo KI arbeitet — und wo nicht
In der Software steckt keine KI. Kein Chatfenster, keine Vorschläge, keine Automatik.
Das Modell arbeitet daneben: Es liest die erzeugte Markdown-Datei (.md) und nennt die Quelle mit. Es schreibt nichts zurück und trifft keine Entscheidungen. Damit ist es austauschbar gegen jedes andere Modell, ohne dass an der Anwendung etwas geändert wird.
Der naheliegende Weg wäre, das Modell direkt auf die Datenbank zu lassen. Dann sucht es sich jede Antwort aus einzelnen Abfragen zusammen, der Kontext wächst mit jeder davon, und ab einer gewissen Größe fällt vorne heraus, was hinten dazukommt.
Zahlen aus dem Vergleich
~6.400statt ~16.000
Token pro Frage: Markdown-Datei (_snapshot.md) gegenüber direktem Datenbankzugriff
gemessenClaude Sonnet 4.5, AWS Bedrock, Beispieldaten, drei Läufe je Variante.
3/3statt 0/3
Läufe mit vollständiger Antwort: Markdown-Datei (_snapshot.md) gegenüber direktem Datenbankzugriff
gemessenGleiche Messung wie oben.
Was das für euch heißt
Wenn ihr eine Anwendung braucht, mit der ein Sprachmodell sofort arbeiten kann, ist der Aufbau dafür gebaut und vorführbar. Was ihn zu eurer Lösung macht, ist der Zuschnitt auf eure Abläufe.
Wir zeigen euch den Demonstrator im Gespräch.