Solo-SaaS mit Laravel und Nuxt: Fünf Entscheidungen, die sich ausgezahlt haben

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-API, Nuxt-App, Kundenportal, iOS-App, Marketing-Site. Allein. Diese fünf Entscheidungen haben sich am deutlichsten ausgezahlt — und seit dem 1.0-Release im September 2026 weiß ich, dass sie auch unter Last halten (siehe Nachtrag).

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

Im Juli waren es gut 100 Pest-Tests im Backend, Playwright-E2E-Tests im Frontend und 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.

Nachtrag: nach dem 1.0-Release

Ergänzt im Oktober 2026. Am 26. September 2026 ist PEX in Version 1.0 in Produktion gegangen — mit E-Rechnung, DATEV-Export, Mahnwesen und Steuerberater-Zugang. So haben sich die fünf Entscheidungen bis dahin geschlagen:

Auth-Domänen: Mit dem Steuerberater kam eine dritte Nutzergruppe dazu. Sie ist bewusst kein dritter Guard, sondern eine Rolle im Team-Modell — mit reinem Lesezugriff und Mandantenwechsel. Faustregel, die sich daraus ergeben hat: eigener Guard, wenn die Gruppe nichts mit dem Team zu tun hat (Kunden); Rolle, wenn sie im Team-Kontext arbeitet.
Stripe: Cashier deckt weiterhin die Abos ab. Für Zahlungen der Kunden meiner Nutzer kam Stripe Connect dazu, inklusive SEPA-Lastschrift und Zahlungslink mit QR-Code — wieder gekauft statt gebaut.
Hintergrund-Jobs: Das Muster aus Horizon und Live-Fortschritt trägt inzwischen auch die E-Rechnungs-Pipeline mit eigener Queue. Wie die aufgebaut ist, beschreibe ich in E-Rechnung in Laravel.
Tests und CI: Aus gut 100 Tests wurden über 2.000 im Backend, dazu über 2.200 Vitest-Tests und eine Playwright-Suite im Frontend. CI läuft auf einem eigenen Self-hosted-Runner, jede Änderung geht über Staging und eine vollständige Regressionsrunde, bevor sie in Produktion darf.
Marketing statisch: Unverändert richtig — die Marketing-Site ist weiterhin eine eigenständige Astro-Site.

Wie das Gesamtsystem heute aussieht, zeigt die PEX Case Study.