De
En
Fr
It
Es
Uk
Was baut ein Unternehmen für individuelle SaaS-Entwicklung tatsächlich?
Ein Unternehmen für individuelle SaaS-Entwicklung baut das Produkt, das Ihre Kunden nutzen, und die Maschinerie drumherum, mit der Sie es als Abo verkaufen können: Konten, Teams, Tarife, Abrechnung, Berechtigungen, Onboarding, ein Admin-Backoffice, Integrationen und ein Hosting, das jeden Kunden aus einer Codebasis bedient. Die sichtbaren Funktionen machen oft weniger als die Hälfte der Arbeit aus. Der Rest ist das, was das Produkt sicher an den zehnten und den hundertsten Kunden verkaufbar macht.
Lytvynov Production entwickelt SaaS-Produkte auf PHP/Symfony, React oder Vue und PostgreSQL oder MySQL, bei Bedarf mit Mobile-Apps in React Native oder Flutter. Wir arbeiten mit Startups, die ein erstes Produkt bauen, und mit B2B-Unternehmen, die ein internes Tool in etwas Verkaufbares verwandeln.
Welche Bausteine braucht jedes SaaS-Produkt?
Jedes SaaS-Produkt braucht dieselben Bausteine, und wer früh entscheidet, wie viel von jedem gebaut wird, spart später Monate. So teilen wir sie üblicherweise in Phasen auf:
| Baustein | SaaS-MVP | Version für den B2B-Vertrieb | Skalierungsphase |
|---|---|---|---|
| Konten und Authentifizierung | E-Mail- und Social-Login | Teams, Einladungen, SSO (Google, Microsoft, SAML) | SCIM-Provisioning, Enterprise-SSO |
| Mandantenfähigkeit | Gemeinsame Datenbank, Mandanten-ID in jeder Zeile | Mandantenbewusstes Caching, Einstellungen pro Mandant | Option einer dedizierten Datenbank für große Kunden |
| Rollen und Berechtigungen | Eigentümer und Mitglied | Eigene Rollen, Berechtigungen pro Objekt | Audit-Log, Freigabe-Workflows |
| Abrechnung | Ein Tarif über Stripe Checkout | Tarife, Testphasen, Nutzerplätze, Nutzungslimits, Mahnwesen | Nutzungsbasierte Preise, Rechnungsstellung, Steuerbehandlung |
| Admin-Backoffice | Generierter Admin für Ihr Team | Kundensuche, Impersonation, Erstattungen | Reporting, Feature Flags pro Mandant |
| Integrationen | Eine zentrale Integration | Öffentliche API, Webhooks | Marketplace-Apps, einbettbare Widgets |
| Betrieb | CI/CD, Backups, Fehler-Tracking | Monitoring, Staging pro Branch | Autoscaling, Richtlinien zur Datenaufbewahrung |
Wie sollte Mandantenfähigkeit gestaltet werden?
Mandantenfähigkeit sollte ab dem ersten Tag eingeplant werden, auch wenn Sie nur einen Kunden haben, denn eine nachträgliche Mandantentrennung in einem Live-Produkt ist teuer und riskant. Die Grundregel ist einfach: Jede Abfrage, die Kundendaten berührt, muss auf einen Mandanten eingeschränkt sein, und diese Einschränkung muss vom Framework erzwungen werden, statt dass jeder Entwickler daran denken muss.
In Symfony setzen wir das mit einem Tenant-Resolver (aus Subdomain, Header oder Nutzersitzung) und einem Doctrine-Filter um, der die Mandantenbedingung automatisch zu jeder Abfrage hinzufügt, plus Tests, die versuchen, Daten eines anderen Mandanten zu lesen, und scheitern müssen. Für die meisten Produkte ist eine gemeinsame Datenbank mit Mandantenspalte der richtige Start. Ein Schema oder eine Datenbank pro Mandant kommt hinzu, wenn Enterprise-Kunden physische Trennung oder regionale Datenhaltung verlangen. Wir kapseln das Mandantenmodell hinter einer Schnittstelle, sodass der spätere Umzug eines großen Kunden in eine dedizierte Datenbank eine Migration ist und kein Neubau.
Wie funktionieren Abo-Abrechnung und Preisgestaltung in einem SaaS?
SaaS-Abrechnung funktioniert am besten, wenn ein Abrechnungsanbieter das Geld verwaltet und Ihr Code die Produktregeln. Stripe Billing, Paddle oder Chargebee speichern Karten, belasten sie, erstellen Rechnungen und kümmern sich um Steuern. Ihre Anwendung hört auf deren Webhooks und entscheidet, was jeder Kunde darf: welcher Tarif, wie viele Nutzerplätze, welche Limits, was während einer Testphase oder nach einer fehlgeschlagenen Zahlung passiert.
Wir haben bereits zahlungsintensive Produkte gebaut. Ritoria, eine Plattform für Fortsetzungsliteratur, betrieb eine In-App-Währung, die über Stripe, PayPal oder Braintree gekauft und für Kapitel, Geschenke und Spenden ausgegeben wurde, mit einem Transaktionsjournal, Empfehlungsprämien und Auszahlungen an Autoren und Cover-Designer. Lehren aus dieser Art von Arbeit: Führen Sie ein Journal jeder Geldbewegung, machen Sie die Webhook-Verarbeitung idempotent, und lassen Sie den Zugang eines Nutzers nie davon abhängen, dass ein einzelner Webhook pünktlich ankommt.
Was sollte das SaaS-Admin-Panel enthalten?
Das SaaS-Admin-Panel sollte es Ihrem Team ermöglichen, eine Kundenfrage zu beantworten, ohne einen Entwickler anzurufen. Das heißt: jeden Kunden finden, seinen Tarif und seine Nutzung sehen, Einstellungen ändern, erstatten und sehen, was er sieht.
Für frühe Produkte generieren wir den Admin aus dem Datenmodell (EasyAdmin in Symfony eignet sich gut), was Ihnen in wenigen Tagen ein funktionierendes Backoffice liefert. Das Backoffice von Ritoria wuchs auf 38 Bereiche für Inhaltszeilen, Banner, Genres, FAQ, SEO-Texte und jede Entität im System, ohne separates individuelles Admin-Projekt. Wenn das Produkt wächst, ergänzen wir die Teile, die sich am schnellsten auszahlen: Impersonation mit Audit-Trail, Feature Flags pro Mandant und Dashboards für Aktivierung und Abwanderung.
Wie plant man eine SaaS-Roadmap vom MVP bis zur Skalierung?
Eine SaaS-Roadmap sollte danach geordnet sein, was Umsatz blockiert, nicht danach, was am spannendsten zu bauen ist. Wir planen meist drei Phasen:
- SaaS-MVP (10 bis 14 Wochen): ein Kernablauf, Registrierung, ein Tarif, Stripe Checkout, generierter Admin. Ziel: erste zahlende Kunden. Siehe MVP-Entwicklung.
- Verkaufbar an Unternehmen (die nächsten 3 bis 5 Monate): Teams und Rollen, mehrere Tarife, Testphasen, SSO, öffentliche API und Webhooks, Audit-Log, Onboarding-E-Mails. Ziel: den Sicherheitsfragebogen eines B2B-Einkäufers bestehen.
- Skalierung: Performance-Arbeit, nutzungsbasierte Preise, Integrations-Marketplace, dedizierte Mandanten, KI-Funktionen auf Basis der Daten Ihrer Kunden.
Die Roadmap wird jeden Monat mit der realen Nutzung abgeglichen. Funktionen, nach denen kein zahlender Kunde fragt, rutschen nach unten, egal wie früh sie geplant waren.
Welche SaaS-Produkte haben wir gebaut?
Wir haben SaaS- und Abo-Produkte für unser eigenes Portfolio und für Kunden gebaut:
- AI Resume Master: unser eigener KI-Lebenslauf-Builder mit SaaS- und Werbemodell, entwickelt in rund drei Monaten, heute bei 50.000 monatlich aktiven Nutzern.
- Ritoria: eine Symfony-Plattform mit 54 Domänen-Entitäten, drei Zahlungsanbietern, einem Marktplatz und einer Social-Schicht auf Englisch und Arabisch, die zweieinhalb Jahre auf AWS in Produktion lief, mit 292 Commits und 120 Datenbankmigrationen.
- Sportveranstaltungskalender: eine Freemium-Plattform mit B2B-Lizenzierung für ein britisches Sports-Tech-Unternehmen, einschließlich APIs und einbettbarer Widgets für Partnerplattformen sowie einer Parsing-Engine, die Hunderte externer Kalender vereinheitlicht.
Was kostet individuelle SaaS-Entwicklung?
Die Kosten individueller SaaS-Entwicklung hängen von der Tiefe der Mandantenfähigkeit, der Komplexität der Abrechnung, der Anzahl der Integrationen und den Compliance-Anforderungen ab. Ein SaaS-MVP dauert typischerweise 10 bis 16 Wochen, ein B2B-fähiges Produkt 4 bis 8 Monate, und die laufende Entwicklung danach läuft über ein monatliches Budget nach Teamgröße.
Nach einem kurzen Scoping-Gespräch erhalten Sie einen Festpreis pro Meilenstein. Ein SaaS-Produkt beginnt bei uns ab etwa 10.000 USD; unser Leitfaden zu den Kosten der MVP-Entwicklung schlüsselt das erste Release auf. Zur Stack-Entscheidung erklärt unser Vergleich Symfony vs. Laravel für SaaS, warum wir für langlebige Produkte standardmäßig Symfony wählen.
Wann sollten Sie kein individuelles SaaS bauen?
Sie sollten kein individuelles SaaS bauen, wenn ein bestehendes Produkt den Großteil Ihrer Anforderungen abdeckt und Ihr Vorteil nicht in der Software selbst liegt. Wenn Sie ein internes CRM, einen Helpdesk oder ein Projekt-Tracking für Ihr eigenes Team brauchen, ist der Kauf eines bestehenden Tools meist günstiger. Individuelle SaaS-Entwicklung lohnt sich, wenn die Software das ist, was Sie verkaufen, wenn Ihr Ablauf so spezifisch ist, dass Standardtools teure Umwege erzwingen, oder wenn Sie Datenmodell und Integrationen langfristig selbst besitzen müssen. Ein nützlicher Test: Wenn ein Wettbewerber Ihr Angebot kopieren könnte, indem er dasselbe Abo kauft, ist die Software nicht Ihr Burggraben, und sie selbst zu bauen macht sie auch nicht dazu.
Wie wir in SaaS-Projekten arbeiten
Wir beginnen mit einer kurzen Scoping-Phase: Mandanten, Rollen, Tarife, Integrationen und das erste Release, schriftlich festgehalten und geschätzt. Dann liefern wir in Meilensteinen mit einer Demo pro Woche, Code in Ihren Repositories und Infrastruktur in Ihren Cloud-Konten. Senior-Engineers verantworten die Architektur und prüfen jede Änderung; intern nutzen wir KI-Coding-Agenten, um die Lieferung zu beschleunigen. Viele Kunden bleiben nach dem Launch bei uns als dediziertes Team für Symfony-Entwicklung.
Sagen Sie uns, was Ihr Produkt tut und wer dafür bezahlt, und wir schlagen ein erstes Release vor. Buchen Sie ein SaaS-Scoping-Gespräch.
