Was ich gelernt habe, als ich ein Jahr lang allein ein SaaS betrieben habe

xguru · 2022-03-07T10:39:09+09:00

Erfahrungsbericht darüber, wie ich den Uptime-Checker OnlineOrNot in 7 Tagen mit Next.js + AWS Lambda gebaut, gelauncht und ein Jahr lang betrieben habe Wie hält man einen Service am Leben, obwohl es 200 Konkurrenten gibt? Ich arbeite an Werktagen unter der Woche genau zwei Stunden daran Fokus auf Funktionen, die den Schmerz der Kunden lösen Extrem (ruthlessly) iterativ. Wenn sich eine Funktion nicht in 2 Stunden umsetzen lässt, den Umfang verkleinern, trotzdem deployen und das wiederholen ✓ Lektionen aus 1 Jahr Es geht darum, Probleme zu lösen, nicht SaaS-Abos zu verkaufen Aus Kundensicht denken Nicht: "Wenn ich diese Funktion baue, kommen die Kunden von selbst!", sondern: "Ich muss den Kunden helfen, dieses nervige Problem zu lösen" SaaS ist nur eine von vielen Möglichkeiten, ein Problem zu lösen Dokumentation ist Teil der User Experience Man sagt zwar: "Entwickler lesen keine Dokumentation", aber das stimmt nur teilweise Sie lesen nicht, sondern überfliegen die Überschriften Für Mobile bauen Entgegen der allgemeinen Annahme über B2B-SaaS erledigen Menschen viel Arbeit auf dem Smartphone Bei OnlineOrNot kommen etwa 50 % über Mobile Sie erstellen schnell auf dem Smartphone ein Konto, fügen ein paar zu überwachende Seiten hinzu und schauen später gelegentlich am Laptop/Desktop nach Sechs Monate lang gab es keinen Mobile-Support, und Leute, die sich über das Smartphone registriert hatten, sind schnell abgesprungen Als ich schließlich responsive Mobile-Seiten gebaut habe, kommen jetzt laufend neue Mobile-Nutzer dazu Die Leute fragen, wie sie von dir erfahren haben Eine der wertvollsten Code-Änderungen war die Frage an neue Nutzer: "Wie haben Sie von OnlineOrNot erfahren?" Es gibt viele Kanäle, um potenzielle Kunden anzuziehen, und man muss wissen, welche man stärker gewichten sollte Manchmal muss man Fehler selbst machen Ich habe viele Bücher gelesen, um die Fehler anderer nicht zu wiederholen, aber manchmal muss man Fehler selbst machen Als ich auf der Hacker-News-Startseite landete, kamen 6000 Leute. Ein paar Hundert wollten sich registrieren, aber am Ende meldeten sich nicht einmal 10 wirklich an — da war klar, dass etwas nicht stimmte Das Registrierungsformular hatte eine Absprungrate von 75 %. Durch A/B-Tests (mit meinem eigenen DeployWithFlags) und zusätzliche OAuth-Provider sank sie auf 50 % Pricing ist wirklich schwer Ist der Preis zu hoch, springen Leute ab, die erwarten, dass deine App alles für sie erledigt Ist der Preis zu niedrig, gibt es Kunden, die für 9 $ bezahlt haben und dann wollen, dass du die App neu schreibst Schwierigen Kunden Geld zurückgeben, Preise erhöhen und weitermachen Sei darauf vorbereitet, beim Pricing viel zu experimentieren Nicht zu sehr auf MRR (Monthly Recurring Revenue) fixieren MRR ist am Anfang ein sehr schlechtes Maß dafür, wie sich das Business entwickelt Dinge, die man vor ein paar Wochen verbessert hat, wirken sich erst jetzt auf den MRR aus. Bis man viele Kunden hat, ist es schwer zu erkennen, ob Änderungen tatsächlich einen Effekt hatten DAU oder einige Customer-Success-Metriken (Seitenprüfungen, Bildgenerierung usw.) waren hilfreicher als MRR Diese Werte zeigen, ob echte Nutzer das Produkt wirklich verwenden und ob es ihnen Nutzen bringt Auch im Paid-Tier braucht es eine kostenlose Testphase Ein kostenloses Tier ist ein guter Weg, Menschen anzuziehen und sie über dein Produkt sprechen zu lassen Wenn das Paid-Tier aber viel besser ist als das kostenlose, brauchst du eine Möglichkeit, den Leuten dieses "Good Stuff" im Paid-Tier kostenfrei probieren zu lassen Bis ich das verstanden habe, vergingen 11 Monate Es gibt zwar ein kostenloses Tier, aber 95 % der neuen Nutzer wählen die kostenlose Testversion des Pro-Tiers Mehr Traffic zu holen ist schwer, das Verhalten des bestehenden Traffics zu ändern ist leichter Im Internet Aufmerksamkeit zu bekommen, ist ein langes, langsames Spiel Wenn du über mehrere Monate hinweg konsequent gutes Content-Marketing machst, wächst die Zahl der Leser von 1–2 pro Tag auf Hunderte Die Zahl der Besucher auf einer Website zu erhöhen, ist wirklich nicht einfach Was die Leute aber tun, wenn sie auf deiner Website sind, kannst du beeinflussen — und zwar sofort (So etwas wie zusätzliche OAuth-Login-Provider hinzuzufügen) Content-Marketing verschafft dir Zeit Wenn du in Content-Marketing investierst, kann das Business für eine gewisse Zeit von selbst weiterlaufen Über ein Jahr hinweg gingen mehrere ältere Beiträge viral und zogen Zehntausende Besucher an. Auch ohne dass ich etwas tue, kommen organisch etwa 1500 Menschen, um diese Beiträge zu lesen Klein und häufig deployen Leute schlagen dir vielleicht bestimmte Funktionen vor, um das Produkt zu verbessern, aber wahrscheinlich werden sie diese Funktionen selbst gar nicht nutzen Meist wollen sie nur helfen und haben ähnliche Funktionen in anderen Produkten gesehen Wenn du zum ersten Mal ein SaaS betreibst, freust du dich darüber, dass dir Leute Feedback geben, und willst sofort Funktionen für sie bauen Ich sage nicht, dass du diese Funktionen nicht bauen sollst (ich habe diesen Rat selbst bekommen und die Funktion, die niemand nutzte, trotzdem gebaut) Frage, wie genau sie die Funktion nutzen würden, frage andere Kunden, wie sie das Problem aktuell lösen, baue die kleinstmögliche Version und schau dann, ob andere Nutzer sie tatsächlich verwenden Du willst doch keine Funktion bauen, die nur eine Person benutzt? Es ist viel weniger schmerzhaft, eine Funktion zu entfernen, in die du nur ein paar Stunden investiert hast und die niemand will, als etwas zu verwerfen, in das Monate Arbeit geflossen sind Erst deployen, über Skalierung später nachdenken In der ersten Version von OnlineOrNot habe ich die Architektur überhaupt nicht optimiert (Bei jedem Uptime-Check wurde eine DB-Verbindung offengehalten, was es schwer machte, viele Nutzer zu bedienen) Außerdem ist es mir lieber, wenn Leute sich über eine unfertige UI wundern, als dass ich etwas baue, das niemand braucht Später habe ich die Architektur neu entworfen, sodass eine einzige kleine RDS-Instanz pro Woche mehrere Millionen Vorgänge verarbeiten konnte Es ist schwieriger als gedacht, viel Zeit in die eigentliche Problemlösung zu stecken Von der Zeit, die ich in einem Jahr mit Programmieren verbracht habe, ging nur etwa die Hälfte in die tatsächliche Lösung des Problems, das ich lösen wollte Die andere Hälfte floss in den Aufbau der SaaS-Plattform Man braucht SaaS-Plattform-Dinge wie verschiedene Arten von Authentifizierung, Testphasen, Onboarding, Team-Management, Rechnungsverwaltung und Lifecycle-E-Mails Vieles kann man auslagern (ohne Stripe hätte ich das Produkt wahrscheinlich nicht als Abo verkaufen können) Aber es gibt immer Dinge, die einem nicht gefallen, und wenn man sie anders handhaben will, muss man sie selbst bauen

(onlineornot.com)

46 Punkte von xguru 2022-03-07 | 3 Kommentare | Auf WhatsApp teilen

Erfahrungsbericht darüber, wie ich den Uptime-Checker OnlineOrNot in 7 Tagen mit Next.js + AWS Lambda gebaut, gelauncht und ein Jahr lang betrieben habe

Wie hält man einen Service am Leben, obwohl es 200 Konkurrenten gibt?

Ich arbeite an Werktagen unter der Woche genau zwei Stunden daran
Fokus auf Funktionen, die den Schmerz der Kunden lösen
Extrem (ruthlessly) iterativ. Wenn sich eine Funktion nicht in 2 Stunden umsetzen lässt, den Umfang verkleinern, trotzdem deployen und das wiederholen

✓ Lektionen aus 1 Jahr

Es geht darum, Probleme zu lösen, nicht SaaS-Abos zu verkaufen

Aus Kundensicht denken
Nicht: "Wenn ich diese Funktion baue, kommen die Kunden von selbst!", sondern: "Ich muss den Kunden helfen, dieses nervige Problem zu lösen"
SaaS ist nur eine von vielen Möglichkeiten, ein Problem zu lösen

Dokumentation ist Teil der User Experience

Man sagt zwar: "Entwickler lesen keine Dokumentation", aber das stimmt nur teilweise
Sie lesen nicht, sondern überfliegen die Überschriften

Für Mobile bauen

Entgegen der allgemeinen Annahme über B2B-SaaS erledigen Menschen viel Arbeit auf dem Smartphone
Bei OnlineOrNot kommen etwa 50 % über Mobile
Sie erstellen schnell auf dem Smartphone ein Konto, fügen ein paar zu überwachende Seiten hinzu und schauen später gelegentlich am Laptop/Desktop nach
Sechs Monate lang gab es keinen Mobile-Support, und Leute, die sich über das Smartphone registriert hatten, sind schnell abgesprungen
Als ich schließlich responsive Mobile-Seiten gebaut habe, kommen jetzt laufend neue Mobile-Nutzer dazu

Die Leute fragen, wie sie von dir erfahren haben

Eine der wertvollsten Code-Änderungen war die Frage an neue Nutzer: "Wie haben Sie von OnlineOrNot erfahren?"
Es gibt viele Kanäle, um potenzielle Kunden anzuziehen, und man muss wissen, welche man stärker gewichten sollte

Manchmal muss man Fehler selbst machen

Ich habe viele Bücher gelesen, um die Fehler anderer nicht zu wiederholen, aber manchmal muss man Fehler selbst machen
Als ich auf der Hacker-News-Startseite landete, kamen 6000 Leute. Ein paar Hundert wollten sich registrieren, aber am Ende meldeten sich nicht einmal 10 wirklich an — da war klar, dass etwas nicht stimmte
Das Registrierungsformular hatte eine Absprungrate von 75 %. Durch A/B-Tests (mit meinem eigenen DeployWithFlags) und zusätzliche OAuth-Provider sank sie auf 50 %

Pricing ist wirklich schwer

Ist der Preis zu hoch, springen Leute ab, die erwarten, dass deine App alles für sie erledigt
Ist der Preis zu niedrig, gibt es Kunden, die für 9 $ bezahlt haben und dann wollen, dass du die App neu schreibst
Schwierigen Kunden Geld zurückgeben, Preise erhöhen und weitermachen
Sei darauf vorbereitet, beim Pricing viel zu experimentieren

Nicht zu sehr auf MRR (Monthly Recurring Revenue) fixieren

MRR ist am Anfang ein sehr schlechtes Maß dafür, wie sich das Business entwickelt
Dinge, die man vor ein paar Wochen verbessert hat, wirken sich erst jetzt auf den MRR aus. Bis man viele Kunden hat, ist es schwer zu erkennen, ob Änderungen tatsächlich einen Effekt hatten
DAU oder einige Customer-Success-Metriken (Seitenprüfungen, Bildgenerierung usw.) waren hilfreicher als MRR
Diese Werte zeigen, ob echte Nutzer das Produkt wirklich verwenden und ob es ihnen Nutzen bringt

Auch im Paid-Tier braucht es eine kostenlose Testphase

Ein kostenloses Tier ist ein guter Weg, Menschen anzuziehen und sie über dein Produkt sprechen zu lassen
Wenn das Paid-Tier aber viel besser ist als das kostenlose, brauchst du eine Möglichkeit, den Leuten dieses "Good Stuff" im Paid-Tier kostenfrei probieren zu lassen
Bis ich das verstanden habe, vergingen 11 Monate
Es gibt zwar ein kostenloses Tier, aber 95 % der neuen Nutzer wählen die kostenlose Testversion des Pro-Tiers

Mehr Traffic zu holen ist schwer, das Verhalten des bestehenden Traffics zu ändern ist leichter

Im Internet Aufmerksamkeit zu bekommen, ist ein langes, langsames Spiel
Wenn du über mehrere Monate hinweg konsequent gutes Content-Marketing machst, wächst die Zahl der Leser von 1–2 pro Tag auf Hunderte
Die Zahl der Besucher auf einer Website zu erhöhen, ist wirklich nicht einfach
Was die Leute aber tun, wenn sie auf deiner Website sind, kannst du beeinflussen — und zwar sofort
(So etwas wie zusätzliche OAuth-Login-Provider hinzuzufügen)

Content-Marketing verschafft dir Zeit

Wenn du in Content-Marketing investierst, kann das Business für eine gewisse Zeit von selbst weiterlaufen
Über ein Jahr hinweg gingen mehrere ältere Beiträge viral und zogen Zehntausende Besucher an. Auch ohne dass ich etwas tue, kommen organisch etwa 1500 Menschen, um diese Beiträge zu lesen

Klein und häufig deployen

Leute schlagen dir vielleicht bestimmte Funktionen vor, um das Produkt zu verbessern, aber wahrscheinlich werden sie diese Funktionen selbst gar nicht nutzen
Meist wollen sie nur helfen und haben ähnliche Funktionen in anderen Produkten gesehen
Wenn du zum ersten Mal ein SaaS betreibst, freust du dich darüber, dass dir Leute Feedback geben, und willst sofort Funktionen für sie bauen
Ich sage nicht, dass du diese Funktionen nicht bauen sollst (ich habe diesen Rat selbst bekommen und die Funktion, die niemand nutzte, trotzdem gebaut)
Frage, wie genau sie die Funktion nutzen würden, frage andere Kunden, wie sie das Problem aktuell lösen, baue die kleinstmögliche Version und schau dann, ob andere Nutzer sie tatsächlich verwenden
Du willst doch keine Funktion bauen, die nur eine Person benutzt?
Es ist viel weniger schmerzhaft, eine Funktion zu entfernen, in die du nur ein paar Stunden investiert hast und die niemand will, als etwas zu verwerfen, in das Monate Arbeit geflossen sind

Erst deployen, über Skalierung später nachdenken

In der ersten Version von OnlineOrNot habe ich die Architektur überhaupt nicht optimiert
(Bei jedem Uptime-Check wurde eine DB-Verbindung offengehalten, was es schwer machte, viele Nutzer zu bedienen)
Außerdem ist es mir lieber, wenn Leute sich über eine unfertige UI wundern, als dass ich etwas baue, das niemand braucht
Später habe ich die Architektur neu entworfen, sodass eine einzige kleine RDS-Instanz pro Woche mehrere Millionen Vorgänge verarbeiten konnte

Es ist schwieriger als gedacht, viel Zeit in die eigentliche Problemlösung zu stecken

Von der Zeit, die ich in einem Jahr mit Programmieren verbracht habe, ging nur etwa die Hälfte in die tatsächliche Lösung des Problems, das ich lösen wollte
Die andere Hälfte floss in den Aufbau der SaaS-Plattform
Man braucht SaaS-Plattform-Dinge wie verschiedene Arten von Authentifizierung, Testphasen, Onboarding, Team-Management, Rechnungsverwaltung und Lifecycle-E-Mails
Vieles kann man auslagern (ohne Stripe hätte ich das Produkt wahrscheinlich nicht als Abo verkaufen können)
Aber es gibt immer Dinge, die einem nicht gefallen, und wenn man sie anders handhaben will, muss man sie selbst bauen

3 Kommentare

wellsbabo 2024-08-13

Ein guter Artikel.

hibuz 2022-03-07

Das sind wirklich nützliche Tipps für die Planung und den Betrieb eines Live-Services!!

xguru 2022-03-07

Selbst wenn es eine kostenlose Stufe gibt, braucht die kostenpflichtige Stufe trotzdem eine kostenlose Testphase. Ich glaube, dieser Punkt ist wirklich wichtig.