Ein internes System und eine mobile App.
Ohne App Stores.

Für wen das gedacht ist

Unternehmen, deren Leute im Außendienst arbeiten — Techniker, Fahrer, Monteure, Lieferteams — koordiniert von Disponenten im Büro. Das bedeutet in der Regel drei getrennte Systeme: eine Web-Anwendung fürs Büro, eine mobile App für den Außendienst und irgendeine Datenbank, die beides verbindet. Drei Systeme, drei Rechnungen, drei Stellen, an denen etwas kaputtgehen kann.

Das Problem mit nativen mobilen Apps

Wenn Sie schon einmal eine native App (Android/iOS) hatten, kennen Sie die Kosten:

• Jede Änderung erfordert einen Mobile-Entwickler — ein eigener Spezialist, ein eigenes Budget.
• Veröffentlichung über App Store und Google Play: Gebühren, Prüfungen, Tage des Wartens.
• Zwei getrennte Codebasen, wenn Sie iPhone und Android unterstützen wollen.
• Nutzer arbeiten mit alten Versionen, weil sie die App nie aktualisiert haben.

Die Antwort: eine App, die im Browser lebt

Wir bauen die mobile Seite als PWA — eine App, die aus dem Browser auf dem Telefon installiert wird, mit Symbol auf dem Startbildschirm wie jede andere, aber ohne App Store.

Sie hat alles, was Sie von einer nativen App erwarten:

• Push-Benachrichtigungen bei neuen Aufträgen — auf Android und iPhone gleichermaßen.
• Offline-Modus — Aufträge lassen sich ohne Empfang ansehen und abschließen (Baustelle im Keller, Funkloch); die Synchronisierung läuft automatisch, sobald die Verbindung zurück ist.
• Kamera — Fotos direkt aus der App an Berichte anhängen.
• GPS — Koordinaten zu jeder Aktion, wenn Ihr Prozess das braucht.
• Zugriff auf Ihren vollständigen Datenkatalog, auch ohne Internet.

Dazu drei Vorteile, die native Apps nicht haben:

1. Sofortige Updates — die neue Version erreicht jedes Telefon unmittelbar, ohne Store und ohne Zutun der Nutzer.
2. Ein Team, eine Codebasis — die Wartung braucht keinen Mobile-Spezialisten.
3. Keine Gebühren an Apple und Google und keine Freigaberegeln.

So läuft es ab

Zuerst beschreiben wir Ihren Prozess so, wie er tatsächlich abläuft — wer macht was, in welcher Reihenfolge, und wo hakt es. Danach bauen wir das System darum herum, nicht umgekehrt.

Wenn wir ein bestehendes System ablösen, gilt: Das erste Release ist für Ihre Nutzer nicht vom alten zu unterscheiden. Keine „Verbesserungen", die Menschen verwirren, die an das Gewohnte gewöhnt sind. Neue Funktionen werden erst nach abgeschlossener Umstellung freigeschaltet.

Ein Beispiel aus der Praxis

Ein Unternehmen mit Standorten in zwei Ländern betrieb drei Systeme — Web für die Disposition, eine native Android-App für den Außendienst und eine Cloud-Datenbank mit steigenden Gebühren. iPhones wurden gar nicht unterstützt.

Wir haben all das durch ein System ersetzt: 12 Arbeitstage für die vollständige Ablösung, inklusive Migration von über 38.000 Datensätzen und des kompletten Archivs. Die mobile Seite ist eine PWA mit Push, Offline-Modus und Kamera, geprüft auf echter iPhone- und Android-Hardware. Die Wartung braucht keinen Mobile-Spezialisten mehr.