FLINTAXI unter der Haube

Von Surfboards und Photoshop-Erweiterungen über digitale Zeitungen bis zu PHP, Vue, Swift und Kotlin. Ein Blick hinter die Technik von FLINTAXI – und auf das, was im November und Dezember noch kommt.

Wer FLINTAXI kennt, denkt vermutlich zuerst an Taxis, Fahrgäste und Buchungen.

Ich denke dabei manchmal an etwas anderes.

An API-Requests. Datenbankabfragen. Zustandswechsel. Push-Nachrichten. Und an die wunderbare Frage, warum eine Funktion, die gestern noch problemlos funktioniert hat, heute plötzlich beschlossen hat, ein Eigenleben zu führen.

Willkommen in meiner Welt.

Ich bin Stefan und entwickle die technische Plattform hinter FLINTAXI. Und bevor ich euch erzähle, welche Technologien dabei zum Einsatz kommen, muss ich ein bisschen weiter ausholen.

Genauer gesagt: bis ins Jahr 1984.

Ja, 1984.

Damals war ein Computer noch etwas, das man bewusst einschaltete, um damit zu arbeiten. Und nicht etwas, das einem beim Frühstück ungefragt mitteilt, dass schon wieder ein Softwareupdate verfügbar ist.

Seit 1984 Apple. Und immer noch nicht geheilt.

Ich bin seit 1984 Apple-User.

Das bedeutet nicht nur, dass ich eine gewisse Vorliebe für Geräte mit einem angebissenen Apfel entwickelt habe. Es bedeutet auch, dass ich eine ziemlich lange Entwicklung der Computerwelt miterlebt habe.

Von einer Zeit, in der Speicherplatz kostbar war und man sich über jedes zusätzliche Megabyte freute, bis zu einer Gegenwart, in der eine App schon einmal mehrere Hundert Megabyte benötigt, um einen Button und drei Einstellungen darzustellen.

Fortschritt ist eben relativ.

Mein erstes selbst geschriebenes Programm hatte übrigens nichts mit Taxis zu tun. Es berechnete das Volumen von Surfboards.

Ein ziemlich praktisches Problem, das ich damals mit Software lösen wollte. Und genau das hat mich von Anfang an fasziniert: Ein reales Problem nehmen, es in eine mathematische oder logische Struktur übersetzen und daraus etwas machen, das tatsächlich funktioniert.

Im Idealfall sogar beim ersten Versuch.

Wobei wir alle wissen, dass dieser Idealfall hauptsächlich in Präsentationen vorkommt.

Die 90er: Photoshop, Druckvorstufe und ziemlich spezielle Probleme

In den 1990er-Jahren habe ich zahlreiche Programme für die digitale Druckvorstufe entwickelt.

Das war eine Zeit, in der die analoge und die digitale Welt auf ziemlich spannende Weise aufeinandertrafen.

Ein Beispiel waren Erweiterungen für Photoshop, mit denen sich analoge Vierfarbfilme digital weiterverarbeiten ließen. Dabei ging es unter anderem darum, die gerasterten Farbauszüge zu entrastern und wieder zu einem vollständigen Bild zusammenzufügen.

Für alle, die mit Drucktechnik wenig anfangen können: Im klassischen Vierfarbdruck wird ein Bild in die Druckfarben Cyan, Magenta, Gelb und Schwarz zerlegt.

Wenn man diese vier Farbauszüge wieder digital zu einem brauchbaren Bild zusammensetzen möchte, ist das deutlich komplizierter, als vier Dateien zu öffnen und auf „Zusammenfügen“ zu klicken. Vor allem, wenn die Vorlagen aus einer analogen Produktionswelt stammen.

Solche Aufgaben haben mir viel beigebracht. Über Bildverarbeitung. Über Algorithmen. Über Präzision.

Und darüber, dass ein Computer grundsätzlich exakt das macht, was man ihm sagt.

Leider auch dann, wenn man ihm etwas völlig Falsches gesagt hat.

Die 2000er: E-Commerce, SaaS und die große Web-Euphorie

Anfang der 2000er-Jahre ging es dann verstärkt in Richtung Internet. Ich entwickelte unter anderem E-Commerce-Systeme und SaaS-Lösungen.

Damals wurde das Web zunehmend zu einer Plattform, auf der man nicht nur Informationen lesen, sondern ganze Geschäftsprozesse abwickeln konnte.

Heute klingt das selbstverständlich. Damals war vieles davon noch echtes Neuland.

Und während sich die Technologien laufend veränderten, blieb eine Sache konstant: Irgendjemand musste dafür sorgen, dass Frontend, Backend, Datenbank und Geschäftslogik tatsächlich miteinander funktionierten.

Das war damals schon spannend. Und ist es heute noch.

Nur haben wir inzwischen deutlich mehr Frameworks, Build-Tools, Paketmanager und Abhängigkeiten, die uns dabei helfen.

Oder uns zumindest sehr überzeugend erklären, warum etwas gerade nicht funktioniert.

Wetter-Apps, digitale Zeitungen und die Lange Nacht der Forschung

Im Laufe der Jahre durfte ich an sehr unterschiedlichen Projekten arbeiten.

Dazu gehörten beispielsweise Wetter-Apps für wetter.at – ein Projektbereich, in dem aktuelle Daten, verständliche Darstellung und mobile Benutzeroberflächen zusammenkommen.

Dann war da die erste digitale Zeitung für iPhone und iPad der Tageszeitung ÖSTERREICH. Zu einer Zeit, als digitale Zeitungen auf Tablets noch etwas Neues waren und nicht einfach eine weitere App zwischen Wetter, Nachrichten und dem nächsten Abo-Hinweis.

Auch Backend und Frontend für die Lange Nacht der Forschung gehörten zu meinen Projekten.

Dazu kamen viele weitere Anwendungen und Systeme, die sich technisch teilweise stark voneinander unterschieden.

Und genau das war immer der Reiz.

Ich habe mich nie besonders dafür interessiert, mein ganzes Entwicklerleben ausschließlich in einer einzigen Programmiersprache oder Technologie zu verbringen.

Dafür gibt es einfach zu viele interessante Probleme. Und zu viele Möglichkeiten, sie zu lösen.

Manche davon sind sogar gut.

Und heute? FLINTAXI.

Nach all diesen Jahren bin ich bei einem Projekt gelandet, das erstaunlich viele meiner bisherigen Erfahrungen zusammenführt: FLINTAXI.

Eine Mobilitätsplattform, bei der es nicht nur darum geht, eine hübsche App auf ein Smartphone zu bringen.

Hier treffen Webentwicklung, Backend-Logik, native mobile Anwendungen, Datenverarbeitung, Benutzeroberflächen und reale betriebliche Abläufe aufeinander.

Und das alles muss zusammenspielen. Möglichst zuverlässig.

Denn ein Fehler in einem kleinen Hobbyprojekt ist ärgerlich. Ein Fehler in einer Anwendung, die gerade eine echte Taxifahrt abwickelt, hat eine ganz andere Qualität.

Schauen wir also einmal unter die Motorhaube.

PHP: Totgesagte programmieren länger

Fangen wir mit PHP an.

Ja, PHP.

Ich weiß.

Es gibt Entwickler, die bei diesem Namen reflexartig die Augen verdrehen.

Manche erklären PHP seit ungefähr zwei Jahrzehnten für tot. Das ist bemerkenswert für eine Technologie, die sich hartnäckig weigert, diesen Nachruf zur Kenntnis zu nehmen.

Bei FLINTAXI verwende ich PHP für wesentliche Teile unserer Website und unseres Admin-Systems.

Und nein, das ist keine nostalgische Entscheidung aus meiner Apple-Frühzeit.

PHP ist für viele serverseitige Aufgaben nach wie vor ein leistungsfähiges und pragmatisches Werkzeug.

Entscheidend ist schließlich nicht, ob eine Programmiersprache gerade auf der nächsten Entwicklerkonferenz besonders cool klingt. Entscheidend ist, ob man damit eine stabile, wartbare und funktionierende Lösung bauen kann.

Ein revolutionärer Gedanke, ich weiß.

Das Admin-System: Die eigentliche Kommandozentrale

Wenn ich von unserem Admin-System spreche, meine ich nicht drei Tabellen, zwei Suchfelder und einen Export-Button.

Unser Admin ist eine ziemlich mächtige Schaltzentrale. Hier laufen wichtige Verwaltungsfunktionen und betriebliche Abläufe zusammen. Und über die Backend-APIssteht das System mit den anderen Teilen der FLINTAXI-Plattform in Verbindung.

Denn eine Mobilitätsplattform besteht nicht aus ein paar isolierten Anwendungen, die zufällig denselben Namen tragen.

Eine Buchung hat einen Status. Ein Driver kann eine Fahrt annehmen. Eine Fahrt beginnt, läuft und wird abgeschlossen. Und die unterschiedlichen Anwendungen müssen mit diesen Informationen sinnvoll umgehen können.

Das klingt einfach, solange man es auf ein Whiteboard zeichnet.

Dort funktionieren Systeme übrigens grundsätzlich hervorragend.

Die Probleme beginnen meistens erst, wenn echte Geräte, echte Daten, echte Netzwerkverbindungen und echte Menschen dazukommen.

Die Backend-APIs bilden einen wichtigen Teil dieses Zusammenspiels. Sie sorgen dafür, dass unterschiedliche Anwendungen miteinander kommunizieren können, ohne gegenseitig ihre internen Details kennen zu müssen.

Das Admin-System ist damit wesentlich mehr als eine Verwaltungsoberfläche. Es ist ein zentraler Bestandteil der technischen FLINTAXI-Welt.

Wie genau die internen Abläufe organisiert sind, bleibt allerdings intern.

Ich schreibe hier schließlich einen Blogartikel und keine kostenlose Architektur-Dokumentation für neugierige Dritte.

Vue und JavaScript: Das Web möchte auch eine App sein

Neben unserer Website gibt es bei FLINTAXI eine Progressive Web App, kurz PWA. Hier kommen Vue und JavaScript zum Einsatz.

JavaScript ist eine dieser Sprachen, die man lieben oder hassen kann. Manchmal sogar beides innerhalb derselben Funktion.

Mit Vue lassen sich dynamische Benutzeroberflächen entwickeln, die auf Änderungen reagieren, ohne ständig komplette Seiten neu laden zu müssen.

Das ist besonders interessant, wenn man mit Buchungen, Statusinformationen und interaktiven Abläufen arbeitet.

Eine PWA nutzt Webtechnologien, kann sich aber in vielen Situationen wie eine eigenständige Anwendung anfühlen.

Für mich ist das eine spannende Ergänzung zur nativen App-Entwicklung. Denn nicht jede Aufgabe benötigt zwingend eine eigene Anwendung für jedes Betriebssystem.

Manchmal ist eine Weblösung genau richtig. Und manchmal eben nicht.

Die Kunst besteht darin, den Unterschied zu erkennen, bevor man sechs Monate in die falsche Richtung entwickelt hat.

Und weil Stillstand bekanntlich keine besonders attraktive Produkteigenschaft ist, bekommt unsere PWA demnächst ein größeres Update. Dazu später mehr.

Swift: Meine bevorzugte Sprache mit Apfelgeschmack

Für die nativen iOS-Anwendungen von FLINTAXI verwende ich Swift.

Und ja, hier kommt meine jahrzehntelange Apple-Vergangenheit wieder zum Vorschein.

Ich entwickle gerne nativ. Nicht, weil plattformübergreifende Lösungen grundsätzlich schlecht wären, sondern weil ich die Möglichkeiten eines Betriebssystems gerne direkt nutze.

Gerade unsere iOS-Driver-App stellt besondere Anforderungen. Sie muss mit Buchungen umgehen, Fahrten begleiten, Statusänderungen verarbeiten und Informationen im richtigen Moment bereitstellen.

Dazu kommen Navigation, Benachrichtigungen und all die kleinen Eigenheiten mobiler Betriebssysteme.

Besonders unterhaltsam wird es, wenn eine App im Simulator perfekt funktioniert, auf dem echten Gerät aber plötzlich beschließt, die Sache etwas kreativer anzugehen.

Zum Glück gibt es TestFlight. Und zum Glück gibt es geduldige Testerinnen.

Unsere neue native iOS-Driver-App hat mehr als 20 Entwicklungsiterationen durchlaufen. Sima allein hat mir dabei fast 230 TestFlight-Feedbacks geschickt.

Das ist eine beeindruckende Zahl. Vor allem, wenn man bedenkt, dass hinter jedem Feedback meist eine neue Aufgabe für mich stand.

Aber genau diese Rückmeldungen haben geholfen, die App Schritt für Schritt besser zu machen.

Am 27. Oktober 2026 wurde schließlich die erste echte, regulär gebuchte Fahrt mit der neuen iOS-Driver-App erfolgreich abgeschlossen. Und zwar von Sima selbst.

Diesmal kam übrigens kein Bugreport. Sondern drei WhatsApp-Nachrichten:

Erste Live Fahrt.

Abgeschlossen.

Tolles Gefühl.

Nach fast 230 Feedbacks war das eine ausgesprochen angenehme Abwechslung.

Wichtig ist dabei: Die iOS-Driver-App wird derzeit bereits unter echten Live-Bedingungen getestet, ist aber noch nicht öffentlich im App Store verfügbar. Live-Betrieb und App-Store-Veröffentlichung sind schließlich zwei verschiedene Dinge – auch wenn man nach einem erfolgreichen Test am liebsten sofort auf „Release“ klicken würde.

Kotlin: Weil nicht alle einen Apfel haben wollen

Natürlich gibt es neben iOS noch eine andere, nicht ganz unbedeutende Smartphone-Welt.

Android.

Dafür setze ich auf Kotlin.

Und wer schon einmal native Anwendungen für iOS und Android entwickelt hat, weiß: Zwei Plattformen können dieselbe Aufgabe erstaunlich unterschiedlich interpretieren.

Was unter iOS elegant gelöst ist, verlangt unter Android manchmal einen ganz anderen Ansatz. Und umgekehrt.

Die Herausforderung besteht deshalb nicht darin, Swift-Code einfach nach Kotlin zu übersetzen. Es geht darum, dieselben fachlichen Funktionen sinnvoll in die jeweilige Plattform zu integrieren.

Die Benutzeroberflächen dürfen sich dabei durchaus an den Eigenheiten des Betriebssystems orientieren. Die zugrunde liegenden Abläufe müssen aber zusammenpassen.

Denn unserem Backend sollte es ziemlich egal sein, ob eine Anfrage von einem iPhone, einem Android-Gerät oder einer Webanwendung kommt.

Eine gültige Anfrage bleibt eine gültige Anfrage.

Zumindest solange niemand auf die Idee kommt, das API-Format kurz vor Feierabend zu ändern.

Backend-APIs: Der Klebstoff, den niemand sieht

Wenn man PHP, Vue, JavaScript, Swift und Kotlin aufzählt, klingt das zunächst nach einer ziemlich bunten Sammlung.

Ist es auch.

Aber die unterschiedlichen Technologien erfüllen unterschiedliche Aufgaben. Zusammengehalten werden sie unter anderem durch unsere Backend-APIs.

Und hier zeigt sich, warum langjährige Erfahrung mit unterschiedlichsten Systemen hilfreich sein kann.

Man muss nicht nur verstehen, wie eine einzelne Anwendung funktioniert. Man muss auch darüber nachdenken, wie die Teile miteinander kommunizieren, welche Informationen sie benötigen und was passiert, wenn etwas schiefgeht.

Ein Frontend kann noch so schön sein. Wenn das Backend Unsinn liefert, wird der Unsinn dadurch höchstens schöner dargestellt.

Und eine API kann technisch vollkommen korrekt antworten und trotzdem fachlich das Falsche tun.

Das ist einer der Gründe, warum ich Backend-Entwicklung so spannend finde.

Die wirklich interessanten Fehler sind oft nicht die, bei denen eine Anwendung abstürzt. Sondern jene, bei denen sie völlig überzeugt etwas Falsches macht.

Bot Block: Nicht jeder Request verdient einen Kaffee

Ein weiteres Thema bei FLINTAXI ist der Schutz unserer Webanwendungen vor unerwünschten automatisierten Zugriffen. Dafür verwenden wir unter anderem unsere eigene Bot-Block-Methode.

Denn im Internet ist nicht jeder Besucher tatsächlich ein Mensch. Und nicht jeder automatisierte Request verfolgt ein besonders freundliches Ziel.

Manche Bots sammeln Informationen. Andere versuchen, Formulare zu missbrauchen oder unnötige Last zu erzeugen.

Wieder andere benehmen sich, als hätten sie den Server persönlich bezahlt und dürften deshalb unbegrenzt darauf herumturnen.

Unsere Aufgabe ist es, solche Zugriffe möglichst sinnvoll zu behandeln, ohne legitime Besucherinnen und Besucher unnötig zu behindern.

Denn eine Sicherheitsmaßnahme, die alle Menschen erfolgreich aussperrt, ist zwar auf eine gewisse Weise effektiv. Aber geschäftlich eher unpraktisch.

Wie unsere Bot-Block-Methode im Detail funktioniert, werde ich natürlich nicht erklären.

Sicherheitsmechanismen verlieren gelegentlich an Charme, wenn man ihre genaue Funktionsweise öffentlich als Schritt-für-Schritt-Anleitung veröffentlicht.

Sagen wir einfach: Nicht jeder automatisierte Besucher bekommt bei uns die gleiche Gastfreundschaft.

Über 40 Jahre Entwicklung – und die Bugs sind immer noch da

Wenn ich auf meine bisherigen Projekte zurückblicke, ist eines besonders auffällig: Die Technologien haben sich ständig verändert.

Von frühen Apple-Computern über digitale Druckvorstufe und Photoshop-Erweiterungen bis zu E-Commerce, SaaS, mobilen Apps und komplexen Backend-Systemen.

Ich habe über die Jahre mit vielen unterschiedlichen Programmiersprachen, Werkzeugen und Entwicklungsumgebungen gearbeitet.

Manche davon sind längst Geschichte. Andere erleben gerade ihre dritte Wiedergeburt unter einem neuen Namen.

Und einige Konzepte, die heute als revolutionär verkauft werden, kommen mir verdächtig bekannt vor.

Was sich aber kaum verändert hat, ist die eigentliche Aufgabe.

Ein Problem verstehen. Eine sinnvolle Lösung entwickeln. Sie ausprobieren. Feststellen, dass die Realität leider nicht vollständig mit der eigenen Vorstellung übereinstimmt. Nachbessern.

Und irgendwann funktioniert es.

Meistens.

Die größte Veränderung ist vielleicht, dass wir heute unglaublich leistungsfähige Werkzeuge haben. Aber auch unglaublich viele Möglichkeiten, neue Komplexität zu erzeugen.

Früher musste man sich überlegen, wie man mit wenig Speicher auskommt. Heute überlegt man manchmal, warum ein Projekt 800 Abhängigkeiten benötigt, bevor überhaupt die erste Zeile eigener Code ausgeführt wird.

Jede Zeit hat ihre Herausforderungen.

November und Dezember: Vier native Apps, eine PWA und ein Entwickler mit vielen offenen Projekten

Bis hierher ging es vor allem um Vergangenheit und Gegenwart. Aber ich wäre kein Entwickler, wenn ich nicht schon längst an den nächsten Versionen arbeiten würde.

November und Dezember 2026 werden für FLINTAXI ziemlich interessante Monate.

Und falls ich zwischendurch nachschauen muss, ob ich gerade im Rider-, Driver-, iOS-, Android- oder Vue-Projekt arbeite: Das ist kein Bug. Das ist Projektmanagement in freier Wildbahn.

Vier native Apps. Zwei Betriebssysteme. Eine PWA. Ein gemeinsames Backend. Und ein Entwickler, der gelegentlich nachschauen muss, in welchem Projekt er gerade arbeitet.

Damit auch alle anderen den Überblick behalten, hier der aktuelle Plan:

Die Zeitangaben sind der aktuelle Planungsstand. Bei Software gilt wie immer: Veröffentlicht wird, wenn die Qualität stimmt – nicht bloß, weil ein Kalenderblatt umgeblättert wurde.

Zuerst: Android Driver

Während die iOS-Driver-App bereits unter realen Bedingungen getestet wird, ist auch die native Android-Driver-App auf dem Weg.

Sie soll spätestens innerhalb der nächsten zwei Wochen erscheinen.

Damit unterstützen wir Driver Schritt für Schritt auf beiden großen Smartphone-Plattformen mit nativen Anwendungen.

Und ja, das bedeutet auch wieder Tests, Nachbesserungen und die gelegentliche Erkenntnis, dass Android manche Dinge einfach anders sieht als iOS.

Wäre ja sonst langweilig.

Ende November: Rider iOS

Auch für die Fahrgastseite tut sich einiges.

Die neue native iOS-Rider-App steht kurz vor dem Finale. Die letzten Arbeiten laufen, und die Veröffentlichung im Apple App Store ist für Ende November geplant.

Damit bekommt FLINTAXI auch auf der Fahrgastseite ein natives iPhone-Erlebnis.

Für mich ist das ein besonderer Meilenstein: Eine Mobilitätsplattform wird erst richtig interessant, wenn beide Seiten – Fahrgäste und Driver – mit Anwendungen arbeiten können, die zu ihrem jeweiligen Alltag passen.

Ebenfalls Ende November: PWA 2.0

Parallel dazu bekommt unsere bestehende Progressive Web App ein umfangreiches Update.

Ende November soll die FLINTAXI PWA 2.0 die bisherige PWA ablösen.

Dabei geht es nicht einfach darum, ein paar Buttons neu einzufärben und anschließend eine höhere Versionsnummer draufzuschreiben.

Die neue PWA orientiert sich optisch und funktional an unseren nativen Rider-Apps.

Das Ziel: ein durchgängiges, einheitliches Benutzererlebnis – unabhängig davon, ob jemand FLINTAXI auf einem iPhone, Android-Gerät oder über das Web nutzt.

Die grundlegende Bedienung, die Abläufe und das Erscheinungsbild sollen vertraut bleiben.

Technisch bedeutet das, dass unterschiedliche Technologien möglichst dieselbe Produktsprache sprechen müssen.

Swift, Kotlin und Vue setzen sich schließlich nicht von Natur aus gemeinsam an einen Tisch und einigen sich freiwillig auf ein Interface.

Da muss man gelegentlich ein wenig nachhelfen.

Aber genau dieser Aufwand lohnt sich. Denn die beste technische Vielfalt ist jene, von der die Menschen, die eine Anwendung verwenden, möglichst wenig mitbekommen.

Anfang Dezember: Rider Android

Und damit Android-Nutzerinnen und -Nutzer nicht nur interessiert zuschauen müssen, folgt der nächste Schritt gleich darauf.

Die native FLINTAXI-Rider-App für Android ist für Anfang Dezember geplant.

Damit soll die neue Rider-Generation auf beiden großen mobilen Plattformen verfügbar werden.

Zusammen mit der PWA 2.0 entsteht so eine einheitliche FLINTAXI-Welt, die auf unterschiedlichen Geräten funktioniert, ohne sich jedes Mal wie eine völlig andere Anwendung anzufühlen.

Das ist zumindest das Ziel.

Und wie immer in der Softwareentwicklung gilt: Der Plan steht. Die letzten Tests entscheiden, wann eine Version tatsächlich bereit für die Veröffentlichung ist.

Denn eine App nur deshalb zu veröffentlichen, weil im Kalender ein bestimmtes Datum steht, war noch nie eine besonders gute technische Strategie.

Advent und Weihnachten: Eine kleine Überraschung

Und weil der Dezember nicht ausschließlich aus App-Releases, Backend-APIs und Debugging bestehen sollte, habe ich noch etwas anderes vorbereitet.

In der Adventszeit beziehungsweise rund um Weihnachten wartet auf die FLINTAXI-Community eine kleine Überraschung.

Etwas zum Abschalten, Entdecken und Schmunzeln.

Mehr möchte ich dazu im Moment noch nicht verraten.

Nur so viel: Es hat ausnahmsweise nichts damit zu tun, möglichst schnell von A nach B zu kommen.

Und ja, auch dafür musste ich natürlich wieder Code schreiben.

Manche Menschen entspannen beim Fernsehen. Ich offenbar beim Erfinden neuer Entwicklungsaufgaben.

Ein gemeinsames Erlebnis – trotz unterschiedlicher Technologien

Wenn man sich diese Roadmap ansieht, erkennt man vielleicht auch, worauf ich bei FLINTAXI langfristig hinauswill.

Es geht nicht darum, einfach möglichst viele Apps zu veröffentlichen.

Eine iOS-App, eine Android-App und eine PWA zu haben, ist für sich genommen noch keine große Kunst.

Die eigentliche Herausforderung besteht darin, dass sich all diese Anwendungen wie Teile einer gemeinsamen Plattform anfühlen.

Mit vertrauten Abläufen. Mit einem einheitlichen Erscheinungsbild. Und mit einem Backend, das die unterschiedlichen Anwendungen zuverlässig miteinander verbindet.

Hinter einem scheinbar einfachen Buchungsvorgang steckt ein Zusammenspiel aus Technologien, die teilweise völlig unterschiedlich funktionieren.

Und trotzdem soll am Ende alles selbstverständlich wirken.

Genau daran arbeite ich. Und genau deshalb freue ich mich auf die kommenden Wochen.

Warum ich FLINTAXI technisch so spannend finde

Nach all diesen Jahren macht mir Softwareentwicklung immer noch Spaß.

Nicht jede Minute, zugegeben.

Wenn ich zwei Stunden lang einen Fehler suche und schließlich feststelle, dass ich selbst vor drei Tagen die entscheidende Zeile verändert habe, hält sich meine Begeisterung kurzfristig in Grenzen.

Aber genau diese Mischung aus Logik, Kreativität, Erfahrung und gelegentlicher Verzweiflung macht die Arbeit interessant.

FLINTAXI vereint vieles, womit ich mich seit Jahrzehnten beschäftige: Webentwicklung, Backend-Systeme, Datenverarbeitung, mobile Anwendungen, Benutzeroberflächen und Sicherheit.

Und vor allem die Herausforderung, aus vielen einzelnen technischen Komponenten ein funktionierendes Ganzes zu machen.

Dabei geht es nicht darum, möglichst viele Programmiersprachen auf eine Liste schreiben zu können. Es geht darum, für unterschiedliche Aufgaben passende Werkzeuge einzusetzen.

PHP für wesentliche Teile der Web- und Admin-Welt. Vue und JavaScript für unsere PWA – und demnächst PWA 2.0. Swift für die nativen iOS-Apps. Kotlin für die Android-Entwicklung.

Und dazwischen Backend-APIs, die dafür sorgen, dass diese Anwendungen nicht einfach nebeneinander existieren, sondern miteinander arbeiten.

Nach über 40 Jahren mit Computern finde ich das immer noch faszinierend. Vielleicht sogar mehr als früher.

Denn heute endet mein Code nicht bei einer Berechnung auf einem Bildschirm oder einer Datei, die irgendwo gespeichert wird.

Er ist Teil einer Plattform, mit der echte Menschen echte Fahrten buchen und durchführen.

Und wenn dann tatsächlich ein Taxi fährt, weil viele tausend Zeilen Code im richtigen Moment das Richtige tun, ist das schon ein ziemlich gutes Gefühl.

Die nächsten Wochen werden zeigen, wie viel von dieser Arbeit nun Schritt für Schritt bei unseren Fahrgästen und Drivern ankommt.

Ich freue mich darauf. Auf die neuen Apps. Auf die PWA 2.0. Auf die kleine Weihnachtsüberraschung.

Und selbstverständlich auf die nächsten Rückmeldungen unserer Testerinnen.

Wobei ich zugeben muss: Gegen gelegentliche Nachrichten mit dem Inhalt „Alles funktioniert“ hätte ich inzwischen auch nichts einzuwenden.

Natürlich könnte ich jetzt behaupten, dass alles perfekt funktioniert, sämtliche Veröffentlichungstermine in Stein gemeißelt sind und Bugs bei FLINTAXI grundsätzlich ausgeschlossen sind.

Aber ich bin Softwareentwickler.

Kein Science-Fiction-Autor.

FLINTAXI – sicher. fair. gemeinsam unterwegs.

Und unter der Haube: PHP, Vue, Swift, Kotlin, über 40 Jahre Erfahrung und gelegentlich ein sehr gepflegtes Fluchen.