SaaS-Produktentwicklung

Was umfasst die SaaS-Produktentwicklung?

SaaS-Produktentwicklung bedeutet, ein Software-Produkt zu entwerfen, zu entwickeln und zu veröffentlichen, das viele Kunden im Abo nutzen und das über das Internet bereitgestellt wird. Nutzer installieren das Produkt nicht auf ihrem Computer; sie melden sich im Browser an, wählen einen Tarif und zahlen regelmäßig. Sie wiederum bieten ein einziges Produkt vielen Unternehmen an, ohne für jeden Kunden eine eigene Installation vorzunehmen.

Diese Arbeit besteht nicht nur aus Programmieren. Zu verstehen, ob die Idee ein echtes Problem löst, die erste Version im richtigen Umfang zu halten, die Abo-Infrastruktur aufzubauen, Kundenkonten sicher voneinander zu trennen und das Produkt nach dem Launch anhand von Nutzungsdaten weiterzuentwickeln, gehört ebenfalls zum SaaS-Entwicklungsprozess.

Was unterscheidet sie von individueller Software?

Eine Software, die Sie für Ihr eigenes Unternehmen entwickeln lassen, hat nur einen Kunden: Sie. In einem Projekt zur SaaS-Produktentwicklung wird das entstehende Produkt dagegen von vielen verschiedenen Unternehmen mit ihren eigenen Daten genutzt. Dieser Unterschied beeinflusst jede Entscheidung, von der Datentrennung über die Preisgestaltung bis zu Support-Prozessen und Update-Politik. Wenn Sie nur ein System für Ihre eigenen Abläufe suchen, können individuelle Webanwendungen der bessere Ausgangspunkt sein.

Der Unterschied des SaaS-Geschäftsmodells

Im Abo-Modell sammelt sich der Umsatz nicht im Moment des Verkaufs, sondern über Monate an. Der Marketing- und Vertriebsaufwand, den man für die Gewinnung eines Kunden betreibt, zahlt sich erst aus, wenn der Kunde das Produkt eine gewisse Zeit weiter nutzt. Deshalb ist bei Entscheidungen in der SaaS-Produktentwicklung das Halten bestehender Kunden ebenso wichtig wie die Gewinnung neuer; eine Verbesserung, die die Kündigungsquote senkt, kann wertvoller sein als eine neue Funktion.

Für wen passt das?

SaaS-Produktentwicklung passt meist zu diesen Profilen:

• Gründerinnen und Gründer, die das wiederkehrende Problem einer Branche gut kennen und daraus ein Produkt machen möchten.
• Unternehmen, die eine für das eigene Geschäft genutzte Methode oder ein Werkzeug auch anderen Firmen anbieten möchten.
• Agenturen und Beratungen, die eine bisher als Beratung erbrachte Leistung mit Software mehr Kunden zugänglich machen möchten.
• Softwareunternehmen, die ihre installierte Software auf ein cloudbasiertes Abo-Modell umstellen möchten.

MVP-Planung: Wo beginnt die SaaS-Produktentwicklung?

Ein MVP (Minimum Viable Product) ist die erste Version, die den grundlegenden Wert der Idee liefert und mit echten Nutzern getestet werden kann. Ziel ist nicht, jede Funktion zu bauen, sondern auf dem kürzesten Weg herauszufinden, ob das Kernversprechen des Produkts funktioniert. Ein häufiges Problem in Projekten zur SaaS-Produktentwicklung ist, dass die erste Version monatelang vergrößert wird und spät auf Nutzer trifft.

Der Ablauf Schritt für Schritt

SaaS-Entwicklungsprojekte führen wir in einer Reihenfolge durch, in der das in jedem Schritt Gelernte in den nächsten mitgenommen wird:

1. Discovery: Wir klären gemeinsam die Zielkunden, das zu lösende Problem, die Wettbewerber und das Erlösmodell.
2. Validierung: Durch Gespräche mit potenziellen Nutzern und Prototyp-Tests suchen wir nach der Resonanz der Idee.
3. MVP-Umfang: Wir halten Funktionen, Tarife und zu messende Kennzahlen der ersten Version schriftlich fest.
4. Design und Prototyp: Registrierung, erste Nutzung und Hauptabläufe testen wir mit anklickbaren Bildschirmen.
5. Entwicklungszyklen: Wir entwickeln das Produkt in kurzen Zyklen und gehen am Ende jedes Zyklus die lauffähige Version gemeinsam durch.
6. Geschlossener Test: Wir testen das Produkt mit einer begrenzten Zahl von Nutzern unter realen Bedingungen und sammeln Feedback.
7. Launch: Wir öffnen das Produkt für alle, samt Zahlungsinfrastruktur und Support-Kanälen.

Zuerst das Problem validieren

Bevor Sie in die SaaS-Entwicklung investieren und bevor Code geschrieben wird, sollten diese Fragen klar beantwortet sein: Wer ist der Zielkunde? Wie löst er das Problem heute? Womit ist er an der bestehenden Lösung unzufrieden? Ist er bereit, für eine bessere Lösung zu zahlen? Gespräche mit potenziellen Kunden, ein anklickbarer Prototyp oder eine einfache Seite für Vorab-Anmeldungen helfen Ihnen, die Antworten auf diese Fragen zu bekommen, ohne Entwicklungskosten zu verursachen.

Den Umfang der ersten Version eingrenzen

Bei der Festlegung des MVP-Umfangs empfehlen wir, die Funktionen in drei Gruppen zu teilen:

• Zwingend: Funktionen, die das Kernversprechen des Produkts erfüllen und ohne die das Produkt sinnlos bleibt.
• Nötig für das Vertrauen: Bausteine, die dafür sorgen, dass Nutzer dem Produkt vertrauen, wie sicherer Login, Zahlung, Backup und grundlegende Hilfeinhalte.
• Kann später kommen: Erweiterte Reports, zusätzliche Integrationen, Anpassungsoptionen und alles, was man mit „wäre nett“ umschreibt.

Funktionen der dritten Gruppe kommen in eine Roadmap und werden nach echter Nutzernachfrage geordnet. So fließt das Budget der SaaS-Entwicklung nicht in Funktionen, die niemand nutzt.

Die Preisgestaltung früh testen

Der Preis wirkt wie eine Entscheidung, die man nach Fertigstellung des Produkts trifft, beeinflusst aber den Umfang des Produkts direkt. Welche Funktionen in welchem Tarif enthalten sind, ob es einen kostenlosen Tarif gibt und ob der Preis pro Nutzer oder nach Nutzungsmenge bestimmt wird, sollte in der MVP-Phase besprochen werden. In der SaaS-Produktentwicklung ist es ein praktischer Weg, Annahmen zu testen, die Preisseite früh zu veröffentlichen und das Interesse zu messen.

Kennzahlen, die von Anfang an gemessen werden

Welche Daten ab dem Launch-Tag beobachtet werden, sollte in der MVP-Planung entschieden werden. Wie viele Menschen sich registrieren, wie viele davon die Kernfunktion des Produkts nutzen, wie viele Nutzer am Ende der Testphase in einen kostenpflichtigen Tarif wechseln und an welchem Punkt Kunden, die ihr Abo kündigen, aussteigen, bilden die Grundlage für Entscheidungen in der SaaS-Produktentwicklung.

Architekturentscheidungen für die SaaS-Entwicklung

Die Architektur eines SaaS-Produkts soll dasselbe Produkt vom ersten Kunden bis zu Hunderten sicher bereitstellen können. Manche Entscheidungen der ersten Version lassen sich später leicht ändern; andere, etwa wie Kundendaten getrennt werden, nachträglich zu ändern, erfordert großen Aufwand. Diese Entscheidungen besprechen wir im SaaS-Entwicklungsprozess ab dem ersten Tag.

Mandantenfähige Struktur

Bei SaaS-Produkten wird jedes Kundenunternehmen als „Mandant“ (Tenant) betrachtet. Die Daten der Mandanten können in derselben Datenbank über eine Kundenkennung getrennt, auf demselben Server in getrennten Schemas oder in komplett getrennten Datenbanken gehalten werden. Jeder Ansatz hat bei Kosten, Wartung und Isolation andere Vor- und Nachteile. Welcher Weg auch gewählt wird: Dass ein Kunde unter keinen Umständen die Daten eines anderen Kunden sehen kann, ist die grundlegende Sicherheitsregel im SaaS-Entwicklungsprozess.

Technologiewahl und Teamplanung

Bei SaaS-Entwicklungsprojekten gibt es bei der Technologiewahl eine eigene Frage: Soll das Produkt später von Ihrem eigenen Softwareteam weiterentwickelt werden? Wenn Sie Investoren gewinnen oder ein Team aufbauen wollen, sollten verbreitete Technologien bevorzugt werden, für die sich beim Ausschreiben von Stellen Bewerber finden. Programmiersprache, Framework und Datenbank wählen wir gemeinsam nach dieser Erwartung, den Anforderungen des Produkts und dem Budget aus; eine bestimmte Technologie setzen wir nicht bei jedem Produkt ein.

Sicherheit und Infrastruktur

Da ein SaaS-Produkt die Daten Ihrer Kunden trägt, gehört Sicherheit auch zum Verkaufsprozess; besonders Firmenkunden stellen dazu detaillierte Fragen. Während der Entwicklung nutzen wir als Referenz die Liste der OWASP Top 10, die die kritischsten Sicherheitsrisiken von Webanwendungen aufführt. Verschlüsselte Verbindung, sichere Passwortspeicherung, Zwei-Faktor-Authentifizierung als Option, regelmäßige Backups und die Protokollierung kritischer Vorgänge sollten ab der ersten Version eingeplant werden.

Auf Wachstum vorbereitet sein

Wächst das Produkt, erzeugen manche Kunden viel mehr Daten als andere und nutzen das System intensiver. Wenn aufwendige Aufgaben wie Berichterstellung und Massenimport in Hintergrundaufgaben ausgelagert werden, verhindert das, dass die intensive Nutzung eines einzelnen Kunden die anderen verlangsamt. In der SaaS-Produktentwicklung muss man nicht vom ersten Tag an eine große Infrastruktur aufbauen; wichtig ist, dass sich die Struktur beim Wachstum erweitern lässt, ohne sie von Grund auf neu zu schreiben.

Updates erreichen alle gleichzeitig

Bei einem SaaS-Produkt gibt es nur eine Version, und jedes Update betrifft alle Kunden gleichzeitig. Deshalb gehört es zu den Grundgewohnheiten der SaaS-Produktentwicklung, dass neue Funktionen zunächst nur für bestimmte Kunden freigeschaltet werden können, Datenbankänderungen mit der alten Version kompatibel sind und bei Problemen schnell zurückgerollt werden kann. Auch große Änderungen den Kunden vorab anzukündigen, schützt die Vertrauensbeziehung.

Abo- und Zahlungsinfrastruktur

Das Abo ist der am meisten unterschätzte Teil von Projekten zur SaaS-Produktentwicklung. Eine Karte einmal zu belasten ist leicht; schwierig ist es, ein stimmiges System aus Tarifen, Testzeiträumen, Upgrades, fehlgeschlagenen Zahlungen und Rechnungen aufzubauen.

Tarife und Limits

Tarife werden meist nach Nutzerzahl, Nutzungsmenge oder Funktionsumfang unterschieden. Welches Modell auch gewählt wird: Wie die Limits im Produkt umgesetzt werden, sollte von Anfang an entworfen werden: Was sieht der Nutzer, wenn das Limit erreicht ist? Werden neue Funktionen sofort freigeschaltet, wenn der Tarif erhöht wird? Damit Sie Ihr Preismodell ohne Codeänderung aktualisieren können, empfehlen wir, Tarif- und Limitangaben über den Admin-Bereich bearbeitbar zu halten.

Testzeitraum, Upgrade und Kündigung

• Testzeitraum: Ob die Kartendaten von Anfang an abgefragt werden und was am Ende des Zeitraums passiert.
• Tarifwechsel: Wie die Restlaufzeit bei einem Upgrade oder Downgrade mitten in der Periode berechnet wird.
• Kündigung: Ob das Abo sofort oder zum Periodenende endet und wie lange die Daten aufbewahrt werden.
• Jahreszahlung: Die Regeln für den Wechsel zwischen Monats- und Jahrestarifen.
• Gutscheine und Aktionen: Für welche Tarife und über wie viele Perioden Rabatte gelten.

Fehlgeschlagene Zahlungen

Karten laufen ab, Limits reichen nicht, Banken lehnen Transaktionen ab. Wenn bei einer wiederkehrenden Zahlung eine Abbuchung fehlschlägt, sollten Schritte wie erneute Versuche in bestimmten Abständen, die Information des Nutzers per E-Mail und die Weiterleitung zum Bildschirm für die Aktualisierung der Karte automatisch ablaufen. Ist dieser Ablauf nicht gut aufgebaut, können Sie Kunden, die mit Ihrem Produkt zufrieden sind, allein wegen eines Zahlungsproblems verlieren. Deshalb empfehlen wir, diesen Ablauf im Rahmen der SaaS-Produktentwicklung in die erste Version aufzunehmen.

Zahlungsdienstleister und Rechnung

Mit einem Zahlungsdienstleister zu arbeiten, der wiederkehrende Zahlungen und das Speichern von Karten (Tokenisierung) unterstützt, erlaubt es Ihnen, Abos zu verwalten, ohne Kartendaten auf Ihren eigenen Servern zu halten. Wenn Sie in der Türkei verkaufen, sollte auch die Ausstellung einer Rechnung nach jeder erfolgreichen Abbuchung Teil des Ablaufs sein; wird E-Fatura oder E-Arşiv (türkische elektronische Rechnungssysteme) genutzt, lässt sich dieser Schritt über die Anbindung an einen Integrator automatisieren. Wenn Sie ins Ausland verkaufen wollen, sollten Währung, Steuern und lokale Zahlungsmethoden zusätzlich bewertet werden.

Nutzerverwaltung und erste Erfahrung

Im SaaS-Entwicklungsprozess ist die Nutzerverwaltung mehr als der Login einer einzelnen Person. Der Kunde ist meist ein Unternehmen; innerhalb des Unternehmens gibt es mehrere Nutzer, unterschiedliche Berechtigungen und Teammitglieder, die im Lauf der Zeit ausscheiden oder dazukommen.

Teamkonten und Rollen

• Einladungsablauf: Der Kontoinhaber lädt Teamkollegen per E-Mail in das Produkt ein.
• Rollen: Berechtigungen werden über Rollen wie Kontoinhaber, Administrator und Standardnutzer getrennt.
• Nutzer entfernen: Der Zugang eines ausgeschiedenen Mitarbeiters lässt sich sofort sperren.
• Unternehmens-Login: Für große Kunden die Option der Einmalanmeldung (Single Sign-on) mit Google- oder Microsoft-Konten.

Die erste Nutzungserfahrung

Ob sich ein neu registrierter Nutzer in den ersten Sitzungen vom Wert des Produkts überzeugt, bestimmt das Ergebnis der Testphase maßgeblich. Deshalb sind Beispieldaten statt eines leeren Bildschirms, ein kurzer Einrichtungsassistent und Schritte wichtig, die den Nutzer zu seinem ersten sinnvollen Vorgang führen. Im SaaS-Entwicklungsprozess braucht dieser Ablauf mindestens so viel Aufmerksamkeit wie die Hauptfunktionen des Produkts.

Das Back-Office des Produkts

Neben dem Produkt, das Kunden sehen, braucht es auch eine Verwaltungsseite, die Ihr Team nutzt. Kundenkonten und Tarife einsehen, ein Abo verlängern, die Einstellungen eines Kontos mit Supportanfrage prüfen und die Nutzungszahlen des gesamten Produkts beobachten sind die Aufgaben dieses Bereichs. Im Plan der SaaS-Produktentwicklung wird das Back-Office oft vergessen, und nach dem Launch muss das Team direkt in die Datenbank eingreifen.

Daten, Datenschutz und KVKK

Unternehmen, die Ihr SaaS-Produkt nutzen, laden die Daten ihrer eigenen Kunden in Ihr System. In diesem Fall müssen nach dem türkischen Datenschutzgesetz Nr. 6698 (KVKK) die Rollen von Verantwortlichem und Auftragsverarbeiter richtig bestimmt und Verträge sowie Informationstexte entsprechend vorbereitet werden. Dass der Kunde seine Daten exportieren kann und seine Daten gelöscht werden können, wenn er sein Konto schließt, sollte ebenfalls als Produktfunktion eingeplant werden. Es ist sinnvoll, die letzte Prüfung der Vertrags- und Datenschutztexte einer Juristin oder einem Juristen zu überlassen.

Launch und danach: SaaS-Produktentwicklung ist eine fortlaufende Aufgabe

Wenn ein SaaS-Produkt live geht, ist die Arbeit nicht beendet, sondern es beginnt eine neue Phase. Nutzerfeedback, Nutzungsdaten und Kündigungsgründe bestimmen, was in der nächsten Version weiterentwickelt wird. Nach dem Launch empfehlen wir, Updates klein und häufig umzusetzen und jedes Update vor der Veröffentlichung zu testen.

• Nutzungsanalyse: Zeigt, welche Funktionen genutzt werden und wo Nutzer hängen bleiben.
• Fehlererfassung: Sorgt dafür, dass Fehler bemerkt werden, bevor ein Nutzer sie meldet.
• Feedback-Kanal: Bündelt Anfragen über ein Formular in der Anwendung oder ein Support-System an einer Stelle.
• Roadmap: Der regelmäßig aktualisierte Plan, in dem Anfragen nach Wert und Kosten geordnet sind.

Auch die Beobachtung von Infrastruktur, Bibliotheken und Sicherheits-Patches geht nach dem Launch weiter. Dafür können Sie unsere Leistung Wartung und technischer Support nutzen oder das Produkt an ein Team übergeben, das Sie selbst aufbauen. Muss Ihr Produkt mit Buchhaltungs-, CRM- oder E-Commerce-Systemen sprechen, kommen API- und Systemintegrationen ins Spiel.

Kundensupport und Hilfeinhalte

Bei einem Produkt im Abo-Modell ist der Support Teil des Produkts. Häufige Fragen, Schritt-für-Schritt-Hilfeartikel und ein aus dem Produkt erreichbares Supportformular sorgen dafür, dass der Nutzer sein Problem schnell löst und Ihr Team dieselben Fragen nicht immer wieder beantworten muss. Die Themen, die in den Supportanfragen hervortreten, sind auch für die Roadmap der SaaS-Produktentwicklung eine wertvolle Datenquelle.

Checkliste für den Launch

• Sind Nutzungsbedingungen, Datenschutzerklärung und KVKK-Texte online?
• Werden Registrierungs-, Passwort-Zurücksetzen- und Abo-E-Mails korrekt versendet?
• Wurden Szenarien für fehlgeschlagene Zahlungen und Kündigungen getestet?
• Werden Backups erstellt, und wurde die Wiederherstellung ausprobiert?
• Funktionieren Fehlererfassung und Nutzungsmessung?
• Über welchen Kanal und an wen gehen Supportanfragen?

Was den Leistungsumfang bestimmt

• Anzahl und Komplexität der Hauptfunktionen im MVP.
• Das Abo-Modell: Anzahl der Tarife, nutzungsbasierte Preisgestaltung, Regeln für Test und Gutscheine.
• Mandantenisolation und die Sicherheitserwartungen von Firmenkunden.
• Bedarf an fertigen Integrationen mit Buchhaltungs-, CRM-, Zahlungs- oder E-Mail-Diensten.
• Unterstützung für mehrere Sprachen und mehrere Währungen.
• Umfang der Report-Bildschirme für Kunden und des Back-Offices.

Häufige Fehler

• Entwickeln ohne Validierung: Monatelang Aufwand in ein Produkt stecken, für das niemand zahlen wird.
• Das MVP aufblähen: Die erste Version so zu vergrößern, dass sie jedes Szenario abdeckt.
• Das Abo für einfach halten: Fehlgeschlagene Zahlungen, Tarifwechsel und Abrechnung ans Ende zu schieben.
• Die Datentrennung später bedenken: Die Methode der Trennung von Kundendaten nach dem Launch zu ändern, ist schwierig und riskant.
• Ohne Messung veröffentlichen: Eine Roadmap aufzubauen, ohne zu wissen, welche Funktion funktioniert.

Häufig gestellte Fragen (FAQ)

Brauche ich für die SaaS-Produktentwicklung eine technische Mitgründerin oder einen technischen Mitgründer?

Für die erste Version ist das nicht nötig; Sie können das Produkt auch mit einem Entwicklungsteam umsetzen. Wächst das Produkt, ist es langfristig jedoch wichtig, dass jemand im Team die technischen Entscheidungen verantwortet.

Was ist der Unterschied zwischen MVP und fertigem Produkt?

Das MVP ist die kleinste Version, die den Kernwert des Produkts liefert, und wird gebaut, um mit echten Nutzern getestet zu werden. Das fertige Produkt entsteht mit der Zeit aus dem, was man aus diesen Tests lernt.

Kann ich Abo-Zahlungen in der Türkei entgegennehmen?

Ja. Mit einem Zahlungsdienstleister, der wiederkehrende Zahlungen unterstützt, lässt sich der Abo-Einzug durchführen, ohne Kartendaten auf Ihrem eigenen Server zu halten. Welcher Anbieter geeignet ist, hängt von Ihrem Geschäftsmodell und Ihrem Zielmarkt ab.

Wie lange dauert der SaaS-Entwicklungsprozess?

Die Dauer hängt vom MVP-Umfang, von der Komplexität des Abo-Modells und vom Integrationsbedarf ab. Sobald der Umfang feststeht, erstellen wir einen in Phasen gegliederten Zeitplan.

Was bestimmt den Umfang der SaaS-Entwicklung?

Den Umfang bestimmen vor allem die Anzahl der Funktionen im MVP, die Komplexität des Abo-Modells, der Integrationsbedarf und die Sicherheitserwartungen von Firmenkunden. Das Angebot für die SaaS-Entwicklung erstellen wir, sobald diese Punkte geklärt sind.

Können wir das Produkt später an unser eigenes Team übergeben?

Ja. Lesbarer Code, verbreitete Technologien und Dokumentation erleichtern die Übergabe; wir empfehlen, die Übergabebedingungen zu Projektbeginn zu besprechen.

Bewerten wir Ihre Produktidee gemeinsam

Ob Ihre Idee noch in einem Notizbuch steht oder schon ein Plan ist, in dem Sie die Wettbewerber untersucht haben: Der erste Schritt ist ein kurzes Gespräch. Wir sprechen über Ihren Zielkunden, das Problem, das Sie lösen, und Ihr Erlösmodell und rahmen gemeinsam die passende erste Version für Ihre SaaS-Produktentwicklung ein. Sie erreichen uns über unsere Kontaktseite.