Vom Chatfenster ins Repo: was sich 2026 änderte

Psychofit ist eine Plattform für psychologische Beratung im Netz. Sie macht wissenschaftlich fundierte Unterstützung für Leute zugänglich, die sonst monatelang warten würden — beraten von Psychologie-Absolvent:innen unter Supervision approbierter Psychotherapeut:innen. Warum das der Anspruch ist, steht auf der Mission-und-Vision-Seite.

Psychofit ist ein Gründerteam, kein Ein-Personen-Projekt. Ich bin technischer Mitgründer und verantworte alles Technische — was in diesem Text steht, ist mein Teil davon.

Zwischen Dezember 2023 und Anfang Januar 2026 sind daran rund 24.000 Zeilen Code entstanden, verteilt auf 245 Commits. In den 17 Arbeitstagen danach kamen 72.000 dazu.

Die Zahlen stehen so im Git-Verlauf, ich habe sie nachgezählt. Was sie nicht verraten: In beiden Phasen war KI im Spiel.

Der Unterschied war nicht die KI, sondern wo sie saß

In der ersten Phase habe ich mit claude.ai gearbeitet — im Browser, in einem Chatfenster. Frage stellen, Antwort lesen, Code markieren, in den Editor kopieren, anpassen, zurückkopieren wenn etwas nicht lief. Das hat funktioniert und war schneller als ohne. Aber jeder Schritt lief über meine Zwischenablage.

Ende 2025 bin ich auf Claude Code umgestiegen, den Coding-Agenten von Anthropic. Dahinter steckt dasselbe Modell wie im Chatfenster. Der Unterschied ist, wo es sitzt: im Terminal und als Erweiterung in VS Code, mit Zugriff auf das Repository. Es liest die Dateien selbst, ändert sie selbst, führt die Tests aus und sieht, was dabei herauskommt.

Mit dem Opus-Modell ab Ende 2025 wurde daraus etwas, das trägt. Damit stand ich nicht allein: Andrej Karpathy, früher KI-Chef bei Tesla, beschrieb im Januar 2026, dass Coding-Agenten seit Dezember eine Schwelle überschritten hätten: weg von Demos, hin zu Aufgaben, die über lange Strecken zusammenhängend bleiben. Ungefähr das war auch meine Erfahrung.

Der Unterschied klingt nach Bequemlichkeit. Er ist aber ein Unterschied in der Art der Aufgabe, die man überhaupt stellen kann.

Im Chatfenster fragt man: „Wie schreibe ich eine Funktion, die freie Terminslots berechnet?” Man bekommt eine Funktion. Den Rest — wo sie hingehört, welche Typen sie braucht, was sie in den vier anderen Dateien kaputt macht — macht man selbst.

Im Repository fragt man: „Ersetze Calendly durch ein eigenes Buchungssystem.” Das ist keine Funktion, das sind 366 Dateien.

Was in den 17 Tagen entstand

Wir hatten Calendly im Einsatz und drei Probleme damit. Erstens ließ sich die automatische Bestätigungsmail nicht abschalten — Klient:innen bekamen zwei Mails, unsere und die von Calendly. Das ist ein seit Jahren offener Punkt in deren Community, es gibt keinen Workaround. Zweitens lag der Buchungsabschluss auf einer fremden Domain, wo das Conversion-Tracking nicht griff. Drittens hätte ein geplantes Feature bedeutet, pro Berater:in die Event-Typen zu verdoppeln, nur um zwei Kundengruppen unterscheiden zu können.

Die Entscheidung, das selbst zu bauen, fiel im Team. Gebaut habe ich es.

Dazu kam ein zweites Werkzeug: Typeform für Feedback- und sonstige Fragebögen. Auch das läuft jetzt selbst, zugeschnitten auf das, was wir tatsächlich fragen wollen.

Also: eigenes Buchungssystem. Es rechnet die freien Zeiten selbst aus der Datenbank — Wochenverfügbarkeiten, Ausnahmen, Puffer zwischen Terminen, Kapazitätsgrenzen. Reservierung, Zahlung und Buchung hängen als eine Kette zusammen, damit kein Slot doppelt vergeben wird.

Dazu kamen drei Oberflächen, die es vorher nicht gab:

Ein Dashboard für die Berater:innen: Wochenzeiten pflegen, Ausnahmen und Urlaub eintragen, Zeitzone setzen, Kundenübersicht mit Filtern, Termine verschieben oder absagen. Der Urlaubsmodus benachrichtigt betroffene Klient:innen automatisch — klingt nebensächlich, ist es bei laufenden Beratungen nicht.

Ein Admin-Bereich: Berater:innen anlegen und verwalten, Buchungen einsehen und exportieren, das komplette E-Mail-System mit rund zwanzig Vorlagen und einem Editor, Erinnerungsregeln, Rabattcodes mit Nachweisprüfung. Und ein Not-Aus für den Mailversand, falls eine Vorlage kaputt ist.

Ein Kundenportal: Folgetermin buchen, selbst stornieren oder umbuchen innerhalb der 48-Stunden-Regel, Marketing-Mails abbestellen.

228 Commits, 366 Dateien, 72.371 Zeilen netto. Vom 8. Januar bis zum 14. Februar 2026, an 17 Tagen mit Commits.

Wofür das früher ein Team gebraucht hätte

Was mich daran am meisten überrascht, ist nicht die Geschwindigkeit an sich. Es ist, woran ich sie messe.

Ich habe fünf Jahre in Teams mit fünf bis fünfzehn Leuten gearbeitet, zuletzt als Lead. Ein Vorhaben dieser Größe war dort selbstverständlich verteilt: jemand fürs Backend, jemand fürs Frontend, jemand für die Pipeline, dazu Abstimmung, Code-Reviews und Übergaben zwischen Leuten, die alle nur einen Ausschnitt sehen. Das ist kein Vorwurf — so arbeitet man, wenn eine Person die Menge nicht schafft.

Diese Aufteilung ist bei mir weggefallen, und mit ihr die Reibung dazwischen. Was bleibt, ist die Arbeit, die vorher zwischen den Rollen unterging: zu wissen, was gebaut werden soll, und zu erkennen, wenn das Ergebnis nicht stimmt.

Zwei Beispiele aus demselben Repository, beide nachzählbar:

Der Bezahl- und Buchungsweg — Stripe-Anbindung, Datenmodell, Kalender, Zahlungsarten, Verfügbarkeitsanzeige auf der Startseite — ging vom ersten Commit bis zur fertigen Seite in drei Tagen live, 34 Commits. Im Januar 2026.

Eine Wirkungsmessung mit Fragebögen, Versionierung der Fragebogen-Stände, Auswertung als Zeitreihe, automatischem Aufräum-Job und Anbindung an ein Bewertungsportal: fünf Tage, 31 Commits, 56 Dateien. Im Juli.

Für Vorhaben dieser Art habe ich früher in Wochen gerechnet, bei mehreren Beteiligten auch in Monaten — Abstimmung, Reviews und Übergaben eingerechnet. Das ist der Unterschied, der mich selbst am meisten überrascht.

Was seitdem nicht mehr auf der Rechnung steht

Der offensichtliche Posten sind die Lizenzen. Calendly kostet im Standard-Tarif 12 Euro pro Platz und Monat bei monatlicher Zahlung. Das ist ein Preis pro Berater:in, nicht pro Buchung: Bei vier Berater:innen sind das 48 Euro im Monat, ob null Termine gebucht werden oder hundert. Bei zwanzig wären es 240 Euro. Typeform beginnt im günstigsten kostenpflichtigen Tarif bei 25 US-Dollar im Monat.

Diese Posten sind jetzt null, und sie bleiben null, wenn das Team wächst. Genau das ist der Punkt: Bei zugekauften Werkzeugen wächst die Rechnung mit dem Team, beim eigenen System nicht.

Wichtiger ist aber, was die Lizenzrechnung nicht abbildet. Der Buchungsflow gehört jetzt uns — von der Slot-Auswahl über den Stripe-Checkout bis zur Bestätigungsmail ist das ein durchgehender Ablauf, den wir gestalten, statt zwischen fremden Oberflächen hin- und herzuspringen. Wenn wir merken, dass Klient:innen an einer Stelle abspringen, ändern wir diese Stelle. Kein Feature-Request bei einem Anbieter, kein Warten auf dessen Roadmap, kein Workaround für etwas, das seit Jahren offen ist.

Das ist der eigentliche Grund, warum sich der Aufwand gelohnt hat. Die Lizenzgebühren waren der Anlass. Die Kontrolle über den Ablauf ist das Ergebnis.

Was das wert ist, und was der Vergleich nicht sagt

Um den Aufwand einzuschätzen, hilft ein Blick darauf, was Dienstleister für die einzelnen Teile ansetzen. Nicht für das Gesamtpaket, sondern Stück für Stück:

Teil	Übliche Schätzung
Buchungssystem mit Zahlung	8 bis 12 Wochen für ein MVP, 25.000 bis 45.000 Dollar
Kundenportal	3 bis 4 Monate bis zur ersten nutzbaren Fassung
Backend mit Datenbank	20.000 bis 80.000 Euro für eine API mit Geschäftslogik, rund 200 Stunden für den Kern

Das sind drei von sechs Bereichen, und schon sie summieren sich auf ein halbes Jahr. Für das Berater:innen-Dashboard, den Admin-Bereich und das E-Mail-System mit Editor habe ich keine Schätzung gefunden, die ich guten Gewissens zitieren würde. Sie kommen also obendrauf, ohne dass ich beziffere, wie viel.

Der Freelancer-Kompass 2025 nennt für IT-Freelancer im DACH-Raum einen mittleren Stundensatz von 95 Euro, über alle Branchen 104 Euro. Wer den Umfang gegen diese Schätzungen hält, landet bei 400 bis 600 Stunden, beim genannten Satz also grob 38.000 bis 57.000 Euro für einen Senior-Freelancer.

Bei einer Agentur wird daraus eine andere Zahl. Deutsche Digitalagenturen nennen öffentlich Stundensätze von 120 bis 180 Euro beziehungsweise 120 bis 150 Euro. Auf dieselben 400 bis 600 Stunden gerechnet sind das 48.000 bis 108.000 Euro — nur für die Entwicklung.

Und die ist dort nicht der ganze Posten. Dieselbe Agentur schreibt, dass Entwicklung typischerweise nur 30 bis 40 Prozent der Projektkosten ausmacht; der Rest geht an Strategie, Design, Testing und Projektleitung. Rechnet man das mit, liegt ein Projekt dieses Umfangs im sechsstelligen Bereich.

Das ist kein Vorwurf an Agenturen. Diese Posten existieren, weil mehrere Menschen sich abstimmen müssen, und in einem Team von fünf ist eine Projektleitung keine Verschwendung, sondern die Voraussetzung dafür, dass überhaupt etwas fertig wird. Ich hatte diese Kosten nicht, weil ich diese Abstimmung nicht hatte.

Die grobe Summe

Wer den ganzen Umfang vergeben hätte, also Buchungssystem, Zahlungsabwicklung, Beraterinnen-Dashboard, Admin-Bereich, Kundenportal, Fragebögen und das E-Mail-System, landet je nach Anbieter grob hier:

Wer baut	Grobe Größenordnung
Erfahrener Freelancer	40.000 bis 60.000 Euro
Kleine Agentur	ab etwa 120.000 Euro

Die untere Zahl deckt sich mit zwei unabhängigen Wegen: einmal über die Stundenschätzung, einmal über die Einzelposten oben, bei denen allein Buchungssystem und Backend schon über 40.000 Euro liegen. Nach oben wird es schnell unscharf, deshalb steht dort ein “ab”.

Der Unterschied ist nicht, dass ich schneller tippe. Er ist, dass ich weiß, welche Frage ich dem Werkzeug stellen muss, und dass ich erkenne, wenn die Antwort falsch ist. Fünfzehn Jahre Praxis entscheiden hier mehr als das Modell.

Douglas Adams hat das 1979 aufgeschrieben, lange bevor es Coding-Agenten gab: Der Supercomputer rechnet siebeneinhalb Millionen Jahre und liefert 42. Eine völlig korrekte Antwort, nur hatte niemand die Frage sauber gestellt. Daran hat sich wenig geändert, außer der Rechenzeit.

Beide Rechnungen sind Marktvergleiche, keine Beweise. Sie sagen, was jemand verlangt hätte. Sie sagen nichts darüber, ob mein Ergebnis dasselbe Ergebnis ist.

Was die Zahl verschweigt

Drei Einwände, die man mir entgegengehalten hat, und die alle stimmen.

Ist der Code wartbar? Die 17 Tage sind Sunk Cost. Die Zeitzonen-Sonderfälle, die Sommerzeitübergänge, die Race Conditions beim gleichzeitigen Zugriff auf denselben Slot — die kommen jedes Jahr wieder. Alles, was Calendly für mich erledigt hat, pflegen wir jetzt selbst — und in der Praxis heißt das: ich. Ein eigenes System zu bauen ist nicht die teure Entscheidung. Es zu betreiben ist es.

Kann ich jede Zeile erklären? Nicht auswendig. Aber die technischen Entscheidungen habe ich getroffen und ich lese, was entsteht. Der Unterschied zwischen „hat ein Werkzeug benutzt” und „weiß nicht, was da läuft” ist genau dieser: ob man die Fragen stellt oder nur die Antworten nimmt.

Sind 2.000 Zeilen am Tag nicht zu viel? Die Frage geht an der Sache vorbei, und das ist mir erst beim Arbeiten aufgefallen: Ich schaue nicht mehr auf Zeilen. Ich klicke das Feature durch und prüfe, ob es tut was es soll — beim Buchungssystem heißt das: Termin buchen, stornieren, umbuchen, in eine Zeitzone wechseln, zwei Browser gleichzeitig auf denselben Slot. Der Feinschliff kommt danach, Stück für Stück, wenn im Betrieb auffällt was fehlt.

Zeilen zu zählen war eine Maßeinheit für eine Zeit, in der jede einzelne Handarbeit war. Sie sagt heute nur noch, wie viel Text entstanden ist. Nicht, ob er das Richtige tut.

Was ich mitnehme

Das Werkzeug hat mir keine Entscheidung abgenommen. Ob das Buchungssystem eigene Slots rechnet, was passiert wenn zwei Leute gleichzeitig denselben Termin klicken — das waren meine Fragen, und sie zu stellen war die Arbeit.

Was gebaut wird, ist dagegen nie meine Entscheidung allein. Das klärt sich im Gespräch: mit meinem Mitgründer, der die fachliche Seite verantwortet, und mit den Berater:innen und Nutzer:innen, die täglich damit arbeiten. Dass Calendly rausfliegt, stand am Ende einer solchen Runde, nicht am Anfang. Das schnellste Werkzeug hilft nicht, wenn man das Falsche baut.

Was sich geändert hat, ist die Größe der Aufgabe, die zwischen Frage und Ergebnis passt. Im Chatfenster war das eine Funktion. Im Repository ist es ein Teilsystem.

Das ist ein echter Unterschied. Er ist nur nicht der, den die meisten meinen, wenn sie „mit KI gebaut” sagen.