Vom Prototyp zum Produkt: TacticRemotes Entwicklungsreise

Tactic Remote begann als eine Frage Anfang Januar 2026: Was waere, wenn man eine laufende Claude Code-Sitzung vom Smartphone aus ueberpruefen koennte? Diese Frage wurde an einem Wochenende zu einem Prototyp, innerhalb von zwei Wochen zu einem nutzbaren Tool und zu einem Produkt mit 13 abgeschlossenen Meilensteinen, bevor wir unser erstes versioniertes Release veroeffentlichten. Dies ist die Geschichte dieses Entwicklungsbogens — was wir gebaut haben, was wir verworfen haben und was wir daraus gelernt haben, schnell zu liefern, ohne Kaputtes auszuliefern.

Der Wochenend-Prototyp (Anfang Januar 2026)

Die erste Version von Tactic Remote umfasste etwa 200 Zeilen Code. Ein Shell-Skript startete Claude Code in einer tmux-Sitzung, ein Python-Flask-Server stellte einen Endpunkt bereit, der tmux capture-pane ausfuehrte und die Ausgabe als Klartext zurueckgab, und eine einfache iOS-App pollte diesen Endpunkt alle 2 Sekunden und zeigte das Ergebnis in einer Monospace-Textansicht an.

Es war haesslich und langsam. Das Polling-Modell bedeutete 2 Sekunden Latenz bei jedem Update. Die Klartext-Erfassung verlor jegliche Formatierung. Es gab keine Authentifizierung — jeder im selben Wi-Fi-Netzwerk konnte Ihr Terminal lesen. Aber es bewies das Konzept: Man konnte eine KI-Coding-Sitzung vom Smartphone-Bildschirm aus sinnvoll verfolgen.

Dieser Prototyp ueberlebte etwa 4 Tage, bevor wir mit dem Neuaufbau begannen.

Meilenstein-Architektur

Wir uebernahmen ein meilensteinbasiertes Entwicklungsmodell anstelle von Kalendersprints. Jeder Meilenstein hatte ein spezifisches technisches Ziel, eine Definition of Done und keine feste Frist. Dies erlaubte uns, zu veroeffentlichen, wenn etwas fertig war, anstatt wenn ein Sprint endete. In der Praxis dauerten Meilensteine durchschnittlich 4-5 Tage, wobei einige nur 2 Tage und einer fast zwei Wochen benoetigten.

Hier ist der komprimierte Verlauf:

Meilensteine 1-3: Fundament. Flask durch einen Swift-nativen eingebetteten Server ersetzen. WebSocket fuer Echtzeit-Streaming anstelle von HTTP-Polling etablieren. Token-basierte Authentifizierung implementieren. Nach Meilenstein 3 hatten wir ein funktionierendes System, bei dem das iPhone Terminal-Updates innerhalb von 200ms empfing und unautorisierter Zugriff blockiert wurde.

Meilensteine 4-5: Sitzungsverwaltung. Unterstuetzung mehrerer gleichzeitiger tmux-Sitzungen. Aufbau des Sitzungs-Lebenszyklus (Erstellen, Ueberwachen, Leerlauf, Abschluss, Bereinigung). Sitzungspersistenz ueber Neustarts der Begleit-App hinweg durch erneutes Verbinden mit bestehenden tmux-Sitzungen beim Start. Dies war der Punkt, an dem Tactic Remote aufhoerte, eine Demo zu sein, und fuer echte Arbeit nutzbar wurde.

Meilensteine 6-7: Mensch in der Schleife. Integration mit dem hook-System von Claude Code zum Abfangen von Genehmigungsanfragen. Aufbau der Genehmigungs-UI auf iOS — anzeigen, was die KI tun moechte, den relevanten Kontext zeigen und Genehmigen/Ablehnen-Aktionen bereitstellen. Push-Benachrichtigungen hinzufuegen, damit Genehmigungen nicht erfordern, dass die App geoeffnet ist. Diese beiden Meilensteine waren der Wendepunkt. Davor war Tactic Remote ein Terminal-Viewer. Danach war es eine Steuerungsoberflaeche.

Meilensteine 8-9: Verbindungsrobustheit. Umgang mit Wi-Fi-zu-Mobilfunk-Uebergaengen. Automatische Wiederverbindung mit exponentiellem Backoff implementieren. Verbindungsqualitaetsindikatoren hinzufuegen. QR-Code-Schnellverbindungsablauf erstellen, um manuelle IP- und Token-Eingabe zu eliminieren. Meilenstein 9 war der schwierigste einzelne Meilenstein — Netzwerk-Randfaelle auf iOS sind zahlreich und schlecht dokumentiert.

Meilensteine 10-11: Cloudflare Tunnel. cloudflared als verwalteten Kindprozess integrieren. Dual-Modus-Verbindungsarchitektur aufbauen (lokal und Tunnel). Tunnel-Gesundheitsueberwachung, automatischen Neustart und elegantes Fallback handhaben. Tunnel-URL zur QR-Code-Generierung hinzufuegen.

Meilensteine 12-13: Produktionsreife. Lokalisierung (7 Sprachen). Mac-Schlafverhinderung. Menueleisten-UI-Feinschliff. Absturzberichte und Diagnose. Leistungsoptimierung zur Reduzierung des Speicherverbrauchs von etwa 60 MB auf unter 25 MB im Leerlauf. Abschliessende Sicherheitsueberpruefung der Authentifizierungs- und Transportschichten.

Wichtige technische Entscheidungen

Mehrere waehrend der Entwicklung getroffene Entscheidungen definierten den Charakter des Produkts:

tmux statt benutzerdefinierter PTY-Verwaltung

Wir haben dies waehrend Meilenstein 1 ausfuehrlich diskutiert. Benutzerdefinierte PTY-Verwaltung wuerde uns feinere Kontrolle ueber die Terminal-Erfassung geben und die tmux-Abhaengigkeit eliminieren. Aber es wuerde auch bedeuten, Sitzungspersistenz, Terminal-Emulation und Prozess-Lebenszyklus-Management neu zu implementieren — Probleme, die tmux seit 15 Jahren geloest hat. Wir entschieden uns, auf diesem Fundament aufzubauen, anstatt es neu zu errichten.

WebSocket statt Server-Sent Events

Fuer Echtzeit-Streaming funktionieren beide Protokolle. Wir waehlten WebSocket, weil wir bidirektionale Kommunikation benoetigten — das iPhone sendet Befehle und Genehmigungen an den Mac zurueck, empfaengt nicht nur Terminal-Ausgabe. SSE haette einen separaten Kanal fuer die Upstream-Kommunikation erfordert und damit Komplexitaet hinzugefuegt.

Eingebetteter Server statt eigenstaendigem Daemon

Ein eigenstaendiger Daemon (verwaltet durch launchd) waere aus macOS-Architekturperspektive "korrekter" gewesen. Aber er haette die Installationskomplexitaet verdoppelt und eine Klasse von "der Server laeuft, aber die App nicht"-Fehlern erzeugt. Den Server in die Menueleisten-App einzubetten bedeutet: eine Sache installieren, eine Sache ausfuehren, eine Sache beenden.

Statisches Token statt OAuth/sitzungsbasierter Authentifizierung

Das Bedrohungsmodell von Tactic Remote ist geradlinig: unautorisierten Zugriff aus dem Netzwerk verhindern. Ein kryptografisch zufaelliges 256-Bit-Token, gespeichert im Schluesselbund, erreicht dies ohne die Komplexitaet von Token-Erneuerung, Sitzungsablauf oder Login-Ablaeufen. Fuer Enterprise-Anwendungsfaelle, die benutzerbasierte Authentifizierung erfordern, empfehlen wir Cloudflare Access als externe Schicht.

tmux-Polling statt Dateisystem-Ueberwachung

Wir pollen tmux capture-pane in 200ms-Intervallen anstatt Dateisystem-Benachrichtigungs-APIs (kqueue/FSEvents) auf einem PTY zu verwenden. Das klingt unelegant, aber der Capture-Befehl von tmux ist extrem schnell (Sub-Millisekunde), und Dateisystem-Ueberwachung auf PTY-Geraeten erwies sich in unseren Tests ueber macOS-Versionen hinweg als unzuverlaessig. Der Polling-Ansatz war auf macOS 13, 14 und 15 absolut zuverlaessig.

Was wir verworfen haben

Nicht alles hat ueberlebt. Einige bemerkenswerte Streichungen:

Ein webbasierter Client. Wir haben waehrend Meilenstein 6 eine responsive Web-Oberflaeche gebaut, die in jedem Browser lief. Sie funktionierte, aber die Erfahrung war deutlich schlechter als eine native App — keine Push-Benachrichtigungen, keine Hintergrund-Wiederverbindung, kein haptisches Feedback bei Genehmigungen. Wir stellten sie zurueck, um uns auf das native iOS-Erlebnis zu konzentrieren.

Terminal-Farben und -Formatierung. Fruehe Versionen versuchten, ANSI-Farbcodes beizubehalten und auf dem iPhone zu rendern. Das Rendering war inkonsistent und fuegte dem Streaming-Protokoll erhebliche Komplexitaet hinzu. Wir wechselten zu einem vereinfachten Renderingmodell, das die Struktur bewahrt, ohne pixelgenaue Terminal-Emulation anzustreben. Volle ANSI-Unterstuetzung steht weiterhin auf der Roadmap.

Automatische Aufgabenvorschlaege. Wir haben eine Funktion prototypisiert, bei der Tactic Remote Claude Code-Aufgaben basierend auf Ihrer juengsten git-Aktivitaet vorschlagen wuerde. Es war technisch interessant, fuehlte sich aber anmassend an — Entwickler wissen, woran sie arbeiten wollen. Wir entfernten es, bevor es ein Beta-Tester sah.

Der Uebergang zur Versionierung

Nach Meilenstein 13 wechselten wir von meilensteinbasiertem Tracking zu semantischer Versionierung. Das erste versionierte Release war 1.2.0 (nicht 1.0.0, da wir waehrend geschlossener Tests interne Builds mit den Nummern 1.0 und 1.1 hatten, um die wir keine Verwirrung stiften wollten).

Der Verlauf seitdem: 1.2.0, 1.3.0, 1.4.0, 1.4.2 und 1.5.0-beta.1. Jede Version entspricht einem klaren Satz von benutzerseitigen Aenderungen, dokumentiert in unserem Changelog. Das Meilenstein-System hat uns waehrend des schnellen Prototypings gut gedient, aber semantische Versionierung kommuniziert klarer an Benutzer, die das Upgrade-Risiko einschaetzen muessen.

Was wir gelernt haben

Liefere das kleinste nuetzliche Ding. Der Wochenend-Prototyp war nach jedem Ingenieursstandard peinlich, aber er beantwortete die einzige Frage, die zahlte: Hilft es tatsaechlich, Claude Code vom Telefon aus zu ueberwachen? Jeder folgende Meilenstein war eine inkrementelle Antwort auf "Was ist die naechste nuetzlichste Verbesserung?"

Netzwerke sind der schwierige Teil. Wir verbrachten mehr Zeit mit Verbindungszuverlaessigkeit als mit jedem anderen Aspekt des Produkts. Wi-Fi-zu-Mobilfunk-Uebergaenge, WebSocket-Wiederverbindung nach dem Ruhezustand, Cloudflare Tunnel-Gesundheitsueberwachung — jedes davon verbrauchte einen kompletten Meilenstein. Die eigentliche Terminal-Erfassung und Sitzungsverwaltung war vergleichsweise unkompliziert.

Abhaengigkeiten sollten langweilig sein. tmux, cloudflared, Schluesselbund, IOKit — die Technologien, von denen Tactic Remote abhaengt, sind stabil und gut dokumentiert. Jedes Mal, wenn wir in Betracht zogen, etwas Neueres oder Innovativeres zu uebernehmen, fragten wir, ob die bestehende langweilige Option gut genug war. Das war sie meistens.

Meilensteinbasierte Entwicklung funktioniert fuer kleine Teams. Ohne den Overhead von Sprint-Planung, Stand-ups und Velocity-Tracking bewegten wir uns schneller. Jeder Meilenstein hatte eine klare Ziellinie, und wir konnten den Umfang in Echtzeit basierend auf dem, was wir waehrend der Implementierung lernten, anpassen. Dieses Modell bricht bei groesseren Teamgroessen zusammen, aber fuer unsere fruehe Entwicklung war es richtig.

Zeitleisten-Zusammenfassung

Acht Wochen von einer Idee zu einer offenen Beta. Nicht weil wir Abkuerzungen genommen haben, sondern weil wir den Umfang konsequent reduzierten und auf bewaehrten Grundlagen aufbauten.

Einen detaillierten Blick auf jedes versionierte Release finden Sie in unserem Changelog.