SaaS MVP-Entwicklung mit Laravel, React und Vue.js

SaaS MVP-Entwicklung mit Laravel und React oder Vue.js ist für B2B-Produkte ein bewährter Weg, weil das Backend-Framework Authentifizierung, Hintergrundaufgaben, Abrechnung und Administration mit ausgereiften Bausteinen abdeckt und das Frontend-Framework eine reaktionsschnelle Oberfläche liefert. Ob React oder Vue, ist dabei zweitrangig. Wichtiger ist, welche Frage das MVP beantworten soll, wie eng der erste Umfang geschnitten wird und welche Grundsatzentscheidungen – Mandantentrennung, Datenschutz, Datenmodell – von Anfang an richtig getroffen werden. Diese drei Punkte behandeln wir hier.

Die Frage hinter dem MVP

Ein MVP ist kein abgespecktes Endprodukt, sondern ein Versuchsaufbau. Im B2B-Umfeld geht es fast immer um eine dieser Fragen:

• Ersetzen Unternehmen einer bestimmten Branche ihren bisherigen Ablauf – oft Excel, E-Mail oder eine Branchensoftware – durch unser Produkt?
• Sind sie bereit, dafür regelmäßig zu zahlen?
• Liefert der Kernprozess zuverlässig genug ein Ergebnis, dass die Nutzung nach dem ersten Monat anhält?

Solange diese Frage nicht schriftlich formuliert ist, lässt sich keine Funktion sinnvoll priorisieren. Mit ihr wird die Diskussion einfacher: Jede Funktion, die nicht zur Beantwortung beiträgt, kommt auf die Liste für später.

Entscheidungsrahmen für den Umfang

Bewährt hat sich eine Einteilung in drei Gruppen.

Unverzichtbar

• Registrierung, Anmeldung, Passwort-Zurücksetzen und Einladungen von Kollegen
• Organisationen als Eigentümer der Daten, mit zwei oder drei festen Rollen
• der Kernprozess, vollständig und belastbar umgesetzt
• E-Mail-Benachrichtigungen für Ereignisse, auf die Nutzer reagieren müssen
• ein interner Administrationsbereich für Support und Datenkorrekturen
• Ereignis-Tracking für die wichtigsten Schritte des Kernprozesses

Nur bei konkretem Bedarf der ersten Kunden

• Single Sign-on, wenn größere Unternehmen es im Einkauf voraussetzen
• eine einzige Integration, ohne die der Kernprozess nicht funktioniert, etwa mit dem ERP oder einer Buchhaltungssoftware
• automatische Abrechnung, wenn das Produkt ohne Vertriebsgespräch verkauft wird

Bewusst später

• frei definierbare Rollen und Rechte
• Berichtsgenerator und individuelle Dashboards
• öffentliche API für Kunden
• White-Label und mehrere Sprachen

Architektur: was Laravel und das Frontend übernehmen

Aktuelle Laravel-Versionen laufen auf PHP 8.3 oder 8.4 und bringen für ein SaaS-Backend die wesentlichen Bausteine mit: offizielle Starter-Kits für die Authentifizierung, Queues für E-Mails, Importe und Berichte, einen Scheduler für wiederkehrende Aufgaben, Cashier für Abonnements über Stripe oder Paddle und Pennant für Feature-Flags. Autorisierungsregeln lassen sich in Policies bündeln, statt über Controller verstreut zu werden.

Für das Frontend bietet Laravel Starter-Kits sowohl für React als auch für Vue an, jeweils auf Basis von Inertia. Die Entscheidung folgt deshalb vor allem praktischen Kriterien:

• Vorhandenes Wissen im Team wiegt schwerer als jeder Framework-Vergleich.
• Vue.js ist bei formular- und tabellenlastigen Fachanwendungen oft schneller umzusetzen und für Backend-Entwickler leicht lesbar.
• React bietet das größere Ökosystem an Komponentenbibliotheken, was beim späteren Ausbau eines eigenen Frontend-Teams hilft.
• TypeScript sollte in beiden Fällen gesetzt sein.

Inertia erspart dem MVP eine separate API-Schicht: Routing, Sitzungen und Validierung bleiben serverseitig. Eine eigenständige JSON-API ist erst dann nötig, wenn eine mobile App, eine Kunden-API oder mehrere Oberflächen zum ersten Release gehören. Wie wir diese Kombination in Portalprojekten einsetzen, zeigt der Beitrag zum B2B-Kundenportal mit Laravel und Vue.js.

Mandantenfähigkeit richtig anlegen

Die Frage, wie Daten einem Kunden zugeordnet sind, ist die teuerste, wenn sie zu spät gestellt wird. Drei Varianten sind verbreitet:

1. Gemeinsame Datenbank mit Mandanten-ID in jeder fachlichen Tabelle. Für die meisten MVPs die richtige Wahl, sofern die Filterung zentral erzwungen wird, etwa über ein Global Scope und Middleware, und nicht in jeder Abfrage einzeln.
2. Eigenes Datenbankschema je Mandant. Stärkere Trennung, aber aufwendigere Migrationen und Auswertungen über alle Kunden.
3. Eigene Datenbank oder Instanz je Kunde. Sinnvoll, wenn einzelne Großkunden das vertraglich verlangen. Für ein MVP meist zu schwer.

Wichtig ist, Variante 1 so zu bauen, dass ein späterer Wechsel für einzelne Kunden möglich bleibt: keine Abfragen über Mandanten hinweg in der Fachlogik, eindeutige IDs, klar getrennte Dateiablage je Mandant.

Datenschutz und Vertrauen im DACH-Markt

Deutsche Mittelständler fragen früh nach dem Umgang mit ihren Daten. Ein MVP, das diese Fragen nicht beantworten kann, verliert Zeit im Einkaufsprozess. Vorbereitet sein sollten:

• ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO als Vorlage,
• eine Liste der Unterauftragsverarbeiter, also Hosting, E-Mail-Versand, Monitoring und Zahlungsanbieter,
• Hosting in der EU und eine klare Aussage zu Backups und deren Standort,
• ein Konzept für Löschung und Datenexport beim Vertragsende,
• ein nachvollziehbares Protokoll wichtiger Änderungen, das auch Kunden selbst einsehen können.

Das alles ist mit überschaubarem Aufwand machbar, wenn es von Anfang an Teil der Planung ist.

Betrieb ab dem ersten Kunden

Sobald zahlende Kunden das Produkt nutzen, gelten andere Maßstäbe als im Prototyp. Mindestens nötig sind eine automatisierte Deployment-Pipeline mit Tests, eine getrennte Staging-Umgebung mit anonymisierten oder künstlichen Daten, tägliche Backups mit regelmäßig geprüfter Wiederherstellung, Fehler-Monitoring mit Benachrichtigung und eine einfache Statusseite oder zumindest ein definierter Kommunikationsweg bei Störungen. Diese Punkte kosten wenig, wenn sie im Fundament eingeplant sind, und verhindern, dass der erste Ausfall das Vertrauen der Pilotkunden beschädigt.

Typische Fehler

• Skalierung vor Nutzern. Microservices und aufwendige Infrastruktur lösen Probleme, die ein MVP noch nicht hat. Eine sauber strukturierte Laravel-Anwendung mit Queues trägt weit.
• Geschäftslogik im Controller. Wer den Kernprozess in eigene Klassen auslagert, kann ihn testen und später über eine API anbieten.
• Kein Administrationsbereich. Ohne ihn wird jede Supportanfrage zu einer Datenbankabfrage durch einen Entwickler.
• Tarife nicht als Daten. Auch bei manueller Rechnungsstellung sollten Tarif und Limits im System hinterlegt und im Code geprüft werden.
• Keine Messpunkte. Ohne Daten über den Kernprozess entscheidet nach dem Launch wieder das Bauchgefühl.

Ablauf in Phasen

1. Discovery: Leitfrage, Kernprozess, Datenmodell und ein klickbarer Prototyp der wichtigsten Masken, abgestimmt mit zwei oder drei Pilotkunden.
2. Fundament: Authentifizierung, Organisationen, Rollen, Mandantentrennung, Administrationsbereich, Deployment und Monitoring.
3. Kernprozess: vollständig umgesetzt, mit Feature-Tests für den Weg, für den Kunden bezahlen.
4. Pilotbetrieb: echte Nutzung durch die Pilotkunden, wöchentliche Auswertung und Anpassung.
5. Öffnung für weitere Kunden, Priorisierung neuer Funktionen anhand von Nutzungsdaten statt nach der ursprünglichen Wunschliste.

Wenn Sie das Team für diese Phasen extern besetzen möchten, finden Sie im Beitrag Laravel Software House in Polen für B2B-Systeme Hinweise zur Zusammenarbeit über Ländergrenzen hinweg.

Nächster Schritt

Formulieren Sie die Leitfrage Ihres MVP in einem Satz und beschreiben Sie den Kernprozess aus Sicht eines Kunden in fünf bis acht Schritten. Ordnen Sie danach alle geplanten Funktionen den drei Gruppen oben zu. Mit dieser Unterlage lässt sich ein realistischer Umfang schätzen. Mehr zu unserem Vorgehen lesen Sie auf der Seite Webanwendungen und SaaS. Wenn Sie Ihre Planung gemeinsam prüfen möchten, sprechen Sie uns an.