AstraCaB GmbH, München#
- Branche
- On-Demand-Transport (Umzug, Transporter, Kurier, Sperrmüll)
- Projektart
- Fahrer-App (mobil), Buchungs-Website (Web), Backend-Arbeit
- Jahr
- 2025
- Dauer
- mehrtägige Episoden über mehrere Monate
Ausgangslage#
AstraCaB betreibt eine Transportplattform in München: Privatkunden und Unternehmen buchen Umzüge, Transporter-Fahrten, Kurierdienste und Sperrmüll-Abholungen — auf Deutsch und mehreren weiteren Sprachen, mit besonderem Fokus auf Expats, die in München ankommen und schnell einen Transport organisieren müssen. Auf der Fahrerseite lief die Auftragsabwicklung nicht über eine App, sondern über Wege, die im Alltag viel Abstimmung kosteten.
Problem#
Ohne eine Fahrer-App landete jede Statusänderung in Telefonaten und Nachfragen: Ist der Auftrag angenommen? Wo steht das Fahrzeug? Ist die Lieferung abgeschlossen? Für ein Unternehmen, das mit fahrenden Fahrern und warternden Kunden arbeitet, ist diese Ungewissheit direkt sichtbar — in verlorenen Minuten pro Auftrag und in Anrufen, die niemand gern führt.
Umfang#
Mein Beitrag in diesem Projekt:
- Die Fahrer-App in Flutter — Auftragsannahme, Auftragsdetail, Statusführung und Navigation im Fahreralltag, aus einer Codebasis für die Geräte, die die Fahrer tatsächlich benutzen.
- Die Buchungs-Website (Web-Frontend, React) — die Kundenseite der Plattform, über die Aufträge entstehen.
- Arbeit am Backend (.NET/C#) — die Schnittstellen, die App und Website mit der Plattformlogik verbinden.
- Ein weiteres Modul — Name und Umfang bleiben hier ungenannt.
Nicht Teil meines Beitrags waren: das Marketing der Plattform, das Betriebs-Team und die interne Organisation von AstraCaB.
Ergebnis#
Die Fahrer-App ist produktiv im Einsatz: Fahrer nehmen Aufträge in der App an, führen sie durch und schließen sie ab, ohne Telefonkette. Was das für AstraCaB konkret an Zeit und Anrufen pro Tag einspart, kann ich hier nicht in Zahlen belegen — dafür müsste der Kunde vermessen haben, was vor der App geschah, und das ist nicht meine Angabe zu erfinden. Die App selbst ist der Beleg: Sie läuft, sie ist im Betrieb, und sie wurde nicht ersetzt.
Was das Projekt nicht gelöst hat: die Plattform ist kein Produkt von mir, und ich betreibe sie nicht. Mein Beitrag endete mit der Übergabe der entwickelten Teile in den laufenden Betrieb des Kunden.
Kosten#
Ein Projekt dieser Größenordnung — ein produktives Modul in einem bestehenden System — bewegt sich heute bei mir im niedrigen fünfstelligen Bereich, als Festpreis nach schriftlichem Scope. Der Weg dorthin läuft über das Erstgespräch und das Scope-Sheet (Prozess), nicht über eine Schätzung am Telefon.
Screenshots#
Für AstraCaB existieren keine Screenshots; die Seite erscheint bewusst ohne Bilder, statt Ersatz zu zeigen. Ein Bildslot ist markiert und wird nachgeliefert, wenn Material freigegeben wird.
Namensnennung#
Die AstraCaB GmbH wird mit ihrer Zustimmung namentlich genannt: kein NDA steht dem entgegen, das Projekt ist abgeschlossen, eine öffentliche Nennung hat es zuvor nicht gegeben. Die technische Aufzählung (Flutter, React, .NET/C#) ist ehrlicher Kontext, kein Verkaufsargument — und kein Beleg für Serverpod-Erfahrung; die stammt aus eigenen Artefakten.
Auch interessant#
- BZBGear — Steuerungssoftware für professionelle Videotechnik, über Jahre weiterentwickelt.
- App-Entwicklung — so läuft eine Flutter-Produktentwicklung bei mir.
- Webentwicklung und Backend-Entwicklung — die anderen Teile dieses Stacks.
- Partner-Leistung — dieses Projekt ist der Beweis, dass ich in einem fremden Stack produktiv arbeiten kann.