Wenn in Ihrem Unternehmen Mitarbeiter draußen arbeiten und nach ihren Einsätzen noch Berichte tippen, ist diese Fallstudie Ihre Referenzarchitektur. Mit DokuAI habe ich das Muster erprobt. Derselbe Bauplan passt auf jedes Problem, bei dem Menschen unterwegs strukturierte Daten erzeugen, und es ist genau der Technologie-Stack, den ich für Kunden liefere.
Das Problem: Berichte, die nach dem Einsatz getippt werden
Bauleiter, Techniker, Sachverständige und Schadenregulierer haben eines gemeinsam: Ihre Arbeit besteht aus Außenterminen und deren Dokumentation. Eine Beispielrechnung: Wer nach dem Einsatz zwei Stunden mit Berichten, dem Sortieren von Fotos und dem Zuordnen von Adressen verbringt, kommt bei 20 Personen auf rund 40 bezahlte Stunden pro Tag, die in Verwaltung fließen statt in Wertschöpfung.
Das ist kein Softwareproblem, sondern ein Problem im Arbeitsablauf, das Software beseitigen kann. DokuAI zeigt, wie das geht: Statt am Schreibtisch zu tippen, nehmen Sie vor Ort eine kurze Sprachnotiz und ein Foto auf. Struktur, Ortsangabe und Format entstehen, während Sie zurück ins Büro fahren.
Die Architektur: sechs kleine Services und eine Flutter-App
Ein Monolith wäre hier ein Fehler. Die rechenintensive Arbeit läuft asynchron, denn eine Transkription dauert Sekunden bis Minuten. Die Fehlerquellen sind voneinander unabhängig: Ein kurzer Aussetzer bei Whisper darf die Erstellung von Berichten nicht blockieren. Und die Mandanten wollen Trennung, jedes Unternehmen sieht nur seine eigenen Aufträge. Das ausgelieferte System besteht deshalb aus sechs Quarkus-Services auf Kubernetes:
api-service
Die einzige öffentlich erreichbare Schnittstelle. Sie ist zuständig für Authentifizierung, Rate-Limiting, Validierung und den Aufbau der Antworten. Alle anderen Services sind intern. An dieser Grenze setzt jedes Audit und jeder Penetrationstest an, und hinter ihr lassen sich Implementierungen austauschen, ohne die App anzufassen.
transcription-service
Wandelt Audio mit Whisper in Text um. Er arbeitet eine Queue ab und beantwortet keine synchronen Requests. Eine 30-Sekunden-Notiz von einer lauten Baustelle braucht 15 Sekunden bis zur sauberen Transkription. Müsste die iOS-App synchron darauf warten, gäbe es bei jeder schwachen Mobilfunkverbindung 504-Fehler.
image-service
OpenAI Vision, dazu eine deterministische OCR-Pipeline als Rückfallebene. Der Service liest aus dem Foto zum Beispiel Maschinenmodell, Schadensart oder die Raumnummer am Türschild. Die Rückfallebene ist wichtig: Vision arbeitet statistisch, OCR nicht, und Berichte müssen reproduzierbar sein.
location-service
Geocoding, Prüfung der Projektgrenzen und Glättung der GPS-Daten. Er schließt die Lücke zwischen „Ich war auf einer Baustelle“ und „Ich war genau an dieser Adresse, die die Schadensdatenbank kennt“. Das Problem ist überraschend schwer, und die Wirkung auf die nachgelagerte Bürokratie ist überraschend groß.
report-service
Verwaltet die typisierten Berichtsvorlagen und die Logik, mit der Berichte zusammengestellt werden. Das Ergebnis ist strukturiert, geprüft und bereit für die PDF-Erzeugung oder den Import ins ERP. Die Vorlagen sind versioniert, sodass alte Berichte reproduzierbar bleiben, auch wenn eine Vorlage später geändert wird.
feedback-service
Sammelt Feedback über alle Apps hinweg. Er ist nicht auf DokuAI beschränkt: Jede App, die ich ausliefere, meldet hierher, damit ich sehe, wo Nutzer tatsächlich hängen bleiben. Für einen Kunden wird daraus ein gemeinsamer Infrastrukturbaustein für sein gesamtes App-Portfolio.
Warum Kafka zwischen den Services statt REST
Würde der api-service den transcription-service über REST aufrufen und auf die Antwort warten, würde sich eine einzige langsame GPU auf der Whisper-Seite bis in jede iOS-App über 3G auswirken. Stattdessen schreibt der api-service in ein Kafka-Topic, gibt sofort eine Job-ID zurück, und die rechenintensiven Services verarbeiten das Topic in ihrem eigenen Tempo. Die Mobile-App fragt regelmäßig einen Status-Endpoint ab, der aus einer von Kafka gespeisten Projektion liest. Das ist schnell, zustandslos und unempfindlich gegen jede Verzögerung weiter hinten.
Der Preis liegt im Betrieb: Kafka ist ein weiterer Service, den Sie betreiben müssen. Der Nutzen: Das gesamte Backend übersteht einen fünfminütigen Teilausfall, ohne einen einzigen Bericht zu verlieren. Für ein Unternehmen, das seinen Kunden dokumentierte Arbeit in Rechnung stellt, entscheidet diese Ausfallsicherheit darüber, ob es entspannt wachsen kann oder freitagnachmittags in Panik gerät.
Die Flutter-Seite
Eine Codebasis für iOS und Android, die sich wie eine native App anfühlt. Die Aufnahme von Sprachmemos nutzt die Plattform-APIs statt einer Web-Zwischenschicht. Fotos laufen über die Kamera mit Offline-Puffer, und jeder Upload lässt sich nach einem Verbindungsabbruch fortsetzen. Seit zwei Monaten in Produktion, Bewertung im App Store 5,0.
Ergebnisse: was sich für die Anwender verändert hat
- Der Bericht entsteht vor Ort statt am Schreibtisch. Eine kurze Sprachnotiz und ein Foto ersetzen die Stunden am Rechner.
- Ort und Fotos werden automatisch als Beleg angehängt. Niemand fragt sich fünf Tage später mehr, wo dieses Foto entstanden ist.
- Mehrsprachige Transkription von Haus aus, einschließlich deutschem Baustellenvokabular nach einem kleinen Nachbearbeitungsschritt.
- Bewertung im App Store 5,0 zum Zeitpunkt dieses Beitrags.
Was das für Ihr Projekt bedeutet
Wenn Ihr Unternehmen einen Außendienst hat, der seine Arbeit dokumentiert, etwa im Bau, bei Inspektionen, in der Immobilienwirtschaft, im Gesundheitswesen, im technischen Service oder in der Schadenregulierung, dann passt genau dieses Muster. Anders sind nur die Berichtsvorlage, die Anbindung an Ihr ERP und die Art der Belege, die Sie sammeln. Das Grundgerüst bleibt dasselbe.
Diesen Stack liefere ich:
- Flutter im Frontend für gleiche Funktionen auf beiden Plattformen, oder natives Swift/Kotlin, wenn Ihr Umfeld das verlangt.
- Quarkus auf Kubernetes im Backend, ausgelegt auf Ihr Lastprofil.
- Kafka für asynchrone Ausfallsicherheit, aber nur, wenn Ihre Last das rechtfertigt (kleinere Teams kommen ohne aus).
- Eine typisierte Berichts-Engine, die vollständig Ihnen gehört, ohne Bindung an fremde Vorlagen.
Ein produktiver Umfang dieser Größe dauert drei bis vier Monate ab dem Projektstart. Ein MVP, der nur den Kern abdeckt, also aus Sprache einen Bericht macht, ist in zwei bis vier Wochen fertig. Preise siehe Leistungen für die typischen Preisspannen, hier starten, falls Ihre Situation dem DokuAI-Muster ähnelt.
Im App Store ansehen: DokuAI lässt sich kostenlos installieren. Probieren Sie es auf einer echten Baustelle aus, dann merken Sie, wie sich ein Bericht in 90 Sekunden tatsächlich anfühlt.