Availably
iPhone-App für zwei Personen. Jeder setzt von Hand einen Status – Verfügbar, Beschäftigt, Fokus, Ruhe –, auf Wunsch mit Zeitlimit, und sieht ohne Nachfrage, ob der andere gerade ansprechbar ist.
Jonas setzt „Fokus“ für 30 Minuten und tippt „Fertig“. Lea zieht die Ansicht nach unten und holt den neuen Stand vom Server, von allein spätestens nach einer Minute. Keine Nachricht, keine Nachfrage.
Lea gibt den Code von Jonas ein. Bei ihr steht sofort „Ihr seid verbunden.“, bei Jonas wird aus der offenen Einladung ihre Karte. Keine Anfrage, keine Annahme.
Leas „Beschäftigt“ läuft ab, und ihr iPhone springt von selbst auf „Verfügbar“. Das von Jonas rechnet das Ende ebenfalls selbst aus, spätestens 15 Sekunden später. Gesendet wird dafür nichts.
- Art
- Prototyp
- Zeitraum
- Dezember 2025, Umbau September 2026
- Stand
- Prototyp. Alle Muss-Funktionen sind gebaut und im Simulator mit lokalem Server getestet. Der Server ist nicht in Betrieb, auf echten iPhones ist die App noch nicht durchgeklickt.
- Technik
- Swift · SwiftUI · TypeScript · Cloudflare Workers · Cloudflare D1
Availably · Bild 1 von 7

Availably · Bild 2 von 7

Availably · Bild 3 von 7

Availably · Bild 4 von 7

Availably · Bild 5 von 7

Availably · Bild 6 von 7

Availably · Bild 7 von 7

Worum es geht
Ein Versuch, wie wenig eine App zeigen darf, damit sie nützlich bleibt. Erfolg heißt hier wenig Nutzung: kurz hinsehen, genug wissen. Entstanden ist der Prototyp in einer Woche im Dezember 2025, damals mit Apples iCloud-Datenbank. Im September 2026 kam ein eigener kleiner Server dazu, weil ein kostenloses Apple-Konto weder den Abgleich über iCloud noch Push erlaubt. Die App ist nicht im App Store und nicht in TestFlight. Die Referenz steht hier, weil sie zeigt, wie Klartext an ein Produkt herangeht, nicht als fertige App.
Funktionen
- Vier Zustände, auf Wunsch mit Zeitlimit von 15 Minuten bis 2 Stunden, danach wieder „Verfügbar“
- Koppeln über einen sechsstelligen Code oder einen Link; die Einladung gilt 24 Stunden und nur einmal
- Teilen mit einem Tipp pausieren; der Partner sieht dann „Pausiert“
- Leise Mitteilungen bei einem Statuswechsel, ohne Push-Dienst: iOS entscheidet, wann die App nachsieht
- Auf Wunsch die Ortszeit des Partners; übertragen wird nur die Zeitzone, kein Standort
- Kein Standort, kein „zuletzt online“, keine Historie, kein Chat
Technische Entscheidungen
- Eigener kleiner Server: ein Cloudflare Worker mit D1. Mit einem kostenlosen Apple-Konto gibt es weder iCloud-Abgleich noch Push, deshalb wurde die Regel „ohne eigenes Backend“ bewusst gebrochen
- Der Server kennt je Gerät nur den aktuellen Stand, keine Historie. Gerätetoken und IP-Adressen liegen dort nur als Hash
- Vor dem ersten Verbinden spricht die App mit keinem Server
- Offline gesetzter Status wartet in einer Warteschlange; der neueste Wert gewinnt
- Entscheidungsregel aus dem Produktdokument: Macht das die App ruhiger oder lauter? Was lauter macht, wird nicht gebaut
Erkenntnisse
- Ein Produktdokument, das Nicht-Ziele nennt, spart mehr Arbeit als eine Funktionsliste
Ein ähnliches Vorhaben? Eine kurze E-Mail genügt, das erste Gespräch ist kostenlos und unverbindlich.





