MeetCal: Warum ich Calendly in Telegram gebaut habe

Es gibt einen bestimmten Moment, der mich gebrochen hat.

Jemand schreibt mir in Telegram: “Können wir diese Woche kurz telefonieren?” Ich antworte: “Klar, hier ist mein Calendly.” Er klickt drauf, der Browser öffnet sich, lädt langsam auf dem Handy, vielleicht wird er gebeten, ein Konto zu erstellen, vielleicht bricht die Verbindung ab. Fünf Minuten später ist er wieder in Telegram und bestätigt den Slot. Das gesamte Gespräch ist nun auf zwei Apps und einen Browser-Tab verteilt.

Das passiert mir dutzende Male pro Woche. Ich habe MeetCal gebaut, weil ich diese Aufteilung satt hatte.

Das Problem mit Calendly in Telegram

Calendly ist okay. Es tut, was es verspricht. Aber die Produktannahme, die darin eingebaut ist, lautet, dass Scheduling eine eigenständige Aufgabe ist — etwas, zu dem man bewusst navigiert, wie beim Buchen eines Fluges.

Telegram-Scheduling funktioniert nicht so. “Können wir kurz reden?” ist ein beiläufiger Satz mitten in einem Gespräch über etwas anderes. Wenn du in diesem Moment einen Calendly-Link einwirfst, bittest du die andere Person, innezuhalten, den Kontext zu wechseln, einen mehrstufigen Ablauf in einer fremden Oberfläche abzuschließen und dann zurückzukommen. Oft ist der Schwung weg, bis sie wiederkommen.

Die Reibung sind nicht nur die zusätzlichen Schritte. Es ist der Bruch im Konversationsfaden. Der Kontextwechsel signalisiert “das ist jetzt eine formelle Scheduling-Aufgabe” — dabei wolltest du nur eine freie Stunde finden.

Was MeetCal macht

Der Host richtet seine Verfügbarkeit einmal im Bot ein. Von da an kannst du deine Buchungskarte direkt teilen — tippe @MeetCalBot in jeden Telegram-Chat, und er fügt eine ansprechende Vorschaukarte direkt in das Gespräch ein. Der Gast tippt darauf, eine Mini-App öffnet sich innerhalb von Telegram, er wählt einen Slot — fertig. Kein Browser, keine E-Mail, keine Kontoanmeldung.

Bestätigung und Erinnerungen kommen als Telegram-Nachrichten. Die gesamte Schleife — vorschlagen, buchen, bestätigen, erinnern — bleibt an einem Ort.

Das Inline-Sharing ist wichtiger, als es klingt. Es bedeutet, dass du den Chat nicht verlassen musst, um deinen Kalender zu teilen. Du tippst einfach den Bot-Namen mitten in eine Nachricht und die Karte erscheint. Der Empfänger sieht keinen rohen Link.

Das schwierigste technische Problem

Die App ist React + Vite. Telegram Mini Apps geben dir Zugriff auf WebApp.MainButton — den Button unten auf dem Bildschirm, der über deinem Inhalt schwebt. Er ist der primäre Action-Button in fast jeder Mini App.

Die API ist imperativ: MainButton.show(), MainButton.hide(), MainButton.setText('Slot buchen'), MainButton.showProgress(). Du rufst Methoden auf, Telegram kümmert sich um das Rendering.

React ist deklarativ. Du beschreibst den Zustand, React entscheidet, was gerendert wird.

Dieser Mismatch hat einen konkreten Bug verursacht: Jedes Mal, wenn sich der Komponentenzustand änderte — selbst Zustand ohne Bezug zum Button — flackerte der Button. Er verschwand für einen einzelnen Frame, bevor er mit dem richtigen Text wieder auftauchte. Auf einem Handybildschirm sieht das kaputt aus.

Die Ursache war, dass ich einen einzigen useEffect hatte, der den gesamten button-bezogenen Zustand beobachtete und bei jedem Render show() und dann setText() aufrief. Das kurze hide() zwischen den Renders war sichtbar.

Die Lösung war, den Hook in separate Effects mit separaten Dependency Arrays aufzuteilen. Ein Effect läuft nur beim Mount, um den Button zu initialisieren und den Click Handler anzuhängen. Ein separater Effect läuft nur, wenn der Button-Text oder der Ladezustand sich ändert — er ruft nie hide() auf, nur setText() und showProgress(). Die Sichtbarkeit wird unabhängig mit einem eigenen Effect gesteuert, der nur feuert, wenn sich das Visible-Flag ändert.

Drei Effects statt einem. Jeder mit einem minimalen Dependency Array. Das Flackern hörte auf.

Es ist eine Kleinigkeit, aber es hat einen halben Tag gedauert, sie zu isolieren — und es ist genau die Art von Sache, die entscheidet, ob sich eine App nativ oder wackelig anfühlt.

Was die Mini-App-Plattform richtig und falsch macht

Richtig: Distribution ist kostenlos. Wenn der Bot funktioniert, finden ihn die Leute über die Inline-Suche. Kein App-Store-Review, kein Installationsschritt. Die Telegram-UI-Primitiven — MainButton, BackButton, Haptic Feedback, das native Share Sheet — reichen aus, um etwas zu bauen, das sich wie eine echte App anfühlt.

Falsch: Das Debugging ist mühsam. Fehler in der Mini App tauchen auf Weisen auf, die schwer zu verfolgen sind. Das WebApp-Objekt verhält sich auf verschiedenen Telegram-Clients (Desktop, iOS, Android) unterschiedlich, auf Weisen, die nicht dokumentiert sind. Ich habe einen Tag damit verbracht, ein Layout-Problem zu debuggen, das nur auf Android auftrat, weil die Viewport-Höhen-Berechnung auf einer Plattform die Tastatur einschließt und auf der anderen nicht.

Die Plattform ist jung. Das spürt man. Aber die Beschränkungen treiben dich zu einfacheren UIs — was meistens eine gute Sache ist.

Aktueller Stand

MeetCal hat drei Stufen: kostenlos (einfache Buchung, begrenzte Slots pro Monat), Starter und Pro. Bezahlte Stufen schalten wiederkehrende Verfügbarkeit, benutzerdefinierte Puffer zwischen Meetings und ein paar andere Dinge frei, nach denen Power-User fragen.

Die Monetarisierung läuft über Telegram Stars — Telegrams In-App-Währung. Das passt gut, weil Nutzer die Plattform nie verlassen müssen, um zu bezahlen. Die Konversion von kostenlos zu bezahlt ist noch früh, aber die Leute, die zahlen, nutzen das Produkt ernsthaft.

Was ich anders machen würde

Ich würde weniger Zeit auf die Politur des Buchungsablaufs in der ersten Version verwenden und mehr auf das Host-Onboarding. Der Moment, in dem jemand seine Verfügbarkeit zum ersten Mal einrichtet, ist wo die meisten Leute abspringen. Der Ablauf funktioniert, ist aber nicht offensichtlich genug. Ich habe immer wieder die Gäste-Erfahrung optimiert — die Person, die bucht — während die Host-Erfahrung der eigentliche Flaschenhals war.

Außerdem: Ich hätte das Telegram Mini Apps Changelog vor dem Start sorgfältiger gelesen. Zwischen dem Beginn meines Builds und dem Ship gab es API-Änderungen, die das Umschreiben von Teilen des Auth-Layers erforderten. Lektion: Behandle die Plattform als instabil, bis du mindestens eine Version geshippt hast.

Die Kernwette gilt weiterhin. Messaging ist da, wo die Aufmerksamkeit lebt. Scheduling sollte dort auch leben.