Mathe-Nachhilfe gebe ich seit Jahren, und ungefähr seit Dezember 2024 ging mir der Gedanke nicht aus dem Kopf, das professioneller aufzuziehen: mit einer eigenen Website und einem Kalender, in dem sich Schüler selbst einen freien Termin aussuchen, statt ihn mit mir per Nachricht auszumachen. Anfang 2025 habe ich mir fertige Buchungssysteme wie Reservio angesehen, aber sie ließen sich entweder nicht so einstellen, dass Einzel- und Gruppenstunden zusammenpassen, oder sie kosteten mehr, als ich für etwas zahlen wollte, das ich ohnehin an meine Bedürfnisse hätte anpassen müssen. Also beschloss ich, es selbst zu machen, obwohl ich vorher nichts mit Programmieren zu tun gehabt hatte.
In diesem Beitrag geht es um die erste Etappe: wie aus ein paar Seiten und einem Formular eine Anwendung wurde, die im Netz läuft und Buchungen annimmt. Unterwegs habe ich eine Menge Fehler gemacht, und von manchen habe ich erst erfahren, als etwas nicht mehr funktionierte.
Die ersten Seiten mit Flask
Am 1. September 2025 speicherte ich die erste Version meines Codes auf GitHub, einem Dienst, der Code samt der ganzen Geschichte seiner Änderungen aufbewahrt. Die Anwendung schrieb ich in Python mit Flask, einem Werkzeug zum Bauen von Websites, von Anfang an für Render, eine Firma, die Server für solche Anwendungen vermietet. Bei Flask hat jede Seite ein fertiges Gerüst, das der Server mit Daten füllt, bevor er es an den Browser schickt. Für den Anfang reichten mir ein paar solcher Gerüste (Startseite, Angebot, Kontakt, Kalender und Buchungsformular), dazu eine Datei, die das Aussehen der Seite beschreibt, und eine Handvoll Bilder. Buchungen, Benutzerkonten, Urlaube und Einstellungen lagen in einfachen Textdateien neben dem Code, was sich später noch rächen sollte.
Von Anfang an gab es auch einen Admin-Bereich, denn irgendjemand musste die Buchungen sehen, Termine sperren und auf Nachrichten antworten. Die Preisliste stand nicht in der Datenbank, sondern in einer Datei mit Einstellungen: zuerst die Dauer der Stunden und die Preise, später auch rabattierte Pakete und Raten. Wollte ich einen Preis ändern, habe ich die Datei angepasst und die ganze Seite neu auf den Server gespielt. Damals hielt ich das für eine vernünftige Vereinfachung, und eine Zeit lang war es das auch.
Ein kurzer Ausflug zu PHP
Das erste ernste Problem betraf nicht die Anwendung selbst, sondern die Frage, wo sie laufen soll. Die billigsten Server, wie man sie normalerweise für eine Firmenwebsite mietet, sind auf PHP ausgelegt, eine andere Programmiersprache, und nicht auf Python, in dem ich Algebra geschrieben hatte. Also dachte ich mir: Wenn der Server für PHP gemacht ist, schreibe ich die Anwendung eben für den Server um.
Mitte September habe ich die ganze Seite in ein neues PHP-Projekt übertragen, aber nach ein paar Tagen ließ ich die Idee wieder fallen und kehrte zu Flask zurück. Statt eine laufende Anwendung an den Server anzupassen, suchte ich mir einen Server, der die Anwendung so nimmt, wie sie ist. Die Lehre aus dieser Episode ist einfach: Die Wahl des Servers gehört zum Projekt und ist keine Formalität für ganz am Ende.
Render, Koyeb und zwei Tage Herumprobieren
Im Oktober habe ich die Flask-Version in einem neuen Projekt aufgeräumt, und am 26. Oktober 2025 habe ich auf GitHub das angelegt, in dem ich bis heute arbeite. Darin lagen von Anfang an Anweisungen für Render, das die Anwendung selbst direkt aus dem Code baut und startet. Ich wählte den kostenlosen Tarif und einen Server in Frankfurt, und die Anwendung bekam eine eigene Adresse im Netz.
Bevor alles lief, bin ich allerdings zwei Tage lang zwischen Render und Koyeb, einem sehr ähnlichen Dienst, hin- und hergeirrt. Die Startdatei, nach der der Server die Anwendung hochfährt, habe ich erst hinzugefügt, dann gelöscht, weil Koyeb Flask von selbst erkennen sollte, und schließlich wieder hinzugefügt. Außerdem klopfte der Server bei der Prüfung, ob die Anwendung noch lebt, an Tür 8000, während sie hinter einer anderen wartete, also musste ich die Nummern abstimmen. Dazu mussten die Cookies, mit denen sich eine Seite merkt, wer angemeldet ist, auf dem Server anders eingestellt werden als auf meinem eigenen Rechner. Am Ende hat Render gewonnen, und dort läuft Algebra bis heute.
Ein ganzer Tag für den Header
Ein eigenes Kapitel verdient der 18. November, denn an diesem Tag stehen in der Änderungsgeschichte über zwanzig Korrekturen allein am Header, also an der Leiste mit dem Menü oben auf der Seite. Auf dem Handy brach das Menü in zwei Zeilen um, die Buttons standen treppenförmig versetzt, und das ausklappbare Menü (das Symbol mit drei Strichen) verhielt sich für Besucher anders als im Admin-Bereich. Jede Korrektur reparierte etwas und machte etwas anderes kaputt, bis ich schließlich alle Änderungen auf den Stand vom Morgen zurückgesetzt und neu angefangen habe, diesmal mit einer Kopie des Headers aus dem Admin-Bereich, der gut funktionierte.
Die Lehre aus diesem Tag hilft bei jedem Projekt: Wenn sich die Korrekturen im Kreis drehen, kehrt man besser zum letzten guten Stand zurück und macht eine durchdachte Änderung, statt Flicken auf Flicken zu setzen.
Die ersten Zahlungen
Noch im Oktober habe ich Algebra an Stripe angebunden, eine Firma, die Zahlungen im Internet abwickelt, und daran erst verstanden, wie so eine Zahlung überhaupt abläuft. Der Kunde wechselt auf die Seite des Zahlungsanbieters, bezahlt und kehrt auf meine Seite zurück, während der Anbieter meinem Server separat eine Nachricht schickt, dass das Geld angekommen ist. Nach ein paar Tagen bin ich aber zu HotPay gewechselt, und in den AGB der Seite tauchte ein Hinweis auf den neuen Zahlungsanbieter auf. Im November kamen Raten und rabattierte Pakete dazu und mit ihnen die erste Korrektur in der Preisdatei, denn so eine Datei verzeiht nicht einmal ein einziges falsch gesetztes Komma, sonst versteht die Seite sie nicht mehr.
Wo ich heute stehe
Drei Monate nach der ersten Version des Codes hat Algebra eine Website, einen Kalender, Buchungen, einen Admin-Bereich und Zahlungen. Den meisten Ärger macht mir gerade die Datenbank, denn Buchungen verschwinden manchmal, nachdem ich eine neue Version der Seite auf den Server gespielt habe. Ich suche nach der Ursache, und wenn ich sie gefunden habe, schreibe ich darüber einen eigenen Beitrag.
Die ganze Serie
Mit diesem Beitrag beginnt eine Serie darüber, wie Algebra i Spółka entstanden ist:
- Die erste Algebra: Flask, Templates und PHP, das ich schnell aufgab
- Buchungen, die bei jedem Deployment verschwanden
- Algebra neu gebaut: von Flask-Templates zu React und TypeScript
- Eine Preisliste in einer Datei, Premium und mein erstes Zahlungsgateway
- Aufgaben, eine Formelsammlung und Zeichnungen, die nicht stimmen wollten
Wie das Ganze heute aussieht, beschreibe ich im Beitrag Algebra i Spółka von innen.