Warum ich einen eigenen SaaS Stack gebaut habe

Das Problem, das jeder SaaS-Entwickler kennt

Jedes SaaS-Projekt beginnt gleich. Man hat eine brillante Produktidee, oeffnet den Editor, erstellt ein neues Repository — und dann verbringt man die naechsten vier bis sechs Wochen damit, die immer gleichen Grundlagen zu bauen: Benutzerregistrierung, E-Mail-Verifizierung, Login, Passwort-Reset, Zahlungsintegration, Abonnement-Verwaltung, Rollensystem. Erst danach kann man ueberhaupt anfangen, an der eigentlichen Idee zu arbeiten.

Ich habe das dreimal durchgemacht. Dreimal denselben Code geschrieben. Dreimal dieselben Stripe-Webhooks implementiert. Dreimal dieselben OAuth2-Flows aufgesetzt. Beim dritten Mal habe ich mich gefragt: Warum mache ich das eigentlich jedes Mal von vorne?

Das Problem ist nicht, dass es keine Loesungen gibt. Es gibt Auth0, Clerk, Firebase Auth, Supabase — alles gute Services. Aber sie loesen immer nur einen Teil des Problems. Und sobald man mehrere Produkte betreibt, die unter einer gemeinsamen Marke laufen sollen, wird es kompliziert. Ich wollte, dass sich ein Benutzer einmal bei IT-Trail anmeldet und dann nahtlos zwischen Atoo Studio, SiteHorse und zukuenftigen Produkten wechseln kann. Das bietet kein Drittanbieter out of the box.

Die Entscheidung: Einmal bauen, fuer immer wiederverwenden

Bevor ich mit SiteHorse.ai angefangen habe, traf ich eine bewusste Entscheidung: Ich investiere vier Wochen in ein solides Fundament. Nicht in ein Produkt, das Geld verdient. Nicht in ein Feature, das Kunden sehen. Sondern in Infrastruktur. In die langweiligen Teile, die niemand bemerkt, wenn sie funktionieren — und die alles zum Einsturz bringen, wenn sie es nicht tun.

Das war keine leichte Entscheidung. Als Solo-Gruender zaehlt jede Woche. Vier Wochen in etwas zu investieren, das keinen direkten Umsatz generiert, fuehlt sich wie ein Risiko an. Aber ich wusste aus Erfahrung: Die Alternative — jedes Mal von vorne anfangen und dabei jedes Mal andere kleine Fehler machen — ist langfristig teurer.

Was steckt im IT-Trail SaaS Stack?

Der Stack ist das komplette Fundament, das jedes meiner SaaS-Produkte braucht. Im Kern besteht er aus mehreren Modulen, die zusammen oder einzeln verwendet werden koennen.

OAuth2-basiertes Single Sign-On

Das Herzstueck ist ein vollstaendiger OAuth2-Server, der als zentrale Identitaetsschicht fuer alle IT-Trail Services dient. Ein Benutzer registriert sich einmal und kann sich dann bei jedem Produkt anmelden, das auf dem Stack aufbaut. Atoo Studio, SiteHorse, zukuenftige Produkte — eine Identitaet, ein Login.

Das klingt einfach, aber die Implementierung hat es in sich. OAuth2 ist ein komplexes Protokoll mit vielen Flows: Authorization Code mit PKCE fuer Webanwendungen, Client Credentials fuer Service-zu-Service-Kommunikation, Refresh Tokens fuer langlebige Sessions. Ich habe alle relevanten Flows implementiert und dabei bewusst auf Bibliotheken wie Passport.js verzichtet, weil ich die volle Kontrolle ueber den Token-Lifecycle haben wollte.

Benutzerregistrierung und Social Login

Die Registrierung unterstuetzt klassische E-Mail-Anmeldung mit Verifizierung sowie Social Login ueber Google und Microsoft. Gerade Microsoft war wichtig, weil viele Business-Kunden sich ueber ihr Azure-AD-Konto anmelden wollen. Die Integration beider Provider war ueberraschend unterschiedlich — Google ist unkompliziert und gut dokumentiert, Microsoft erfordert deutlich mehr Konfigurationsarbeit und hat subtile Unterschiede in der Token-Validierung.

Zahlungsintegration: Stripe und Paddle

Hier habe ich eine pragmatische Entscheidung getroffen: Ich unterstuetze sowohl Stripe als auch Paddle. Warum zwei Payment Provider? Die Antwort ist einfach: Steuern.

Stripe ist der Goldstandard fuer Zahlungsabwicklung. Die API ist exzellent, die Dokumentation erstklassig, die Webhook-Integration zuverlaessig. Aber Stripe ist ein reiner Payment Processor — als Unternehmen bin ich selbst fuer die korrekte Umsatzsteuerabwicklung in jedem Land verantwortlich, in dem ich Kunden habe. Als Einzelunternehmer in Oesterreich ist das ein administrativer Albtraum, wenn man weltweit verkauft.

Paddle hingegen ist ein Merchant of Record. Das bedeutet, Paddle verkauft technisch gesehen an den Endkunden und kuemmert sich um die gesamte Umsatzsteuer-Thematik. Dafuer nehmen sie einen hoeheren Anteil. Fuer B2C-Produkte mit vielen internationalen Kleinkunden ist Paddle oft die bessere Wahl. Fuer B2B mit weniger, aber groesseren Kunden ist Stripe effizienter.

Im Stack habe ich eine abstrakte Payment-Schicht gebaut, die beide Provider hinter einem einheitlichen Interface verbirgt. Jedes Produkt kann selbst entscheiden, welchen Provider es nutzt — oder sogar beide gleichzeitig fuer verschiedene Preisplaene.

Rollenbasierte Zugriffskontrolle

Das Berechtigungssystem ist bewusst einfach gehalten: Benutzer haben Rollen, Rollen haben Berechtigungen. Keine verschachtelten Gruppen, keine komplexen Policies. Fuer die Produkte, die ich aktuell baue, reicht das. Das System ist aber so entworfen, dass es bei Bedarf erweitert werden kann.

TypeScript end-to-end

Der gesamte Stack ist in TypeScript geschrieben — Backend, geteilte Types, Utility-Bibliotheken. Das war eine bewusste Entscheidung. TypeScript gibt mir Typsicherheit ueber die gesamte Codebasis. Wenn ich ein Feld im User-Objekt umbenenne, zeigt mir der Compiler sofort alle Stellen, die angepasst werden muessen. Bei einem System, das die Grundlage fuer mehrere Produkte bildet, ist diese Sicherheit unbezahlbar.

Wie sich die Investition ausgezahlt hat

SiteHorse.ai — mein KI-gestuetzter Website-Builder — wurde in sechs Wochen gebaut. Sechs Wochen von der ersten Zeile Code bis zum oeffentlichen Launch. Das waere ohne den SaaS Stack schlicht unmoeglich gewesen.

Von Tag eins an hatte SiteHorse funktionierendes Login, Registrierung, E-Mail-Verifizierung, Google-Login, Stripe-Integration mit verschiedenen Preisplaenen und ein Rollensystem. All das musste ich nicht schreiben — ich habe es einfach eingebunden. Ich konnte mich komplett auf das konzentrieren, was SiteHorse einzigartig macht: den KI-gesteuerten Website-Generator, die Template-Engine, den visuellen Editor.

Architekturentscheidungen

Einige Entscheidungen verdienen eine naehere Erklaerung.

Warum OAuth2 statt einer einfacheren Loesung? JWT-basierte Sessions waeren fuer ein einzelnes Produkt voellig ausreichend. Aber ich baue nicht ein Produkt — ich baue ein Oekosystem. OAuth2 gibt mir standardisierte Flows fuer Cross-Service-Authentifizierung, die von jedem Client verstanden werden. Wenn morgen ein mobiler Client dazukommt, muss ich nichts aendern.

Warum ein modularer Monolith? Ich habe bewusst keine Microservices gebaut. Der Auth-Server, die Payment-Integration und die User-Verwaltung sind separate Module in einem einzigen Repository. Sie teilen sich Types und Utilities, werden aber unabhaengig deployed. Das gibt mir die Einfachheit eines Monolithen bei der Entwicklung und die Flexibilitaet von Services beim Deployment.

Open-Source-Plaene

Der IT-Trail SaaS Stack ist aktuell ein privates Repository. Aber ich plane, ihn als Open Source zu veroeffentlichen. Meine Ueberzeugung: Gute Infrastruktur sollte kein Wettbewerbsvorteil sein. Der Wert liegt in den Produkten, die auf dem Fundament gebaut werden, nicht in der Klempnerei darunter.

Bevor es soweit ist, muss ich allerdings noch einiges aufraumen. Dokumentation schreiben. Konfigurationsbeispiele erstellen. Sicherstellen, dass keine Secrets im Code oder in der Git-History sind. Open Source bedeutet auch Verantwortung — besonders bei sicherheitskritischem Code wie Authentifizierung und Zahlungsabwicklung.

Lessons Learned

Was habe ich aus dem Projekt gelernt?

Bau nicht neu, was du schon gebaut hast. Es klingt offensichtlich, aber der Drang, es “diesmal richtig” zu machen, ist real. Ja, der Code von vor zwei Jahren ist nicht perfekt. Aber er funktioniert und ist getestet. Refactoring ist sinnvoller als ein kompletter Neubau.

Investiere frueh in Fundamente. Die langweiligen Teile — Auth, Payments, User Management — sind genau die Teile, die am haertesten zurueckbeissen, wenn sie schlecht gebaut sind. Ein Bug in der Authentifizierung ist kein Feature-Request, den man verschieben kann. Er ist ein Sicherheitsvorfall.

Halte es einfach, bis du einen Grund fuer Komplexitaet hast. Mein Rollensystem hat drei Rollen. Mein OAuth2-Server unterstuetzt zwei Grant Types. Mein Payment-System hat zwei Provider. Das reicht. Wenn ich fuenf Produkte habe und die Anforderungen wachsen, kann ich erweitern. Aber vorher baue ich keine Infrastruktur fuer Probleme, die ich noch nicht habe.

Der IT-Trail SaaS Stack ist kein glamouroeses Projekt. Es gibt keine beeindruckende Demo, keinen Wow-Effekt. Aber er ist der Grund, warum ich SaaS-Produkte in Wochen statt Monaten bauen kann. Und das ist mehr wert als jedes Feature.