Es gibt eine besondere Art von Druck, wenn man die “Klebeschicht” eines Systems verantwortet, das von Millionen Menschen genutzt wird.
Nicht den Druck eines nahenden Deadlines — damit lässt sich umgehen. Ich meine den stillen Druck: das Wissen, dass jede Architekturentscheidung, die man heute trifft, sich entweder sauber in die Zukunft zusammensetzt oder eine technische Schuld erzeugt, die jeden Entwickler, der den Code in den nächsten Jahren anfasst, ausbremsen wird. Das konsistent richtig hinzubekommen — über Teams und konkurrierende Produktprioritäten hinweg — das ist das eigentliche Handwerk der Software-Architektur.
In diesem Bereich arbeite ich seit dem größten Teil meiner Karriere.
Die Enterprise-Jahre
Seit 2017 entwickle und leite ich Engineering über den gesamten Software-Lebenszyklus hinweg — von macOS-Desktop-Tools bei appsolute (MAMP/MAMP PRO) über hochsichere Health-Tech-Plattformen bei Vivy GmbH, einem Allianz-Startup, wo meine Arbeit am MVP direkt dazu beitrug, dass das Unternehmen seine letzte Investmenttranche sicherte. Zuletzt war ich leitender Ingenieur des Core Horizontal Teams bei Bedrock Streaming GmbH in Köln — ein Team, das für die nahtlose Integration von Video-, Audio- und Live-Inhalten auf einer der größten europäischen Streaming-Plattformen verantwortlich ist: zunächst allein für RTL+ in Deutschland, später auch für Videoland in den Niederlanden, M6 in Frankreich und RTL+ in Ungarn.
Diese letzte Rolle hat mein Denken über Systeme geprägt. Das Core-Team ist kein Produktteam. Es liefert nicht zwingend Features, die für Endnutzer sichtbar sind. Es liefert hauptsächlich die unsichtbare Infrastruktur, die Features erst möglich macht: die Architekturverträge zwischen vertikalen Squads, die gemeinsamen Frameworks, das Snapshot-Testing-Framework, das ich gebaut und auf alle internen Entwickler ausgerollt habe, die technischen RFCs, die langfristige Code-Qualität davor bewahren, kurzfristiger Velocity geopfert zu werden. Wenn dieses Fundament stabil ist, bewegen sich Produktteams schnell. Wenn nicht, verlangsamen sie sich — und niemand kann leicht erklären, warum.
Außerdem bin ich Mitglied der AI-Champions-Community des Unternehmens, wo ich die strategische Transformation zu einer AI-First-Engineering-Kultur vorantreibe — mit Fokus auf LLM-Integration und interne Entwickler-Agent-Tooling.
Warum ich auch eigene Software baue
Binaries Lab existiert aus zwei Gründen.
Der erste ist das Handwerk. Enterprise-Arbeit ist tief befriedigend, aber sie bewegt sich in Enterprise-Geschwindigkeit. Eigene Produkte zu bauen und zu veröffentlichen — von der Idee bis zum App Store, mit allem, was dazugehört: vom Swift-Code über das Go-Backend bis zur IAP-Validierung und der Marketingseite — verdichtet den gesamten Lebenszyklus auf wenige Wochen. Das hält die Fähigkeiten scharf und die Perspektive ehrlich.
Der zweite Grund ist Beweis. Transcriber, Migrate und e.Vernetzt sind keine Nebenprojekte — ganz zu schweigen von Gratehatch und ClockFeed. Sie sind das Ergebnis der Anwendung derselben Architekturstandards, die ich im großen Maßstab einsetze — CLEAN Architecture, SOLID-Prinzipien, modulares Design, Datenschutz als Grundprinzip — auf Produkte, für die ich Ende-zu-Ende verantwortlich bin. Jede Entscheidung hat Konsequenzen, mit denen ich direkt lebe. Diese Verantwortlichkeit erzeugt bessere Software.
Was diese Kombination in der Praxis bedeutet
Die iSAQB-zertifizierte Software-Architektur gibt einem das Vokabular und die Frameworks, um über Systeme nachzudenken. Ein Jahrzehnt professioneller Erfahrung in iOS, macOS, Angular, Kotlin, Go, AWS und Full-Stack-Entwicklung gibt einem die Werkzeuge. Was Enterprise-Leadership lehrt — Recruiting-Zyklen leiten, Performance-Reviews durchführen, Stakeholder auf Vorstandsebene managen, als Security Champion Threat Modeling und Risikoabschätzung verantworten — ist, dass die schwierigsten Probleme in der Software-Entwicklung selten rein technischer Natur sind.
Teams, die großartige Produkte liefern, verstehen beide Seiten. Sie haben Ingenieure, die rigoros über Architektur nachdenken und dieses Denken klar an Menschen kommunizieren können, denen geschäftliche Ergebnisse wichtig sind. Sie haben Führungspersönlichkeiten, die Standards setzen, ohne zum Flaschenhals zu werden.
Auf diese Verbindung habe ich mich spezialisiert.
Worum es in diesem Blog geht
Hier schreibe ich über reale Engineering-Probleme — die Art, die auftaucht, wenn man versucht, architektonische Integrität über eine große Codebasis hinweg zu erhalten, KI-Tooling in einen bestehenden Entwicklungs-Workflow zu integrieren, oder eine produktionsreife iOS-App zu bauen, die die Menschen respektiert, die sie nutzen.
Kein Füllmaterial. Kein Trend-Hopping. Engineering, das seine Komplexität verdient.
Wenn etwas davon mit einer Herausforderung resoniert, an der dein Team arbeitet, bin ich immer offen für ein Gespräch. Erreichbar unter marcelo@binarieslab.com — der Kaffee geht auf mich.