Wie du dein SaaS-Pricing festlegst

Warum Pricing zum Produkt gehört und nicht ans Ende

Viele Teams behandeln den Preis als das Letzte, was sie festlegen. Erst wird gebaut, dann überlegt man sich, was es kosten soll. Eine teure Reihenfolge. Dein SaaS-Pricing bestimmt, welche Kunden du anziehst, wie hoch dein Aufwand pro Kunde sein darf und ob am Ende genug übrig bleibt, um das Produkt weiterzuentwickeln und zu betreiben. Ein Preis ist eine Aussage darüber, wie viel Wert dein Produkt schafft. Triffst du diese Aussage daneben, merkst du es oft erst Monate später, an einer Wachstumskurve, die nicht trägt.

Pricing ist deshalb ein eigenes Designthema. Eine universell richtige Antwort gibt es nicht. Aber es gibt nachvollziehbare Modelle, klare Denkrichtungen und eine Handvoll Fehler, die sich immer wiederholen. Wir gehen das der Reihe nach durch, damit am Ende eine begründete Entscheidung steht statt einer geratenen.

Die vier Grundmodelle: Flat-Rate, Seat, Nutzung, Staffeln

Fast jedes SaaS-Pricing lässt sich auf vier Grundmuster zurückführen. In der Praxis mischst du sie. Bevor du mischst, solltest du die Bausteine einzeln verstehen.

Flat-Rate (Pauschalpreis). Ein Preis, ein Produkt, alle bekommen dasselbe. Du zahlst einen festen Betrag pro Monat und nutzt alles. Der Vorteil ist Einfachheit: Der Kunde versteht sofort, was er bekommt, und du musst nichts messen oder abrechnen. Der Nachteil ist, dass du Wert verschenkst. Ein kleiner und ein grosser Kunde zahlen gleich viel, obwohl der grosse oft ein Vielfaches an Nutzen zieht. Flat-Rate passt, wenn dein Produkt für alle ungefähr gleich wertvoll ist oder du am Anfang jede Reibung vermeiden willst.

Pro Platz (per Seat). Du zahlst pro Nutzer, der mit dem Produkt arbeitet. Ein Team von fünf Leuten zahlt fünfmal so viel wie ein Einzelnutzer. Das Modell ist beliebt, weil es leicht verständlich ist und mit der Organisation des Kunden mitwächst. Mehr Mitarbeitende, mehr Umsatz. Gut funktioniert es, wenn der Wert tatsächlich an der Zahl der aktiven Personen hängt, etwa bei einem Tool für Zusammenarbeit. Die Schwäche: Kunden teilen Logins, um Plätze zu sparen. Und bei Produkten, die nur wenige Power-User wirklich brauchen, passt die Rechnung schlecht zum Wert.

Nutzungsbasiert (usage-based). Du zahlst nach Verbrauch, pro API-Aufruf, pro versendeter Nachricht, pro Gigabyte, pro verarbeitetem Dokument. Preis und Nutzung sind eng gekoppelt. Wer viel nutzt, zahlt viel. Wer wenig nutzt, zahlt wenig. Das senkt die Einstiegshürde und wirkt fair. Der Preis dafür ist Unsicherheit auf beiden Seiten: Der Kunde weiss am Monatsanfang nicht, was am Ende auf der Rechnung steht, und du hast weniger planbare Einnahmen. Es lohnt sich, wenn es eine klare, gut messbare Grösse gibt, die mit dem Wert mitwächst.

Staffeln (Tiers). Statt eines einzelnen Preises bietest du mehrere Pakete an, etwa Basis, Pro und Business. Jede Stufe hat einen festen Preis und einen definierten Funktionsumfang oder ein Limit. Staffeln lösen mehrere Probleme auf einmal. Sie geben Kunden eine Wahl, sie segmentieren nach Zahlungsbereitschaft, und sie schaffen einen Pfad nach oben, wenn ein Kunde wächst. Die Kunst liegt im Schnitt: Jeder Kunde soll sich in genau einer Stufe wiederfinden, und der Sprung zur nächsten muss sich lohnen.

In der Realität siehst du Mischformen. Staffeln mit einem Platz-Preis pro Stufe, dazu ein nutzungsbasierter Anteil für alles über dem Limit. Solche Kombinationen sind mächtig. Sie haben aber einen Preis, auf den wir gleich zurückkommen: Komplexität.

Vom Wert her rechnen, nicht von den Kosten

Der häufigste Reflex beim Pricing geht von den eigenen Kosten aus. Was kostet mich der Betrieb, was will ich an Marge, also kostet es so viel. Als untere Grenze ist diese Rechnung in Ordnung. Als Hauptfrage ist sie falsch. Der Preis orientiert sich am Wert, den der Kunde bekommt, nicht an deinen Kosten.

Wertbasiert denken heisst, du fragst, was sich für den Kunden verändert, sobald er dein Produkt einsetzt. Spart er drei Stunden pro Woche? Vermeidet er einen Fehler, der ihn sonst teuer zu stehen käme? Gewinnt er Kunden, die er ohne dich nicht erreicht hätte? Je näher dein Preis an diesem Nutzen liegt, desto mehr Spielraum hast du nach oben, und desto leichter sagt der Kunde ja, weil sich die Ausgabe für ihn rechnet.

Mit dem Wert hängt die Abrechnungsgrösse zusammen, der Value Metric. Das ist die Einheit, an der du den Preis aufhängst: der Platz, der API-Aufruf, das verwaltete Projekt. Ein guter Value Metric hat drei Eigenschaften. Er wächst mit dem Nutzen, den der Kunde zieht. Er ist vorhersehbar, sodass der Kunde die Rechnung im Kopf nachvollziehen kann. Und er ist fair, weil mehr Nutzen mehr kostet. Findest du den richtigen Value Metric, ergibt sich das Modell fast von selbst.

Wertbasiert heisst nicht, den maximal möglichen Preis zu nehmen. Es heisst, den Preis bewusst in Relation zum Nutzen zu setzen und einen Teil des geschaffenen Werts beim Kunden zu lassen. Genau dieser geteilte Wert ist der Grund, warum ein Kunde bleibt und weiterempfiehlt.

Die vier Pricing-Fehler, die fast jedes Team macht

Einige Fehler wiederholen sich so zuverlässig, dass es sich lohnt, sie beim Namen zu nennen.

Zu billig. Aus Unsicherheit zu tief einzusteigen ist der häufigste. Die Sorge ist nachvollziehbar, man will niemanden abschrecken. Nur schadet ein zu tiefer Preis doppelt. Er lässt Marge liegen, die du für Entwicklung und Betrieb brauchst, und er signalisiert: billig wirkt weniger wertvoll. Dazu zieht ein zu tiefer Preis die falschen Kunden an, jene, die viel Support brauchen und wenig zahlen. Später zu erhöhen geht, ist aber unangenehm, weil Bestandskunden es spüren. Höher starten und gezielt Rabatte geben fällt fast immer leichter, als von unten nachzuziehen.

Zu kompliziert. Ein Pricing, das niemand auf Anhieb versteht, ist der zweite. Kombinierst du mehrere Achsen, Plätze mal Nutzung mal Feature-Stufen, verlierst du Kunden schon im Kopf, bevor sie zur Zahlung kommen. Wer ausrechnen muss, was ihn das Produkt am Ende kostet, zögert. Verständlichkeit ist selbst ein Verkaufsargument. Lieber ein Modell, das eine Frage offen lässt, als eines, das fünf aufwirft.

Keine Segmentierung. Mit einem einzigen Preis bedienst du nur einen einzigen Kundentyp gut. Der Einzelnutzer und das grössere Team haben unterschiedliche Zahlungsbereitschaft. Ohne wenigstens eine grobe Staffelung verschenkst du entweder die kleinen oder die grossen Kunden.

Pricing nie wieder anfassen. Viele legen den Preis einmal fest und rühren ihn jahrelang nicht an, aus Angst, etwas kaputtzumachen. Dabei ist Pricing kein einmaliger Beschluss, sondern etwas, das du mit wachsendem Verständnis für deine Kunden anpasst. Wer Produkte nicht nur baut, sondern auch selbst betreibt, sieht im laufenden Betrieb, welche Kunden bleiben, wo sie abspringen und welches Paket niemand bucht. Diese Signale sind die beste Grundlage für die nächste Iteration. Bei unseren eigenen Produkten Wortfreunde und Reazon nutzen wir genau diese Rückkopplung, um Pricing zu beobachten statt zu raten. Warum diese Betriebsnähe ganze Projekte trägt, steht in warum SaaS-Projekte scheitern.

Wann sich Pricing-Feinschliff noch nicht lohnt

Eine Frage, die selten offen beantwortet wird: Solltest du im MVP überhaupt schon viel Energie ins Pricing stecken? Meist nicht. Solange du noch nicht weisst, ob überhaupt jemand das Problem gelöst haben will, ist ein durchoptimiertes Preismodell verschenkte Zeit. Die teuren Pricing-Entscheidungen, gestaffelte Pakete, ausgeklügelte Limits, dynamische Nutzungsabrechnung, gehören in die Phase, in der du zahlende Kunden hast und ihr Verhalten beobachten kannst. Vorher fehlt dir schlicht die Datengrundlage.

Das heisst nicht, dass du den Preis ignorierst. Es heisst, dass du im MVP eine bewusste, einfache Entscheidung triffst und sie als vorläufig verstehst. Wenn du dein Pricing dagegen schon vor dem ersten Kunden bis ins Detail durchdenkst, optimierst du auf Annahmen, die der Markt gleich wieder umstösst.

So setzt du dein MVP-Pricing pragmatisch an

Deine grösste Unsicherheit im frühen Stadium ist nicht das perfekte Modell, sondern fehlendes Wissen über deine Kunden. Du kennst ihre Zahlungsbereitschaft nicht und weisst noch nicht sicher, welcher Value Metric passt. Das Ziel im MVP ist deshalb nicht das endgültige Pricing, sondern eines, mit dem du schnell startest und aus dem du lernst.

Fang einfach an. Eine Flat-Rate oder zwei, drei klar geschnittene Staffeln reichen fast immer. Ein einfaches Modell erklärst du leicht und setzt es schnell um, was im MVP ohnehin im Vordergrund steht. Falls du unsicher bist, wie schlank ein erstes Produkt sein darf, ordnet was kostet ein MVP das für dich ein.

Wähle bewusst einen Value Metric, auch wenn du ihn später änderst. Schon die Entscheidung, ob du pro Platz, pro Projekt oder pauschal abrechnest, zwingt dich, über den Wert nachzudenken, und du kannst im Betrieb beobachten, ob die Einheit trifft. Setz den Preis lieber etwas zu hoch als zu tief an. Frühen Kunden kannst du Rabatte geben, ohne dein öffentliches Pricing zu verbrennen, und aus ihren Reaktionen lernst du, wo die Schmerzgrenze liegt.

Und plane Pricing von Anfang an als etwas Veränderliches. Bau dein Produkt so, dass du Stufen, Limits und Preise anpassen kannst, ohne alles umzustellen. Wer ein SaaS nicht nur baut, sondern auch betreibt, gewinnt mit jedem Monat ein klareres Bild davon, was Kunden wirklich bezahlen. Diese Verbindung aus Bauen und Betreiben ist der Kern unserer Arbeit in der SaaS-Produktentwicklung. Wir denken Pricing nicht als Schild am fertigen Produkt, sondern als Teil des Produkts, der mit ihm wächst.

Pricing bleibt ein Hebel, kein Beschluss

Dein erstes Pricing wird nicht dein letztes sein, und das ist kein Mangel, sondern der Normalfall. Wichtig ist, dass du es bewusst triffst. Du verstehst die Modelle, du rechnest vom Wert statt von den Kosten, du umgehst die offensichtlichen Fehler, und du startest im MVP einfach genug, um schnell zu lernen. Mit jedem zahlenden Kunden bekommst du Daten, die deine nächste Entscheidung besser machen. Behandle den Preis darum als Hebel, an dem du über die Lebenszeit deines Produkts immer wieder drehst, nicht als einmaligen Beschluss.