Das System unterscheidet grundlegend zwischen zwei verschiedenen Nutzungsszenarien, die technisch völlig unterschiedlich implementiert sind — je nach Anforderung an Konnektivität, Skalierung und Datenschutz.

Das Herzstück für Konferenzen, Führungen und Events. Ein Speaker spricht in sein Gerät — der Text wird übersetzt und über einen Supabase Realtime Broadcast Channel an beliebig viele Listener gesendet. Jeder Listener empfängt den Text in seiner individuell gewählten Sprache und kann ihn sich vorlesen lassen.

Um in jeder Umgebung — von der Konferenzhalle bis zum Kreuzfahrtschiff ohne Internetverbindung — zuverlässig zu funktionieren, verfügt das System über vier verschiedene Verbindungsmodi. Der passende Modus wird automatisch oder manuell je nach Einsatzszenario gewählt.

Die Modi sind nach Konnektivitätsanforderung und Latenz gestaffelt — von Cloud-basierter Infrastruktur bis hin zu vollständig autonomen Peer-to-Peer-Verbindungen ohne jegliche Netzwerkabhängigkeit.

Das System ist darauf ausgelegt, niemals vollständig auszufallen. Wenn ein Dienst — etwa Google oder Azure — nicht erreichbar ist, ein API-Limit überschritten wird oder ein Netzwerkfehler auftritt, greift automatisch der nächste Dienst in der vordefinierten Kette. Dieser Mechanismus funktioniert transparent für den Endnutzer.

Es gibt drei unabhängige Fallback-Ketten: eine für Spracherkennung (STT), eine für Übersetzung und eine für Sprachausgabe (TTS). Jede Kette ist nach Qualität und Kosten priorisiert — die beste und günstigste Option steht an erster Stelle, der robusteste Offline-Fallback am Ende.

Die Spracherkennung ist die komplexeste Fallback-Kette, da sie stark vom Betriebssystem und Browser abhängt. iOS blockiert beispielsweise die Web Speech API, was eigene Lösungswege erfordert. Die Kette priorisiert je nach Kontext Datenschutz, Qualität oder Verfügbarkeit.

Die Übersetzungskette ist nach Kosten und Verfügbarkeit optimiert. Der primäre Dienst ist Azure Translator, der mit einem großzügigen Gratis-Kontingent für die meisten Anwendungsfälle ausreicht. Die nachgelagerten Dienste greifen automatisch, wenn Limits erreicht werden.

Fintutto verfolgt die Philosophie der Markt-Spezialisierung. Anstatt einer einzigen monolithischen App gibt es 19 spezialisierte Vercel-Projekte, die auf verschiedene Zielgruppen und deren spezifische Anforderungen zugeschnitten sind. Jedes Segment hat eigene Tier-Definitionen mit spezifischen Limits, konfiguriert in src/lib/tiers.ts.

Die drei Serverless-Edge-Functions auf Vercel fungieren als datenschutzkonformer Mittelsmann zwischen den Browser-Clients und den externen KI-Diensten. Clients kommunizieren niemals direkt mit Azure oder Google — alle API-Schlüssel bleiben serverseitig verborgen.

Der vollständige Datenfluss von Spracheingabe bis Sprachwiedergabe durchläuft alle drei Fallback-Ketten sequenziell. Jede Stufe ist unabhängig resilient — ein Ausfall in der STT-Kette beeinflusst nicht die Verfügbarkeit der TTS-Kette. Das Gesamtsystem ist damit deutlich robuster als jede monolithische Lösung.

Diese realen Erfahrungen aus dem Betrieb zeigen: Die mehrstufigen Fallback-Ketten sind kein theoretisches Design-Pattern, sondern eine praktische Notwendigkeit. Die Architekturentscheidung, niemals einen Single Point of Failure zu tolerieren, hat sich in kritischen Momenten mehrfach bewährt.