Hands-on CTO bei Livable Places

Bei Livable Places arbeite ich nicht an einer generischen "AI-first"-Story, sondern an einem realen Delivery-System für ein PropTech-Produkt mit echter Betriebsverantwortung. Das umfasst gleichzeitig Monorepo-Produktentwicklung, verteilte Score- und Daten-Workflows, self-hosted Plattformbetrieb, Geo-/Census-Services und die evidenzgetriebene Vorbereitung einer neuen Office-Risk-Produktlinie.

Die Produktthese ist größer als ein Score-Dashboard: gesellschaftliche Nachfrage nach Immobiliennutzungen auf Standortebene messbar und vergleichbar machen. Die operative Logik ist Demand -> Supply -> Property, damit Finanzierung, Ankauf, ESG und Portfolioentscheidungen auf nachvollziehbarere Signale zugreifen können.

Mein Hebel liegt darin, Produktlogik, Datenpipelines, AI/ML-Research, Geo-Services, Queue-Orchestrierung und Plattformbetrieb nicht als getrennte Baustellen zu behandeln. Monorepo, Worker, Auth, Observability, GitOps-nahe Deployments, Backups und Runbooks bilden zusammen ein System, das entwickelt, ausgeliefert und betrieben werden kann.

Die AI-/ML-Arbeit bleibt dabei bewusst evidenzgebunden. Office-Risk-Fingerprinting, PCA, k-Means, Location Absorption Score, Benchmarking und Feature Ablation werden als Charakterisierung und Screening eingesetzt, bis Target-Qualität, Residualisierung und Cross-City-Stabilität stärkere Aussagen erlauben.

• Aufbau und Weiterentwicklung eines pnpm/Turborepo-Monorepos für Web-App, Services, Worker und Betriebswerkzeuge
• Hands-on Arbeit an verteilten Score- und Daten-Workflows mit Bun, BullMQ, FlowProducer, QueueEvents und Redis
• Nutzung von Redis für Locking, Pub/Sub und Job-Completion-Signale statt fragiler Glue-Logik
• Aufbau authentifizierter asynchroner Report-Export-Pfade mit Service-Auth-Guards, gemeinsamem Export-Domain-Modell und XLSX-Generierung
• Plattformverantwortung für self-hosted Bare-Metal-Infrastruktur mit Docker Swarm, Traefik, Authentik, Ansible-Bootstrap, Docker Secrets, restic Backups, WireGuard und Observability-Stack
• IaC/GitOps-artige GitHub-Workflow-Pfade für Build, Release, Deployment, Rollback, Scaling, Backup, Restore-Smoke-Tests, Maintenance und Self-Healing
• Fachliche und architektonische Steuerung der Geo-/Census-Services rund um Kotlin, Spring Boot, PostGIS, OpenAPI, FastAPI, Valhalla, OSM und externe POI-Importe
• Vorbereitung einer neuen Office-Risk-Produktlinie mit evidenzgetriebener Produkt- und Delivery-Logik
• Design und kritische Prüfung von ML-Workflows rund um PCA, k-Means-Clustering, LAS-Kalibrierung, Benchmark-Matrizen, Target-Qualität, Residualisierung und Feature Ablation
• Nutzung von Multi-Agent-Research-Workflows, lokalen Agent Skills und plugin-artiger Skill-Entwicklung als Teil der Produkt-Evidence-Layer, nicht nur als Entwicklerkomfort
• Übersetzung von Strategie in sichtbare Goals, Scopes, Work Items, Development Boards, Releases, Demos und kundennahe Feedback-Loops
• Aufbau von Demo- und Kampagnenmesspfaden mit anonymem Zugang, UTM-Tracking, Event Analytics und Conversion-Funnel-Denken
• Aufbau interner Planungs- und Reporting-Werkzeuge mit Next.js, React, SQLite, Zod und lokalisierten Produktoberflächen

• Delivery als System: Monorepo, Plattform, Queues, Geo-Services und Produktarbeit werden nicht getrennt optimiert
• Decision Quality statt Dashboard-Output: Produktarbeit wird daran gemessen, ob sie bessere Finanzierungs-, Ankaufs-, ESG- oder Portfolioentscheidungen ermöglicht
• Infrastructure as Code: Plattformzustand, Auth-Baselines, Stack-Definitionen, Secrets, Backups und Operations sind kodifiziert und wiederholbar
• Operability by design: Logs, Metrics, Traces, Alerts und Auth sind Teil des Produkts, nicht Spätfolgen
• Verteilte Orchestrierung mit expliziten Abhängigkeiten, Locking und Beobachtbarkeit statt stillen Hintergrundjobs
• AI-first dort, wo es trägt: Agents, LLM-Tooling und Research-Automation verbessern Evidence-Qualität und Delivery-Speed, aber Claims bleiben an Daten gebunden
• ML mit Evidence Gates: fingerprinten, benchmarken, kalibrieren, residualisieren, ablatieren und erst dann Predictive Value behaupten
• Geo-/Datenprodukte als Infrastruktur: OSM, Census, POI, Routing und Marktdaten werden als versionierte, beobachtbare Produktabhängigkeiten behandelt
• Sichtbares Operating Model: Strategie, Roadmap, Goals, Scope, Work Items, Board, Release, Demo und Kundenfeedback bleiben verbunden
• Kleine Batches und sichtbare Verantwortung statt Roadmap- und Prozesssignale
• Evidence-first Produktarbeit: Beobachtung, Hypothese, Experiment, dann Skalierung