Die FuelBuddy Driver App ist das, womit Fahrer den Kraftstoff tatsächlich zu den Kunden ausliefern. Für Fahrer zu entwickeln ist ein eigenes Problem: Der Bildschirm muss bei direkter Sonneneinstrahlung lesbar sein, Antippen muss verzeihend sein, und das Netz kann unterwegs jederzeit abreißen. Ich habe eine Reihe von Features end to end gebaut, die genau auf diese Bedingungen zugeschnitten sind – das Frontend und die dahinterliegenden Daten-APIs.

Was ich gebaut habe

Offline-tolerante Oberfläche: Fahrer verlieren regelmäßig das Signal, deshalb habe ich Routen- und Auftragsdaten lokal zwischengespeichert und ihnen ermöglicht, in Funklöchern weiterzuarbeiten. Die App reiht Änderungen in eine Warteschlange ein und synchronisiert sie zurück, sobald die Verbindung zurückkehrt, statt einzufrieren.
Standort und Karten: Das Frontend für die Live-GPS-Verfolgung und die Kartenroutenführung übernommen und häufige Standort-Updates und Karten-Neuzeichnungen effizient gehalten, damit sie über eine lange Schicht nicht den Akku leersaugen.
Feldtaugliche UX: Mehrere operative Features end to end verantwortet und für reale Bedingungen gestaltet – kontrastreiche Layouts, große Antippbereiche und kurze Formulare, damit Fahrer eine Lieferung schnell und sicher erfassen können.
Die APIs dahinter: Die CRUD-APIs gebaut, aus denen diese Features lesen und in die sie schreiben, auf Hasuras GraphQL-Engine, sodass ich ein Feature end to end ausliefern konnte – die Offline-Warteschlange, die Auftragsdaten und das Erfassen der Lieferungen sprechen alle mit Endpunkten, die ich verantwortet habe.

Warum es wichtig war

Das Gestalten für einen Kontext mit dem Handy in der Hand und in Bewegung machte die App im Feld schneller nutzbar. Fahrer konnten sich auf die Straße und die Lieferung konzentrieren, statt gegen einen trägen Bildschirm zu kämpfen, was die Lieferungen in Bewegung hielt.