Adapter vor Abstraktionen
Besonderheiten der Quellen bleiben in den Stadt-Konnektoren; das übrige System arbeitet mit einer gemeinsamen Darstellung.
Persönliches Engineering-Produkt · produktiv in Betrieb
Schweizer Parkdaten-Plattform
Aus einer fragmentierten Parkplatzsuche entstand findparking.ch: ein öffentliches Produkt, das Live-Verfügbarkeit, historischen Kontext und kurzfristige Prognosen für mehrere Schweizer Städte zusammenführt. Ich habe das gesamte System entworfen, entwickelt und bereitgestellt und betreibe es laufend weiter.
Technische Verantwortung
Ich verantworte den gesamten technischen und produktbezogenen Lebenszyklus.
5Städte heute live
~90Parkhäuser
Seit Sep. 2025historische Beobachtungen
< CHF 10/MonatVPS-Hosting
01 — Entstehung
Ein echtes Problem beim Autofahren, keine Startup-Geschichte.
Bei Fahrten nach Zürich war die Suche nach freien Parkplätzen unnötig fragmentiert. Die Information existierte, doch für den Vergleich mehrerer sinnvoller Parkhäuser mussten einzelne Quellen nacheinander geöffnet werden.
Die erste Produktidee war bewusst einfach: mehrere Parkhäuser gemeinsam zeigen, damit sich die aktuelle Verfügbarkeit sofort vergleichen lässt.
Eine zweite Frage entstand sehr früh. Wenn ich in 30 bis 60 Minuten losfahre, reicht der aktuelle Wert nicht: Wird ein Parkhaus wahrscheinlich voller oder leerer? Dafür musste zuerst eine Historie entstehen, die die Quellseiten nicht bereitstellten.
02 — Produktentwicklung
Zuerst nützlich, dann schrittweise leistungsfähiger.
- 01
Ende 2025 · Tabellen-MVP
Die erste öffentliche Version bestand hauptsächlich aus Verfügbarkeitstabellen. Sie löste das Vergleichsproblem und begann Beobachtungen zu sammeln, ohne auf eine aufwendige Oberfläche zu warten.
- 02
Historie entsteht
Geplante Snapshots verwandelten flüchtige öffentliche Werte in Zeitreihen. Die heutige Produktionshistorie reicht ungefähr bis September 2025 zurück.
- 03
Um Juni 2026 · Prognoseversuche
Zürich diente als erster Entwicklungs- und Testfall für kurzfristige Prognosen; anschliessend wurden mehrere Ansätze systematisch verglichen.
- 04
Mehrstadt-Architektur
Nach Aufbau der gemeinsamen Pipeline konnten neue Städte Speicherung, Auswertung und Darstellung wiederverwenden und nur einen quellenspezifischen Adapter ergänzen.
- 05
Heutiges Produkt
Aus dem Tabellen-MVP wurde eine ausgearbeitete responsive Oberfläche mit vergleichbaren Karten und interaktiver geografischer Karte.
Die Reihenfolge ist entscheidend: Das Produkt war bereits nützlich, während die Datenbasis und experimentelleren Funktionen weiter entstanden.
03 — Architektur
Quellenspezifische Komplexität an der Systemgrenze halten.
Schweizer Städte und Betreiber stellen Parkdaten über unterschiedliche Formate und Endpunkte bereit, darunter XML und JSON. Hinter dem Produkt steht keine einheitliche standardisierte Schweizer Park-API.
Jede Stadt besitzt deshalb einen eigenen Abruf- und Anpassungskonnektor. Nach der Normalisierung in eine gemeinsame interne Darstellung werden PostgreSQL-Speicherung, Prognose und Auswertung, Flask-Anwendung und Oberfläche gemeinsam genutzt.
Produktionsarchitektur
Heterogene öffentliche Quellen
XML · JSON · weitere Endpunkte
↓XML · JSON · weitere Endpunkte
Stadtspezifische Adapter
↓Gemeinsame Darstellung und Validierung
↓Historische Beobachtungen
PostgreSQL auf dem VPS
PostgreSQL auf dem VPS
Prognose und Auswertung
~8 Ansätze · MAE
~8 Ansätze · MAE
Betriebliche Prüfungen
Aktualität · Fehler · Warnungen
Aktualität · Fehler · Warnungen
↓
Python- und Flask-Anwendung
↓Responsive Liste + Leaflet / OpenStreetMap
04 — Datenpipeline
Von der flüchtigen Aktualisierung zur ausgewerteten Prognose.
- 01
Abrufen
Ein Stadt-Konnektor ruft die öffentliche Quelle auf und verarbeitet deren besonderes Format.
- 02
Anpassen
Stadtspezifische Felder und Zustände werden in die gemeinsame interne Struktur übersetzt.
- 03
Validieren und speichern
Nutzbare Beobachtungen werden mit Zeitstempel in PostgreSQL gespeichert, statt den vorherigen Zustand zu überschreiben.
- 04
Prognosen erzeugen
Geplante Aufgaben berechnen kurzfristige Schätzungen, wenn genügend Historie und aktuelle Daten vorhanden sind.
- 05
Auswerten
Prognosen werden mit der später beobachteten Verfügbarkeit verglichen; Modellfehler werden unter anderem mit MAE verfolgt.
- 06
Darstellen und überwachen
Flask liefert die öffentlichen Karten und die Karte; private Statusansichten zeigen Aktualität, Aufgabenstatus und erkannte Probleme.
Konventionelle Cron-Jobs genügen in diesem Massstab: Erfassung ungefähr alle 5 Minuten, Prognoseaufgaben alle 15 Minuten und tägliche Backups. Die unterschiedlichen Takte vermeiden eine Neuberechnung nach jeder Rohbeobachtung.
05 — Produkt- und Technikentscheidungen
Komplexität bewusst steuern.
Historie vor Prognose
Früh gesammelte Snapshots schufen erst die Grundlage für spätere Prognosen, statt eine Funktion auf zu wenig Daten aufzubauen.
Cron vor Orchestrierungsinfrastruktur
Getrennte Zeitpläne bleiben auf einem kleinen Server explizit und leicht betreibbar. Zusätzliche Infrastruktur würde noch keinen proportionalen Nutzen schaffen.
Erkennen statt Selbstheilung behaupten
Die Überwachung trennt Anwendungsfehler von fehlenden, veralteten oder geänderten Quelldaten. Die Behebung erfordert weiterhin Diagnose und gegebenenfalls eine Konnektoranpassung.
06 — Historische Daten
Der fehlende Datensatz musste mit der Zeit entstehen.
Die Produktionsbeobachtungen reichen ungefähr bis September 2025 zurück. Zeilenzahl, Datenbankgrösse und Abfrageleistung werden nicht genannt, weil hier keine verifizierten Werte vorliegen.
Jede gespeicherte Aktualisierung macht Verfügbarkeit zu einer beobachtbaren Zeitreihe statt zu einer wegwerfbaren Zahl. PostgreSQL auf dem VPS unterstützt die Live-Anwendung, historische Vergleiche sowie die Prognose- und Auswertungspipeline.
Der Wert wächst schrittweise. Eine neue Stadt kann erst dann in den gemeinsamen Prognoserahmen aufgenommen werden, wenn eine kompatible öffentliche Quelle eingebunden ist und genügend Historie vorliegt; Architektur kann Daten nicht ersetzen, die ein Betreiber gar nicht veröffentlicht.
Wie Historie das Produkt verändertQuelle zu einem Zeitpunkt
↓Aktuelle Verfügbarkeit
findparking.ch über die Zeit
Aktuelle Verfügbarkeit
+ Vergleich vor einer Stunde
+ Historische Beobachtungen
+ Kurzfristige Schätzungen
+ Prognoseauswertung
07 — Prognoseexperimente
Ansätze vergleichen, bevor ein Sieger feststeht.
Das aktuelle System befindet sich in einer Experimentier- und Auswertungsphase und ist keine fertige Machine-Learning-Plattform. Ungefähr acht Prognoseansätze werden verglichen, statt einen Ansatz vorzeitig als endgültig besten darzustellen.
Prognosen werden gespeichert und später mit der tatsächlich beobachteten Verfügbarkeit verglichen. Das private Betriebsdashboard verfolgt die Leistung mit Kennzahlen wie dem Mean Absolute Error (MAE), damit die Auswahl auf Ergebnissen beruht.
Die öffentliche Oberfläche zeigt derzeit Schätzungen für eine und drei Stunden, sofern aktuelle Daten, bekannte Kapazität und ein aktuelles Modell vorliegen. Sie werden klar als Schätzungen und nicht als Garantien dargestellt.
08 — Heutiges öffentliches Produkt
Eine moderne Oberfläche für Entscheidungen unterwegs.
Nutzende können responsive Parkhauskarten durchsuchen oder zur geografischen Karte wechseln. Die Karten zeigen aktuell freie Plätze und bekannte Kapazität, einen farbigen Verfügbarkeitsstatus, Veränderung und Verfügbarkeit ungefähr eine Stunde zuvor, Datenaktualität und – sofern gültig – kurzfristige Schätzungen.
Die Karte nutzt Leaflet mit OpenStreetMap und zeigt denselben wesentlichen Kontext geografisch. Das heutige Erlebnis ist eine deutliche Weiterentwicklung des Tabellen-MVP und bleibt dennoch auf den praktischen Vergleich fokussiert.
Aktuelle Parkplatzverfügbarkeit und kurzfristige Schätzungen in den unterstützten Schweizer Städten ansehen.
Zu findparking.ch ↗09 — Produktivbetrieb
Mit dem Deployment begann die Zuverlässigkeitsarbeit erst.
Ein passwortgeschütztes internes Dashboard zeigt Erfassungsstatus, Datenaktualität, Prognoseaufgaben, erkannte Probleme und MAE-basierte Modellvergleiche. Die Authentifizierung schützt diese Betriebsansicht; sie ist kein Kontosystem für Nutzende.
Echte Ausfälle geplanter Aufgaben und Probleme mit Quelldaten führten zu Überwachung und Warnungen. Einige Störungen entstehen in der Anwendung, andere wenn ein Betreiber nicht mehr veröffentlicht, veraltete oder unbrauchbare Daten liefert oder seine Quelle ändert. Die Reaktion bleibt pragmatisch: erkennen, untersuchen und anpassen – ohne perfekte Verfügbarkeit oder automatische Reparatur zu behaupten.
10 — Kontinuierliche Verbesserung
Das Produkt nützlich halten und in einem realistischen System lernen.
Zwei parallele Ziele
Die Entwicklung verbessert sowohl das reale Produkt als auch eine glaubwürdige Umgebung für technische Experimente.
Komplexität muss sich lohnen
Ein vollständiges Kontosystem, umfangreiche Benachrichtigungen, Zahlungen und kommerzielle Infrastruktur bleiben bewusst ausserhalb des heutigen Produkts.
Experimente von Produktionsaussagen trennen
Azure und Snowflake werden für praktische Lernerfahrung untersucht und prototypisch integriert; sie sind keine kritischen Produktionsabhängigkeiten.
Kleiner Betrieb ist trotzdem echter Betrieb
Ein bescheidener VPS und Cron schaffen genug reale Verantwortung, um aus Ausfällen zu lernen, ohne unnötige Infrastruktur zu bauen.
11 — Aktueller Stand
Ein öffentliches Produkt mit echten Daten und bewusst begrenztem Umfang.
Der professionelle Wert liegt im vollständigen Lebenszyklus und nicht in kommerzieller Traktion: Idee, Tabellen-MVP, fortlaufende Datensammlung, Prognoseversuche, responsive Oberfläche, Produktivbetrieb, Überwachung, Wartung und Roadmap bilden ein zusammenhängendes Produkt.
Die Website ist öffentlich, doch Nutzergewinnung ist derzeit kein Projektziel. Ich bin der wichtigste regelmässige Nutzer; Freunde und andere Personen mit dem Link verwenden sie gelegentlich. Aussagekräftige MAU-, DAU- oder Traffic-Zahlen liegen nicht vor.
12 — Durchgängige Verantwortung
Ich verantworte den gesamten technischen und produktbezogenen Lebenszyklus.
Ich identifizierte das Problem, definierte und lieferte die erste nützliche Version, entwarf Konnektorgrenze und PostgreSQL-Historie, entwickelte Flask-Anwendung und responsive Oberfläche, führte Prognoseauswertung ein und stellte das Produkt auf einem Linux-VPS bereit.
Ich betreibe es auch: Aufgaben planen, Backups pflegen, Datenaktualität und Modellleistung überwachen, auf Anwendungs- und Quellenausfälle reagieren und entscheiden, welche Verbesserung als Nächstes genügend Wert schafft.
Einordnung: Dies ist ein persönliches Engineering- und Produktprojekt ausserhalb meiner Anstellung. Dahinter stehen kein Kunde, kein unternehmerischer Stakeholder-Prozess, keine Teamführungsbehauptung und keine Geschichte kommerzieller Traktion. Sein Wert ist der direkte Beleg, dass ich ein technisches Produkt von einem persönlichen Problem bis zum Produktivbetrieb und zur laufenden Verbesserung führen kann.
13 — Langfristige Roadmap
Mobile ist die natürliche nächste Produktrichtung – keine heutige Funktion.
Parkplatzverfügbarkeit ist ein mobiler Echtzeit-Anwendungsfall. Eine native App ist eine mögliche spätere Richtung, keine zugesagte Lieferung und keine bereits in Entwicklung befindliche Funktion.
Personalisierte Live-Ansicht
Konten und Favoriten könnten dauerhafte Ansichten für die tatsächlich genutzten Parkhäuser ermöglichen.
Reichhaltigere Benachrichtigungen
Die Beobachtung ausgewählter Parkhäuser könnte Änderungen nutzbarer machen, ohne jede Aktualisierung in eine Meldung zu verwandeln.
Native mobile Erfahrung
Eine für das Telefon entwickelte Anwendung könnte den Vergleich vor und während der Fahrt beschleunigen.
Optionale spätere Geschäftsebene
Zahlungen oder andere kommerzielle Funktionen würden nur erwogen, falls sich das Produkt tatsächlich in diese Richtung entwickelt.