Von der Idee zu zahlenden Nutzern: Wie wir ein B2B-SaaS gestartet haben

Sie kam mit einer Tabelle, einer Ahnung und einer Frist, die ihr die Branchenkonferenz gesetzt hatte, ohne sie zu fragen. In vier Monaten würde sie auf einer kleinen Bühne vor rund zweihundert Menschen stehen, die genau die Art von Unternehmen führten, für die ihre Idee gedacht war. Sie wollte ihnen etwas Echtes zeigen können — keine Folien, kein Mockup, sondern ein Produkt, in das sich ein Fremder einloggen und für das er zahlen konnte. Mit diesem Gespräch beginnt diese Fallstudie, und das Nützlichste daran ist, wie gewöhnlich der Ausgangspunkt war.

Wir haben die identifizierenden Details hier bewusst verändert. Die Gründerin ist real, das Produkt ist live, und die Zahlen liegen nah an der Wahrheit, sind aber gerundet und abgemildert, damit niemand zurückrechnen kann, um wen es sich handelt. Es kommt nicht auf die konkrete Nische an — es kommt auf die Form des Weges an, denn diese Form wiederholt sich fast jedes Mal, wenn eine nicht-technische Gründerin versucht, aus einer guten Idee funktionierende Software zu machen. Wenn Sie irgendwo am Anfang dieses Weges stehen, sieht das etwa so aus, wie die nächsten Monate verlaufen können, wenn es gut läuft.

Die Kurzfassung: eine Branche, die sie genau kannte, ein mühsamer manueller Prozess, den alle darin duldeten, eine Tabelle, mit der sie ihn still besser erledigte als ihre Kollegen, und kein technischer Hintergrund. Elf Wochen konzentrierter Arbeit später waren die ersten zahlenden Nutzer da. Hier ist, wie — und, ehrlicher gesagt, hier ist, wo wir gestolpert sind.

Die Ausgangslage: eine Tabelle, die echte Arbeit leistet

Die Gründerin führte eine kleine Beratung in einem regulierten, dokumentenlastigen Feld. Ihre Kunden waren andere kleine Unternehmen, und jedes von ihnen kämpfte mit derselben wiederkehrenden Pflicht — einen Stapel Formulare zusammentragen, auf Vollständigkeit prüfen, dem Fehlenden hinterherjagen und vor einer Frist eine saubere Zusammenfassung erstellen. Die meisten ihrer Wettbewerber erledigten das mit E-Mails, Telefonaten und einem Ordner voller Word-Vorlagen. Sie tat es mit einer Tabelle, die sie über vier Jahre aufgebaut und verfeinert hatte, und ihre Kunden liebten sie still dafür.

Diese Tabelle war die ganze Erkenntnis. Sie war kein Businessplan und keine Marktanalyse — sie war ein Beweis. Menschen verließen sich bereits auf ihr Werkzeug, baten sie, es für Unternehmen laufen zu lassen, die sie gar nicht beriet, boten an, allein für den Zugang zu zahlen. Wenn Kunden versuchen, etwas zu kaufen, bevor Sie es gebaut haben, müssen Sie nicht mehr raten, ob es Nachfrage gibt. Die Frage war nie, ob sich das lohnt. Die Frage war, ob daraus Software werden kann, die ein anderer nutzen kann, ohne dass sie daneben sitzt.

Ihre Rahmenbedingungen waren ebenso real. Ein festes Budget aus ihren eigenen Ersparnissen, nicht aus einem Fonds. Die Konferenzfrist. Und eine harte Regel, auf die wir uns früh einigten: Das durfte kein Projekt werden, das täglich ihre Aufmerksamkeit verlangte, denn sie hatte weiterhin eine Beratung zu führen. Was immer wir bauten, musste fertigstellbar, bezahlbar und langweilig im Betrieb sein. Diese drei Worte prägten jede folgende Entscheidung.

Die erste Aufgabe war zu entscheiden, was NICHT gebaut wird

Wenn Gründer ihr Traumprodukt beschreiben, ist die Funktionsliste immer riesig, weil sie es sich seit Jahren ausmalen. Ihre füllte zwei Seiten: Dashboards, Team-Berechtigungen, ein Prüfprotokoll, automatische Erinnerungen, ein Kundenportal, Abrechnung, Analysen, Integrationen mit drei Tools, die ihre Kunden nutzten, und — natürlich — „irgendwo etwas KI darin". Jeder Punkt war vernünftig. Alle vor dem Start zu bauen wäre eine Katastrophe gewesen.

Also machten wir die Übung, die wir mit jedem machen: Für jede Funktion stellten wir eine einzige unverblümte Frage. Wenn das am Starttag fehlen würde, würde ein Kunde sich weigern zu zahlen? Nicht „wäre es schöner damit" — würde der Verkauf tatsächlich scheitern. Die meisten Funktionen fallen bei diesem Test durch, und genau das ist der Punkt. Die, die überstehen, sind Ihr echtes Produkt. Alles andere ist eine Roadmap, was eine schöne Sache ist, aber nicht das, was Sie zuerst bauen.

Was übrig blieb, war fast schon peinlich klein. Ein Nutzer konnte ein Konto anlegen, einen Fall einrichten, seinen Kunden einladen, die erforderlichen Dokumente hochzuladen, und dieselbe saubere, geprüfte Zusammenfassung zurückbekommen, die ihre Tabelle erzeugte — nur automatisch und ohne sie dazwischen. Das war alles. Keine Dashboards. Keine Team-Rollen. Keine KI, noch nicht. Vier Funktionen, eine klare Aufgabe, ordentlich erledigt.

Was wir in elf Wochen tatsächlich gebaut haben

Wir arbeiten in kurzen, sichtbaren Zyklen, statt drei Monate zu verschwinden und mit einer Überraschung zurückzukehren. Etwa jede Woche bekam die Gründerin einen Link zu etwas, das sie anklicken konnte, selbst wenn es hässlich und halb verdrahtet war. Dieser Rhythmus zählt mehr, als er klingt: Er hielt ihre Entscheidungen klein und häufig, statt sie zu einer einzigen erschreckenden Abnahme am Ende aufstapeln zu lassen.

Wochen 1–3: das Rückgrat

Zuerst bauten wir den unglamourösen Kern — Konten, eine sichere Art, Dokumente zu speichern, und das Datenmodell unter dem Fall-Workflow. Nichts davon ist für einen Kunden sichtbar, und alles davon ist der Teil, der teuer zu reparieren ist, wenn man ihn überstürzt. Weil das Produkt sensible Unterlagen anderer Unternehmen verarbeitete, behandelten wir Zugriffskontrolle und Datentrennung als Startanforderung, nicht als spätere Erweiterung. Das ist einer der wenigen Punkte, an denen wir uns weigerten zu sparen.

Wochen 4–7: die eigentliche Arbeit

Dann der Teil, der es bezahlenswert machte: ihre Tabellenlogik in die Engine zu verwandeln, die Dokumente auf Vollständigkeit prüft und die Zusammenfassung erzeugt. Das war das Herz des Produkts, und wir gaben ihm die meiste Zeit. Wir setzten uns mit ihr zusammen und nahmen auseinander, warum jede Regel in ihrer Tabelle existierte — und einige stellten sich als Gewohnheiten statt Anforderungen heraus, was uns erlaubte zu vereinfachen. Bis Ende Woche sieben konnte man einen echten Fall von Anfang bis Ende durchspielen.

Wochen 8–11: es sicher machen, um dafür Geld zu verlangen

Die letzte Strecke war der Unterschied zwischen einer Demo und einem Produkt. Bezahlung, damit Menschen tatsächlich abonnieren konnten. Eine saubere Anmeldung, die keine Anleitung brauchte. Das Dutzend kleiner Fehlerzustände, die entscheiden, ob ein Fremder Ihrer Software vertraut oder abspringt. Und Tests — langweilige, repetitive Tests — mit der Gründerin und zwei wohlgesinnten Kunden, die zustimmten, das System absichtlich kaputtzumachen, bevor Fremde es taten. Diese letzte Gruppe verdiente ihren Frühzugriffsrabatt um ein Vielfaches.

Die Frage „bau doch etwas KI ein", ehrlich beantwortet

Auf ihrer Wunschliste stand KI, so wie auf den meisten Wunschlisten heute. Wir widersprachen, und es lohnt sich zu erklären, warum, denn es ist derselbe Rat, den wir fast jedem geben. Die Aufgabe, die Version eins erledigen musste — einen bekannten Satz Dokumente gegen einen bekannten Satz Regeln zu prüfen — ist eine Aufgabe, die Regeln besser erledigen als KI. Sie ist vorhersehbar, sie ist nachprüfbar, und wenn ein regulierter Kunde fragt „warum hat das System das markiert", wollen Sie eine klare Antwort, kein Achselzucken.

Das heißt nicht, dass KI keinen Platz hatte. Es gab ein wirklich unordentliches, sprachlich geprägtes Problem, das sich im Workflow versteckte: Kunden luden oft Dokumente hoch, die fast richtig, aber falsch beschriftet waren, oder fügten Informationen als Freitext ein, statt das Formular auszufüllen. Diesen Wirrwarr zu lesen und zu sortieren ist genau das, worin moderne KI gut ist. Also notierten wir es sorgfältig — und ließen es dann für Version zwei. Es vor dem Start hinzuzufügen hätte die Frist verzögert, um eine Funktion zu polieren, für die noch niemand zu zahlen gebeten hatte.

Die ersten zahlenden Nutzer gewinnen

Hier ist der Teil, vor dem sich Gründer am meisten sorgen und auf den sie sich am wenigsten vorbereiten. Ein Produkt, das niemand findet, ist kein Geschäft, sondern ein Hobby. Aber diese Gründerin hatte einen Vorteil, der mehr wert war als jedes Marketingbudget: Sie hatte bereits ein Publikum, das ihr vertraute, und einige davon hatten gebeten zu zahlen, bevor die Software existierte. Der Startplan stützte sich vollständig darauf, und Ihrer sollte das auch, wenn Sie es haben.

Statt eines aufsehenerregenden öffentlichen Starts machten wir das Gegenteil — einen leisen, bewussten. Zwei Wochen vor der Konferenz schrieb sie die Handvoll Kunden an, die bereits gefragt hatten, bot ihnen Gründungsmitglied-Preise an und nahm sie von Hand an Bord, indem sie über einen Videoanruf zusah, wie sie es nutzten. Jede Verwirrung wurde zu einer Korrektur. Als sie auf dieser Bühne stand, pitchte sie keine Idee; sie beschrieb Software, für die ihre Kollegen bereits zahlten, und sie konnte das ehrlich sagen.

1. 1
   Beginnen Sie mit den Menschen, die bereits fragen

   Ihre erste Ansprache ging nur an Kunden, die zuvor angeboten hatten zu zahlen. Warme Nachfrage konvertiert, bevor kalte Nachfrage überhaupt antwortet.
2. 2
   Nehmen Sie die ersten paar von Hand an Bord

   Kein Selbstbedienungs-Heldentum am Anfang. Sie führte jeden frühen Nutzer live durch und verwandelte jeden Verwirrungspunkt in eine konkrete Korrektur.
3. 3
   Preise für Gründer, nicht für immer

   Frühe Nutzer bekamen einen klar zeitlich begrenzten Gründungstarif. Er belohnte ihr Risiko und gab späteren Kunden einen Grund, warum die Preise stiegen.
4. 4
   Nutzen Sie die Frist als Start

   Die Konferenz war kein nachträglich angeschraubter Marketing-Gag — sie war die Zwangsfunktion, die den Umfang den ganzen Weg über ehrlich hielt.

Das Ergebnis — und was es wirklich bedeutet

Zum Ende des Startmonats hatte das Produkt seine ersten zahlenden Abonnenten — eine kleine Zahl, die Art, die man noch an zwei Händen abzählen kann, jeder ein echtes Unternehmen, das eine echte monatliche Gebühr zahlt. Das klingt bescheiden, und das ist es. Es ist auch der einzelne schwerste Meilenstein im ganzen Leben eines Softwareprodukts. Von null zahlenden Kunden zu ein paar zu kommen ist weit schwerer, als von ein paar zu vielen zu kommen, denn es ist der Moment, in dem die Idee aufhört, Ihre zu sein, und die des Marktes wird.

Die folgenden Zahlen sind beispielhaft und gerundet, aber sie treffen die Form dessen, was geschah. Was Sie daraus mitnehmen sollen, sind nicht die Zahlen — es sind die Proportionen. Eine eng umrissene erste Version, ein kleines fokussiertes Budget, ein kurzer Zeitrahmen und ein Start, der auf warme Nachfrage zielte statt auf das ganze Internet.

Wo wir danebenlagen

Eine Fallstudie, die nur Erfolge auflistet, ist eine Werbung, also hier der ehrliche Teil. Wir machten zwei Fehler, die es wert sind, benannt zu werden, denn Sie werden in dieselben verführt werden.

Erstens unterschätzten wir das Onboarding. Wir hatten das Produkt sorgfältig umrissen, aber die ersten fünf Minuten der Erfahrung eines neuen Nutzers als Nebensache behandelt, etwas, das man am Ende aufräumt. Es stellte sich als der entscheidende Moment heraus, und wir verbrachten eine ungeplante Woche damit, die Anmeldung und den leeren ersten Bildschirm neu zu bauen, damit ein Fremder verstehen konnte, was zu tun war, ohne dass man es ihm sagte. Nächstes Mal ist die Erstnutzungs-Erfahrung eine Funktion ab Tag eins, nicht ab Woche zehn.

Zweitens ließen wir eine „kleine" Regel in der Prüf-Engine aufblähen. Die Gründerin erwähnte einen Sonderfall fast nebenbei, wir waren uns einig, dass er einfach sei, und er verschlang still drei Tage, weil die Daten der echten Welt unordentlicher waren, als ihre saubere Tabelle je verriet. Die Lektion war nicht „vermeiden Sie Sonderfälle" — sie war, dass ihre Tabelle still manuelle Bereinigung leistete, von der sie vergessen hatte, dass sie sie tat. Software muss diese unsichtbare Arbeit sichtbar machen, und das kostet immer mehr, als irgendjemand erwartet.

Wenn Sie dort stehen, wo sie stand

Das, was das hier funktionieren ließ, war keine clevere Architektur und kein modisches Tool. Es war Disziplin beim Umfang und Ehrlichkeit über die Nachfrage. Sie hatte den Beweis, dass Menschen es wollten, bevor wir eine Zeile Code schrieben, und wir waren rücksichtslos dabei, die kleinste Version zu bauen, für die jemand trotzdem zahlen würde. Keines davon erfordert einen technischen Hintergrund. Beides sind Dinge, mit denen Sie diese Woche selbst beginnen können.

Wenn Sie eine Tabelle haben, deren Ausführung man immer wieder von Ihnen erbittet, oder einen manuellen Prozess, für den Ihre Kunden Ihnen danken, sind Sie einem Produkt vielleicht näher, als Sie denken. Der gefährliche Zug ist, sich die fertige, funktionsvollständige Version vorzustellen und davor zu erstarren, wie groß sie aussieht. Tun Sie das nicht. Finden Sie die eine Aufgabe, die sie unbedingt erledigen muss, bauen Sie nur das und legen Sie es den Menschen vor, die bereits fragen. Die Roadmap kann warten. Der erste zahlende Nutzer kann das nicht.

Häufige Fragen