Der Schritt vom kostenlosen Nebenprojekt zu ersten Einnahmen scheitert selten an der Technik — er scheitert daran, dass Devs Pricing als nachgelagertes Detail behandeln statt als Produktentscheidung. Dabei entscheidet der Preis nicht nur, wie viel du verdienst, sondern wer deine Nutzer sind und wie viel Support du am Hals hast.
Ich habe selbst Projekte monetarisiert und mehr Fehler gemacht, als mir lieb ist. Das hier ist die Zusammenfassung dessen, was ich beim nächsten Mal von Anfang an anders mache — inklusive der deutschen Besonderheiten, die in amerikanischen Indie-Hacker-Guides schlicht fehlen.
Der mentale Schritt: Von “wer zahlt schon dafür” zu “wer hat das Problem”
Das größte Hindernis sitzt zwischen deinen Ohren. Devs unterschätzen systematisch, was ihre Arbeit wert ist, weil sie den Aufwand kennen: “Das ist doch nur ein CRUD mit zwei Integrationen.” Aber Nutzer zahlen nicht für deinen Aufwand — sie zahlen dafür, dass ein Problem verschwindet. Ein Tool, das einem Freelancer zwei Stunden Rechnungsstress pro Monat spart, ist zwanzig Euro monatlich wert, egal ob du es in drei Wochenenden gebaut hast.
Die praktische Konsequenz: Preise nicht an deinen Kosten oder deinem Aufwand ausrichten, sondern am gesparten Aufwand oder erzeugten Wert beim Nutzer. Und dann trau dich, diesen Preis auch aufzurufen. Fast jeder Indie-Dev, den ich kenne, hat rückblickend zu billig gestartet — ich auch. Preiserhöhungen später sind unangenehm; zu hoch gestartet und dann gesenkt hat dagegen selten jemand bereut.
Free Tier: Die beliebteste Falle
Der Reflex ist verständlich: Kostenlos-Stufe anbieten, Nutzer sammeln, später konvertieren. In der Realität passiert bei kleinen Projekten oft Folgendes: Du sammelst hunderte Free-Nutzer, die Serverkosten und Support-Anfragen erzeugen, und die Konversionsrate zur Bezahlversion liegt im niedrigen einstelligen Prozentbereich. Du hast dir ein zweites unbezahltes Produkt geschaffen — den Betrieb der Gratis-Nutzerschaft.
Ein Free Tier ergibt strategisch nur dann Sinn, wenn mindestens eins zutrifft: Das Produkt hat Netzwerkeffekte (jeder Free-Nutzer macht es für zahlende wertvoller), Free-Nutzer erzeugen Sichtbarkeit (z. B. “Powered by”-Badge auf öffentlichen Seiten), oder deine Grenzkosten pro Nutzer sind praktisch null. Trifft nichts davon zu, ist eine zeitlich begrenzte Testphase fast immer die bessere Wahl: 14 Tage voller Funktionsumfang, danach zahlen oder gehen. Das filtert früh die Nutzer heraus, die nie zahlen würden — und deren Feature-Wünsche dich sonst in die falsche Richtung ziehen.
Einmalzahlung, Abo oder Lifetime-Deal?
Die drei Standard-Modelle, ehrlich einsortiert:
- Abo (SaaS-Klassiker): Planbar und summiert sich — aber nur gerechtfertigt, wenn du laufend Wert lieferst: Hosting, Datenpflege, Updates, API-Betrieb. Ein Abo für ein Tool, das einmal installiert einfach läuft, erzeugt Kündigungen und schlechte Bewertungen. Rechne außerdem mit Churn: Bei kleinen B2C-Tools sind fünf bis zehn Prozent monatlich normal, dein Wachstum muss das erst mal übertreffen.
- Einmalzahlung: Passt für Desktop-Tools, Plugins, Templates, Kurse. Die Hürde ist niedriger, aber du brauchst konstant neue Käufer. Beliebter Mittelweg: Einmalkauf inklusive ein Jahr Updates, danach optionales Update-Abo.
- Lifetime-Deals: Verlockend für den schnellen Cash-Schub am Anfang, aber du verkaufst zukünftige Verpflichtung zum Einmalpreis. Wenn das Produkt läuft, sind die Lifetime-Käufer die Nutzer, die du für immer supportest und die nie wieder zahlen. Als begrenzte Early-Bird-Aktion okay, als Dauermodell gefährlich.
Für B2B-Tools gilt zusätzlich: Staffle nach Wert-Metrik, nicht nach Feature-Willkür. Anzahl Projekte, Teammitglieder, verarbeitete Dokumente — irgendwas, das mit dem Nutzen mitwächst. Und die wichtigste B2B-Erkenntnis überhaupt: Firmen zahlen deutlich mehr als Privatnutzer, oft für dasselbe Produkt mit Rechnung, Team-Verwaltung und einem SLA-Satz in der Mail.
Die deutsche Realität: Zahlung, Steuern, Formalien
Hier trennt sich der Indie-Hacker-Traum von der Praxis, denn die US-Guides enden bei “just use Stripe”. In Deutschland fängst du da erst an:
- Umsatzsteuer: Verkaufst du digital an Privatkunden in anderen EU-Ländern, gilt deren Mehrwertsteuersatz — das OSS-Verfahren (One-Stop-Shop) nimmt dir die Einzelmeldungen ab, aber kümmern musst du dich trotzdem. Alternative: Ein Merchant of Record wie Paddle oder Lemon Squeezy tritt als Händler auf und übernimmt die komplette Steuerabwicklung gegen eine höhere Gebühr. Für Solo-Devs mit internationalen Kunden ist das oft den Aufpreis wert.
- Kleinunternehmerregelung (§ 19 UStG): Unter der Umsatzgrenze kannst du ohne Umsatzsteuer abrechnen — weniger Bürokratie, aber kein Vorsteuerabzug. Für den Start meist sinnvoll, mit wachsendem Umsatz wächst du raus.
- Rechnungen und Impressum: Deutsche Geschäftskunden erwarten ordentliche Rechnungen mit fortlaufender Nummer und Steuerangaben; dein Checkout braucht Impressum, Datenschutzerklärung und AGB, die zum Produkt passen.
- Zahlungsmethoden: Kreditkarten-Only kostet dich in Deutschland messbar Konversion. PayPal ist quasi Pflicht, SEPA-Lastschrift für Abos stark, und im B2B ist Kauf auf Rechnung weiter verbreitet, als man als Dev wahrhaben will.
Das klingt nach viel, ist aber einmaliger Setup-Aufwand. Der Fehler ist nicht, dass es Bürokratie gibt — der Fehler ist, sie erst nach dem Launch zu entdecken und dann panisch nachzuziehen.
Der erste zahlende Kunde schlägt jede Theorie
Zum Schluss die wichtigste Priorisierung: Alles in diesem Artikel ist zweitrangig gegenüber der Frage, ob überhaupt jemand zahlt. Ein perfektes Pricing-Modell für ein Produkt ohne Zahlungsbereitschaft optimiert eine Null. Deshalb: Bau den Bezahl-Weg früh ein — notfalls als schlichten Stripe-Payment-Link — und such aktiv die ersten fünf zahlenden Nutzer, bevor du Pricing-Seiten polierst. Fünf Fremde, die echtes Geld überweisen, sagen dir mehr über dein Produkt als fünfhundert Free-Anmeldungen.
Und wenn der erste Euro da ist: Dokumentiere, was funktioniert hat, und erhöhe beim nächsten Kunden testweise den Preis. Pricing ist kein Beschluss, sondern ein fortlaufendes Experiment.
Wenn du gerade an der Monetarisierung deines Projekts sitzt und Sparring brauchst: Im Discord der Community teilen einige von uns ihre Zahlen und Learnings offen — auch die peinlichen.