Website, Online-Zahlungen, Telegram-Bot und Web-CRM für Invisible World

Ausgangslage

• Die alte Website wirkte veraltet und war nicht auf Buchungen ausgelegt: gebucht wurde nur ein Datum, die Uhrzeit klärte das Team per Telefon oder Instagram.
• Online-Kartenzahlungen wurden nicht zuverlässig bestätigt – und es fehlte ein Überblick über Buchungen und Zahlungen.
• Ein zweiter Auftritt mit eigenem CMS, aber kein gemeinsamer Blick auf Buchungen und Zahlungen beider Websites.
• Preise ließen sich nur im CMS ändern, und das Team hatte keine einfache Übersicht über den Tag.
• Personenbezogene Daten der Gäste müssen in Belarus bleiben – ausländisches Cloud-Hosting kam für den Produktivbetrieb nicht in Frage.

Was ich gebaut habe

1. Website mit Fokus auf Buchungen

• Statische Astro-Website: schnell, günstig im Betrieb, läuft auf Shared Hosting – die Serverantwort ist etwa doppelt so schnell wie zuvor (0,4 s statt 0,9 s, gleiches Hosting).
• Jede Programmseite mit klarem Angebot: Preis je Tag (werktags, Wochenende und Feiertage), Schnellauswahl der nächsten 7 Tage, FAQ und Vertrauensblock.
• Buchungsdialog mit echten Sitzungen: 8 Termine pro Tag, belegte sind ausgegraut, der Gesamtpreis aktualisiert sich live.
• Gutschein-Konfigurator mit Live-Vorschau: Name, Nachricht, Anlass, Papier- oder E-Gutschein.
• Funnel-Analytics mit einem Ziel für jeden wichtigen Schritt, UTM und Referrer an jeder Anfrage; Barrierefreiheit (Tastatur, Fokus, reduzierte Bewegung), schema.org und Sitemap.

2. Online-Zahlungen direkt über die Bank

• Anbindung der Acquiring-API der Alfa-Bank und des nationalen QR-Zahlungsdienstes Oplati – ohne das alte Backend.
• Der Server berechnet jeden Betrag aus seiner eigenen Preisliste und vertraut nie dem Browser; Bestellnummern kollidieren nie mit alten Bestellungen.
• Die Sitzung bleibt während der Zahlung reserviert. Lehnt die Bank ab oder vergehen 30 Minuten, wird sie automatisch freigegeben – die Anfrage bleibt für einen Rückruf.
• Die Bestätigung hängt nicht davon ab, dass der Gast von der Bankseite zurückkehrt: Der Server fragt die Bank im Hintergrund ab. Danach erhält der Gast eine E-Mail (eigener SMTP-Client, Domain mit DKIM).
• End-to-End geprüft mit einer echten Zahlung über 1 BYN durch eine Mitarbeiterin als normaler Gast: Die Bank bestätigte, die Zahlung erschien in Bot und CRM, die E-Mail ging raus.

3. Telegram-Bot als Steuerzentrale fürs Team

• Das Team arbeitet ohnehin in Telegram – also ist der Bot das Hauptwerkzeug. Kein Nachrichten-Spam: Eine Panel-Nachricht aktualisiert sich selbst, Neues erscheint als Zähler.
• Sitzungen des Tages, Anfragen, Zahlungen, Notizen, Anruf- und WhatsApp-Buttons; Zugriff per befristetem Einladungslink oder Freigabe durch den Inhaber mit einem Tipp, Rechte pro Person.
• Ausfallmeldungen nur an die Inhaber, ein Morgen-Digest und eine Übersicht „Ausfälle und Neustarts“.

Der Telegram-Bot in Aktion

Echte Bot-Texte aus einem Testlauf mit erfundenen Gästen – für das Portfolio ins Englische übersetzt und als Telegram-Ansicht dargestellt. Zum Vergrößern antippen.

4. Web-CRM – in Telegram und im Browser

• Öffnet sich aus dem Bot als Telegram Mini App ohne Passwort: Der Server prüft die HMAC-Signatur der Startdaten. Im Browser geht es über Einmal-Links und ein HttpOnly-Cookie.
• Bereiche: Heute (8 Sitzungen mit Gast, Programm und Status), Kalender beider Websites, Anfragen, Zahlungen, Übersicht mit Kennzahlen und Quellen, Preise.
• Die Geschäftsleitung ändert Preise selbst – Website und Zahlbeträge stellen sofort um. Sieht ein Gast noch einen alten Preis, lehnt der Server den Betrag ab (HTTP 409) und der Dialog lädt den neuen Preis.

5. Altsysteme anbinden, ohne sie anzufassen

• Nur lesende, inkrementelle Synchronisation aus zwei Strapi-Instanzen über eine eigene Leserolle und Cursor-Paging; beide Websites erscheinen in einer CRM-Ansicht mit Kennzeichnung.
• Fehlende Zahlungsbestätigungen geklärt: Die Ursache habe ich für den bisherigen Entwickler dokumentiert und den neuen Zahlungsweg unabhängig davon gebaut.
• Bis zur Umstellung laufen die Altsysteme überwacht weiter – Änderungen daran nur mit Freigabe des Kunden.

6. Umzug nach Belarus und SEO-sichere Migration

• Website, Bot, CRM und Daten auf ein Hosting in Belarus umgezogen – wegen der Datenresidenz.
• Keine Geheimnisse im Repository: Zugangsschlüssel verwaltet der Inhaber selbst, Gästedaten liegen getrennt vom Code.
• Ein Audit-Skript vergleicht jede alte URL mit der neuen Seite (Status, Title, Description, H1, Canonical, Textanteil): Alle alten URLs bleiben erhalten, Unterseiten behalten 90–95 % ihres Textes, Weiterleitungen per 301 behalten den Query-String.
• Alte SEO-Fehler behoben (Canonicals auf eine Platzhalter-Domain, keine Sitemap, keine robots.txt); Umstellungsplan: 1–1,5 Stunden, 3–5 Minuten Ausfall, Rückfall in 5 Minuten.

Architektur

• Statische Website plus kleiner Server statt schwerem Framework: schnell, einfache Deploys auf Shared Hosting.
• Der Server ist die einzige Quelle für Geld: Preise liegen in der CRM, jeder Betrag wird serverseitig neu berechnet, veraltete Preise werden abgelehnt.
• Telegram als Oberfläche fürs Team: keine neue App zum Lernen, Login ohne Passwort über signierte Mini-App-Daten.
• Sicherheit: HMAC-Prüfung der Telegram-Daten, Same-Origin- und Header-Prüfung für CRM-Aktionen, HttpOnly-Cookies, Rate-Limits, Validierung an jedem Endpunkt, keine Gästedaten in Logs oder im Repository.

Tests und Übergabe

• Integrationstests starten den echten Server gegen nachgebaute Bank-, Oplati-, SMTP- und Telegram-Server: der komplette Zahlungsablauf (bezahlt, abgelehnt, Timeout, neuer Versuch, Reservierung), Preise und Rechte, Weiterleitungen und Ausfallmeldungen.
• Puppeteer-End-to-End-Tests gehen wie ein Gast durch die Website – vom Buchungsdialog über die Bankseite bis „Zahlung erfolgreich“ – sowie durch die CRM im Browser und in Telegram. Insgesamt rund 350 automatisierte Prüfungen, vor jedem Deploy grün.
• Übergabe: ein 3-minütiges Onboarding-Video für Manager (Bot und CRM), programmatisch produziert mit HyperFrames und KI-Stimme, dazu kurze Anleitungen für die Geschäftsleitung.

So habe ich gearbeitet

Erst verstehen: alten Code, Server-Logs und Admin-Daten nur lesend analysiert und der Geschäftsleitung strukturierte Fragen mit Antwortoptionen gestellt. Dann schrittweise: Vorschau → Test-Subdomain ohne Indexierung → echte 1-BYN-Zahlung durch das Team → Umstellung der Hauptdomain mit Rückfallplan. Jede Änderung an den Altsystemen nur mit ausdrücklicher Freigabe, Entscheidungen schriftlich festgehalten.

KI-gestützt und transparent: Ich habe mit einem KI-Coding-Agenten (Claude Code) gearbeitet. Richtung, Produkt- und Architekturentscheidungen, Reviews, Tests, Deployment, Zugänge, Kundenkommunikation und Betrieb lagen bei mir; den Großteil von Code und Tests hat der Agent geschrieben.

Die Live-Systeme des Kunden verlinke ich bewusst nicht. Die Screenshots stammen aus einer Demo-Version mit erfundenen Daten; die Oberfläche (im Original Russisch) habe ich für dieses Portfolio ins Englische übersetzt, die Telefonnummer des Kunden ist unkenntlich gemacht. Einblick in Code und Tests gerne im Gespräch.