Solo-SaaS mit Laravel und Nuxt: Fünf Entscheidungen, die sich ausgezahlt haben
Veröffentlicht am · Marten Ackermann
Kurzantwort: Ein Solo-SaaS steht und fällt mit Entscheidungen, die Arbeit vermeiden: getrennte Auth-Domänen statt Rollen-Spaghetti, Stripe Cashier statt eigener Abrechnung, WebSockets für lange Jobs, Tests als Standard statt als Nachtrag — und eine statische Marketing-Site, die das App-Bundle nicht belastet.
Ich habe PEX gebaut — eine Rechnungs- und Zeiterfassungs-Software für Freelancer und Agenturen: Laravel-11-API, Nuxt-3-App, Kundenportal, iOS-App, Marketing-Site. Allein. Diese fünf Entscheidungen haben sich am deutlichsten ausgezahlt.
1. Zwei Auth-Domänen statt einer Rollenmatrix
PEX hat zwei fundamental verschiedene Nutzergruppen: das Team, das Rechnungen schreibt, und dessen Kunden, die im Portal Rechnungen einsehen und bezahlen. Statt beide in ein User-Modell mit Rollen zu pressen, gibt es zwei getrennte Guards: Laravel Sanctum für Team-Nutzer, ein eigener customer-Guard mit Bearer-Tokens für Portal-Kunden.
Der Gewinn: Kein Endpoint kann versehentlich für die falsche Gruppe erreichbar sein — die Trennung liegt in der Infrastruktur, nicht in if-Bedingungen.
2. Stripe Cashier statt eigener Abo-Logik
Abrechnung selbst zu bauen ist die klassische Solo-Falle: Proration, fehlgeschlagene Zahlungen, Steuern, Mahnungen. Laravel Cashier deckt Subscriptions und Portal-Zahlungen ab; was bleibt, ist die Webhook-Verarbeitung — mit Wiederholungslogik, denn Webhooks kommen doppelt, verspätet oder gar nicht.
Faustregel: Die Abrechnung ist bei einem Solo-Produkt nie das Differenzierungsmerkmal. Kaufen, nicht bauen.
3. Lange Jobs sichtbar machen: Horizon + WebSockets
CSV-Massenimporte laufen bei PEX als Hintergrund-Jobs über Laravel Horizon. Der Fortschritt wird per WebSockets (Pusher) live ins Frontend gestreamt. Das kostet einen Abend Einrichtung und erspart dauerhaft die schlechteste aller UX: einen Spinner, der lügt.
4. Tests und CI vom ersten Tag
53 Pest-Tests im Backend, Playwright-E2E-Tests im Frontend, vier GitHub-Actions-Workflows. Als Solo-Entwickler gibt es kein zweites Augenpaar — die Testsuite ist der Kollege, der beim Refactoring widerspricht. Ohne sie hätte ich den Wechsel auf shadcn/ui und größere Feature-Branches nicht ruhig ausrollen können.
5. Marketing statisch, App dynamisch
Die Marketing-Site ist eine eigene Astro-5-Site — statisches HTML, kein App-Framework, perfekte Core Web Vitals. Die Nuxt-App bleibt eine reine Client-Anwendung hinter dem Login. Beide Welten haben gegensätzliche Anforderungen (SEO vs. Interaktivität); sie in einem Framework zu vereinen, macht beides schlechter.
Fazit
Keine dieser Entscheidungen ist spektakulär. Genau das ist der Punkt: Ein Solo-SaaS scheitert selten an fehlender Raffinesse — sondern an Komplexität, die man sich selbst eingebrockt hat. Jede der fünf Entscheidungen hat Komplexität gestrichen, bevor sie entstehen konnte.
Wie das Gesamtsystem aussieht, zeigt die PEX Case Study.