SaaS entwickeln: Von der Idee zum ersten zahlenden Kunden

Die meisten SaaS-Ideen sterben nicht am Code. Sie sterben daran, dass niemand das Produkt haben wollte. Wer eine SaaS entwickeln möchte, denkt zuerst an Features, an die Datenbank, an das schicke Dashboard. Und genau da fängt das Problem an. Du baust monatelang etwas, das in deinem Kopf perfekt ist, und merkst beim Launch, dass der Markt achselzuckt.

CB Insights hat über 400 gescheiterte Startups untersucht. Bei 43 Prozent fehlte am Ende der Product-Market-Fit, das Produkt passte nicht zu einem echten Markt. In der älteren, viel zitierten Auswertung von gut hundert Post-mortems lag “kein Marktbedarf” sogar mit 42 Prozent ganz oben. Die Zahlen unterscheiden sich je nach Erhebung, die Richtung ist seit Jahren dieselbe. Gebaut wird zu viel, validiert wird zu wenig.

Dieser Guide geht den Weg von der Idee bis zum ersten zahlenden Kunden in der Reihenfolge durch, in der er in der Praxis funktioniert. Nicht in der Reihenfolge, die sich gut anfühlt.

Bevor du eine SaaS entwickelst, validierst du das Problem

Die wichtigste Arbeit passiert, bevor eine einzige Zeile Code geschrieben wird. Du musst wissen, ob das Problem, das du lösen willst, überhaupt schmerzt. Und ob es genug Leuten schmerzt, die bereit sind, dafür zu zahlen.

Der erste Schritt sind Gespräche. Such dir 10 bis 20 Menschen, die das Problem haben, und rede mit ihnen. Nicht über deine Lösung. Über ihren Alltag, ihren aktuellen Workaround, was sie schon ausprobiert haben und woran es gescheitert ist. Der Fehler, den fast alle machen: Sie pitchen ihre Idee und hören dann freundliche Zustimmung. Zustimmung ist kostenlos. Sie sagt dir nichts.

Im B2B-Bereich gilt grob die Marke von rund 20 Gesprächen als Schwelle. Wenn du die Antworten des nächsten Gesprächspartners vorhersagen kannst, hast du ein Muster gefunden. Vorher hörst du oft nur das, was du hören willst.

Der ehrlichste Test kommt danach: Lass dir Geld zusprechen, bevor das Produkt existiert. Vorbestellungen, ein Pilotvertrag, ein Gründer-Tarif mit Rabatt. Wer vorab zahlt, hat ein echtes Problem. Wer “klingt super, sag Bescheid wenn es fertig ist” sagt, wird später nicht kaufen. Diese eine Trennlinie spart dir Monate. Ehrlich gesagt ist sie unbequem, weil sie deine Idee früh dem echten Markt aussetzt. Genau deshalb funktioniert sie.

Der MVP ist die kleinste Version, die jemand bezahlt

Ein MVP ist kein halbfertiges Produkt mit allen Features in schlecht. Es ist die kleinste Version, die ein echtes Problem löst und für die jemand zahlt. Ein einziger Workflow, sauber gelöst, schlägt zehn Funktionen, die alle nur zu 70 Prozent funktionieren.

Beim Zuschnitt hilft eine harte Frage: Was ist der eine Kernnutzen, für den der Kunde dich bezahlt? Alles, was nicht direkt auf diesen Nutzen einzahlt, fliegt aus der ersten Version. Reporting, Rollen und Rechte, hübsche Einstellungen, das kommt später. Manchmal lässt sich der Nutzen sogar erst von Hand liefern, hinter den Kulissen, bevor du ihn automatisierst. Das nennt sich Concierge-MVP und beantwortet die Frage, die kein Interview beantworten kann: Löst die Lösung das Problem wirklich, wenn sie angewendet wird?

Bei den Kosten kursieren wilde Zahlen. Realistisch liegt eine einfache SaaS, etwa im Stil eines schlanken Projektboards, je nach Quelle zwischen rund 25.000 und 60.000 Euro, komplexere Produkte mit KI, vielen Integrationen und echter Multi-Tenancy schnell jenseits von 150.000. Die Zeit bis zu den ersten zahlenden Kunden liegt bei einfachen Produkten oft bei zwei bis drei Monaten, bei größeren eher bei einem halben Jahr. Das sind Größenordnungen aus Branchenauswertungen, kein Festpreis. Der genaue Aufwand hängt am Funktionsumfang, und der hängt an deiner Disziplin beim Weglassen.

Zwei, drei Tech-Entscheidungen am Anfang, der Rest später

Bei der Technik lähmen sich viele Gründer selbst. Welche Sprache, welches Framework, welche Cloud. Die ehrliche Antwort: Für den Start ist fast alles egal, solange dein Team es beherrscht. Die schnellste vertraute Technologie schlägt die theoretisch beste, die ihr erst lernen müsst.

Eine Grundsatzentscheidung solltest du trotzdem früh treffen: Multi-Tenancy. Bei SaaS teilen sich viele Kunden eine Anwendung. Trennst du ihre Daten über eine gemeinsame Datenbank mit Mandanten-Kennung, über getrennte Schemata oder über getrennte Datenbanken? Das im Nachhinein umzubauen ist teuer und riskant. Die meisten kleinen SaaS-Produkte fahren mit einer gemeinsamen Datenbank und sauberer Mandantentrennung gut, das ist günstig und reicht weit.

Der zweite Punkt ist die Abrechnung. Wiederkehrende Zahlungen, anteilige Berechnung bei Tarifwechsel, fehlgeschlagene Kreditkarten, all das willst du nicht selbst bauen. Ein Anbieter wie Stripe nimmt dir den Großteil ab. Wer hier basteln will, verbrennt Wochen an einem gelösten Problem. Wenn du an der Stelle unsicher bist, ist eine kurze Standortbestimmung mit jemandem, der das schon gebaut hat, billiger als drei falsche Architekturentscheidungen. Genau dafür gibt es unsere Fokus-Session.

Das Pricing entscheidest du nicht am Ende

Pricing ist keine Aufgabe für kurz vor dem Launch. Es gehört in die Validierung. Wenn du in den Gesprächen nicht über Geld redest, weißt du nicht, ob dein Produkt zahlungsfähig ist.

Für den Anfang reicht oft ein simples Modell mit ein, zwei Stufen. Verzettel dich nicht mit fünf Tarifen und Add-ons, solange du noch keine zehn Kunden hast. Wichtiger als die perfekte Preisstruktur ist, dass du überhaupt einen Preis aufrufst, der die Sache ernst macht. Zu billig ist gefährlicher als zu teuer, weil ein zu niedriger Preis Kunden anzieht, die viel Support brauchen und schnell wieder gehen.

Womit wir bei der Kennzahl sind, die ab dem ersten Kunden zählt: dem MRR, der monatlich wiederkehrende Umsatz. Er ist die Lebensader jeder SaaS. Die zweite ist die Churn, der Anteil der Kunden, die wieder kündigen. Im B2B-SaaS gilt eine jährliche Churn unter 5 Prozent als gesund, monatlich unter einem Prozent als richtig gut. Spannend ist, wo es weh tut: Rund 70 Prozent der Abwanderung passieren in den ersten 90 Tagen. Wenn ein neuer Kunde nicht schnell den ersten echten Nutzen sieht, ist er meist schon wieder weg.

Die zwei Fehler, die fast alle machen

Der erste Fehler ist zu viel bauen. Aus dem MVP wird über Monate ein Vollprodukt, weil ja noch dieses Feature fehlt und jenes auch. Wer ein Jahr im Keller baut und nie verkauft, baut am Markt vorbei. Du merkst erst beim Launch, dass die Hälfte niemand braucht, und die Hälfte, die fehlt, hätte dir ein einziges Kundengespräch verraten.

Der zweite Fehler ist zu spät verkaufen. “Wenn es fertig ist, dann verkaufe ich.” Es wird nie fertig. Software ist nie fertig. Verkaufen gehört von Tag eins dazu, nicht als Belohnung am Schluss. Die ersten Pilotkunden sind keine Käufer, sie sind deine besten Berater. Sie zeigen dir, was wirklich fehlt, und sie zahlen dir gleichzeitig den Beweis, dass dein Markt existiert.

Beide Fehler haben dieselbe Wurzel: die Angst, sich der Realität auszusetzen. Im Keller bauen fühlt sich produktiv an. Verkaufen fühlt sich nach Ablehnung an. Nur produziert das eine Umsatz und das andere nur Code.

Was zählt, ist der erste zahlende Kunde

Wenn du nur eine Sache aus diesem Text mitnimmst: Erst das Problem validieren, dann bauen. Der erste zahlende Kunde ist kein Nebenprodukt am Ende der Entwicklung, er ist der Beweis, dass die ganze Sache trägt. Alles davor ist eine Wette, alles danach ist ein Geschäft.

Wenn du eine SaaS entwickeln willst und vor der Frage stehst, was zuerst, was später und was vielleicht nie, dann lass uns reden. Wir bauen individuelle Software und die passende Webentwicklung für Unternehmen, und wir sagen dir ehrlich, ob deine Idee trägt. Buch dir einen Termin, bevor du den ersten Monat ins Bauen steckst.