Unternehmertum
OneTrack-Story: So baust du ein 8-stelliges SaaS auf
Ein Software Business aufbauen klingt nach Code, Servern und Feature-Listen. Wer eine achtstellige Software wirklich hochzieht, weiß: der Code ist der einfachste Teil. Am OneTrack-Beispiel siehst du, wie aus einer Marketing-Agentur ein Datenprodukt wurde, das heute mit Lösungen konkurriert, für die Konzerne 50.000 bis 120.000 Dollar im Monat zahlen. Und du siehst die Fehler, die auf dem Weg richtig teuer wurden.
Ich zerlege hier den kompletten Weg: die Idee, das MVP, die ersten zehn Kunden, den Punkt, ab dem kein Geld mehr verbrannt wurde, und die Entscheidungen, die über Skalierung oder Stillstand entschieden haben. Keine Motivationssprüche, sondern Mechanik. So, wie ein Unternehmer sie durchlebt, der einen mittleren sechsstelligen Betrag versenkt hat, bevor die Sache lief.
Eine Sache vorweg: Software bewegt sich schnell und ist nur bedingt planbar. Wer damit klarkommt, hat einen Skalierungsvorteil, den fast kein Dienstleistungsmodell schlägt. Wer nicht, verbrennt Geld und Nerven. Lies bis zum Ende, dann weißt du, auf welcher Seite du landest.
Wie entsteht die Idee fuer ein Software Business?
Die beste Software-Idee löst ein Problem, das du selbst hast, und das nachweislich auch andere haben. Du bemerkst einen Engpass in der eigenen Arbeit, prüfst über Gespräche mit potenziellen Kunden, ob der Bedarf real ist, und baust erst dann. Keine Idee aus dem luftleeren Raum, sondern ein Signal aus der eigenen Praxis.
OneTrack ist genau so entstanden. Das Team betrieb eine Marketing-Boutique, machte viele Revenue- und Profit-Share-Deals und brauchte für die Abrechnung eine saubere Antwort auf eine simple Frage: Wer hat den Traffic gebracht, wer hat am Ende das Geld verdient? Die vorhandenen Werkzeuge, Google Tag Manager, Server-to-Server-Verbindungen, No-Code-Verknüpfungen, deckten immer nur einen Teil ab. Es fehlte permanent ein Element, um Tracking-Erfolg verlässlich zu versprechen. Aus diesem Engpass wurde das Produkt.
Der Denkfehler, den die meisten hier machen: Sie coden etwas zusammen und hoffen, dass es schon jemand nutzt. Die sichtbaren Erfolgsgeschichten sind ein Survivorship-Bias. Erfahrungsgemäß erhöhst du deine Erfolgschance massiv, wenn du vorher fragst: Braucht der Markt das? Haben die Leute wirklich einen Schmerz? Und die härteste Frage: Würdest du dafür bezahlen, und wie viel?
Wichtig ist die Unterscheidung zwischen Signal und Rauschen. Ein großer Teil des Contents im Netz ist selbst Marketing, das dich zu irgendeinem Kauf lenken will. Wer daraus eine Produktidee ableitet, baut auf Rauschen. Das Signal findest du im eigenen Umfeld, im echten Bedarf, nicht im nächsten Hype. Wie du diesen Bedarf systematisch prüfst, statt einer Modeerscheinung hinterherzulaufen, ordnet der Beitrag Strategie vor Taktik ein.
Was ist ein MVP wirklich, und warum verstehen es die meisten falsch?
Ein MVP ist das am wenigsten Gebaute, das für einen Kunden interessant ist, ihm Mehrwert liefert und das er tatsächlich kauft. Nicht das kleinste, was technisch irgendwie läuft. Dieser Unterschied entscheidet, ob du sechs Monate an etwas Verkäuflichem baust oder an einem Prototyp, den niemand haben will.
Genau hier verrennen sich viele. Sie hören “Minimum Viable Product” und denken an das Skelett, das gerade so startet. Das ist ein technischer Blickwinkel. Der richtige ist ein Kundenblickwinkel: Ab welchem Funktionsumfang ist ein zahlender Kunde bereit, dir Geld zu geben? Alles darunter ist ein Bastelprojekt, alles darüber ist verfrühte Feature-Verliebtheit.
Beim Feature-Set kommt eine zweite Wahrheit dazu: Rund 80 bis 90 Prozent der Kunden brauchen dieselbe Basis, und diese Basis würde für den Start reichen. Trotzdem will jeder tausend Sonderwünsche. Deine Aufgabe ist es, die gemeinsame Basis zu bauen und die Sonderwünsche zu parken. Menschen im analytischen Bereich neigen dazu, alles zu überkomplizieren. Marktbeobachtungen zeigen: Die meisten scheitern nicht an Schritt fünf, sie setzen nicht mal Schritt eins sauber um.
| Fehlannahme | Realität | Konsequenz |
|---|---|---|
| MVP = kleinste lauffähige Version | MVP = kleinste kaufbare Version | Du baust am Bedarf vorbei |
| Jeder braucht seine Spezialfeatures | 80 bis 90 Prozent brauchen dieselbe Basis | Ressourcen verpuffen |
| Erst perfekt, dann Kunden | Erst Bedarf, dann iterieren | Monate ohne Umsatz |
| Aufwand ist planbar | Aufwand ist kaum schätzbar | Budget explodiert |
Der letzte Punkt ist der unangenehmste. Aufwand in Software abzuschätzen ist ungefähr so präzise wie aus dem Kaffeesatz lesen. Man sieht die Probleme nicht, die später kommen, und muss stark antizipieren. Wer das ehrlich einkalkuliert, plant Puffer ein, statt sich an einen Zeitplan zu klammern, der ohnehin nicht hält.
Wie gewinnt man die ersten zehn Kunden fuer ein SaaS?
Die ersten zehn Kunden kommen fast nie über kalte Reichweite, sondern über bestehende Beziehungen und echtes Vertrauen. In der Praxis kamen sie aus dem Kundenstamm der früheren Agentur, zu einem Sondereinstiegspreis, innerhalb von rund sechs Wochen nach dem ersten verkaufbaren MVP. Warme Kontakte, die dem Team ohnehin vertrauten, waren der schnellste Hebel.
Der Ablauf war unspektakulär und genau deshalb wiederholbar. Erst wurde etwa ein halbes Jahr entwickelt, bis ein MVP stand, das einigermaßen stabil lief und nach außen gezeigt werden konnte. Dann ging das Team zu zufriedenen Bestandskunden aus der Agenturzeit: Hier ist ein Sondereinstiegspreis, lasst uns gemeinsam Gas geben. Das Ergebnis: rund zehn Kunden in sechs Wochen. Bemerkenswert ist, dass ein großer Teil dieser ersten zehn Jahre später immer noch Kunde ist.
Daraus folgt eine klare Reihenfolge für den Start. Baue etwas Kaufbares, geh damit zuerst zu Menschen, die dir schon vertrauen, und liefere ihnen ein Ergebnis, über das sie reden. Kaltakquise, Ads und Content kommen danach. Wer sofort auf Reichweite setzt, verbrennt Budget, bevor das Produkt überhaupt bewiesen hat, dass es hält. Wenn du parallel einen planbaren Outbound-Kanal aufbauen willst, hilft der Leitfaden zum B2B-Vertrieb aufbauen.
Was danach den Ausschlag gab, war Product-Led Growth. Kunden waren zufrieden, empfahlen das Tool über Mund-zu-Mund-Propaganda weiter, und daraus wurde ein selbstverstärkendes Schwungrad. Die Entscheidung, wie viel in Marketing zu investieren war, wurde dem Team teils vom Markt abgenommen. Das funktioniert aber nur, wenn das Produkt wirklich einen Nerv trifft. Ohne echten Bedarf gibt es keine Empfehlungen.
Wann rechnet sich ein Software Business finanziell?
Ein SaaS erreicht die monatliche Nullsumme, also den Punkt ohne monatlichen Cash-Verlust, in der Praxis nach rund acht Monaten ab dem ersten Kunden. Das gilt ausdrücklich für den laufenden Cashflow, nicht für das zuvor verbrannte Aufbaukapital. Bis dahin ist ein Software-Start ein sattes Minusgeschäft.
Die Zahlen dahinter sind ernüchternd und ehrlich zugleich. Am Anfang wurde ein mittlerer sechsstelliger Betrag verbrannt, bevor das Modell trug. Das war so schmerzhaft, dass es der Auslöser war, einen Top-Entwickler fest ins Team zu holen, damit sich dieser Fehler nicht wiederholt. Wer ohne Rücklagen in so etwas geht, setzt seinen Geldbeutel, seine mentale Klarheit und seinen Zustand aufs Spiel. In diesem Fall standen siebenstellige Rücklagen bereit, die den nötigen Atem gaben.
Diese Reihenfolge lohnt sich als Faustregel: erst Entwicklung mit Verlust, dann erste Kunden, dann Break-even, dann Skalierung.
| Phase | Zeitraum | Finanzieller Zustand |
|---|---|---|
| Entwicklung des MVP | 3 bis 6 Monate | Reines Minus, hoher Kapitalabfluss |
| Erste zehn Kunden | ca. 6 Wochen danach | Erste Einnahmen, weiter negativ |
| Monatliche Nullsumme | ca. 8 Monate ab Kunde eins | Cashflow neutral |
| Skalierung | Jahre | Steigende Marge pro Kunde |
Der entscheidende Punkt: Druck ist Gift für Software-Entwicklung. Wer aus einer Notlage heraus baut und sofort Geld verdienen muss, trifft schlechte Entscheidungen. Entwicklung braucht Zeit und die Erkenntnis aus Fehlern. Genau deshalb ist die finanzielle Grundlage kein Luxus, sondern Voraussetzung. Wer wissen will, wie sich eine solche Kostenstruktur ohne Fremdkapital tragen lässt, findet im Beitrag Ein Prozess zum sechsstelligen Umsatz einen konkreten Rahmen.
Warum skaliert Software besser als eine Dienstleistung?
Software skaliert besser, weil die Kosten der nächsten Einheit gegen null gehen. Nach der einmaligen Grundentwicklung sind Fix- und variable Kosten pro zusätzlichem Kunden gering. Bei einer Dienstleistung musst du für mehr Kunden mehr Menschen einstellen und trainieren, also läuft die Kostenkurve fast parallel zum Umsatz mit.
Der Kern ist die Kostenstruktur, nicht ein magischer Software-Zauber. Bei einer Dienstleistung sind Recruiting und Training die zwei Komponenten, die jede Skalierung ausbremsen. Du brauchst gefühlt immer einen Tick mehr Mitarbeiter, als du Kunden hast, und musst diese Menschen finden, einarbeiten und halten. Bei Software heißt “ein Kunde mehr” im Zweifel: ein anderer Server. Das ist der Grund, warum die wertvollsten Firmen der Welt fast alle Softwarefirmen sind.
Dazu kommt die Internationalisierung. Ein Dienstleister, der ins Ausland geht, braucht Leute mit den passenden Sprachen und Marktkenntnissen. Bei Software übersetzt du die App, und weiter geht es. Der Markt ist zudem größer und leichter zu erreichen. Auch der Support ist ein standardisiertes Produkt, während Beratung immer eine menschliche Komponente behält, die schwer zu skalieren ist.
Eine wichtige Einschränkung: Auch Software ist kein Feld ohne Tücken. Ein Beispiel dafür, wie unplanbar Änderungen sein können, ist ein bekannter Fall aus dem Streaming-Bereich, in dem eine scheinbar simple Anpassung, welche Episode als Titelbild angezeigt wird, rund 18 Entwickler und sechs Monate gekostet hat, weil ein Subsystem das Update nicht hergab. Genau diese Unplanbarkeit unterschätzen Einsteiger regelmäßig.
Bei aller Skalierbarkeit gibt es harte Schwellen. Erfahrungsgemäß verändern sich alle Systeme bei jeder Verdreifachung der Mitarbeiter: von 1 auf 3, von 3 auf 9, von 9 auf 27. An diesen Punkten brechen Prozesse, die vorher gut liefen. Wer das antizipiert, restrukturiert rechtzeitig, statt in der Skalierung stecken zu bleiben. Wie sich dieser Sprung strukturell managen lässt, zeigt der Beitrag Unternehmen skalieren mit System.
Welche Fehler machen Dienstleister beim Wechsel zu Software?
Der teuerste Fehler ist, Software wie eine Dienstleistung zu behandeln. Dienstleistung ist personen- und zeitgebunden, Software bewegt sich schnell und ist nur bedingt planbar. Wer diesen Unterschied nicht verinnerlicht, klammert sich an Planbarkeit, wo es keine gibt, und verbrennt Kapital an falschen Stellen.
Fehler eins ist der Planungsfetisch. In der Dienstleistung kannst du Aufwände einigermaßen kalkulieren. In der Software musst du damit rechnen, dass alles länger dauert und schwieriger ist als gedacht. Ein Feature ist eben keine neue Excel-Zeile mit einer Formel, sondern greift oft in mehrere Subsysteme ein. Wer das ignoriert, plant Termine, die reihenweise platzen, und demotiviert sein Team.
Fehler zwei ist die falsche Datenbank-Entscheidung. Wer zu klein denkt, wählt eine Infrastruktur, die 100 Kunden trägt, aber nicht 500 oder 1.000. Dann reißt es dich mitten im Skalierungsprozess auseinander. Solche Weichen musst du 6 bis 12 Monate vorausdenken, nicht erst, wenn der Engpass schon da ist. Antizipation ist hier keine Kür, sondern Pflicht.
Fehler drei ist der Wrapper-Reflex: schnell etwas um ein bestehendes KI-Modell herumbauen. Die Eintrittsbarriere ist niedrig, deshalb sehen die großen Anbieter dieselbe Chance und überrollen dich. Nachhaltig wird ein Produkt erst, wenn du zumindest ein Stück weit von Null auf Eins gehst, also echten neuen Wert schaffst, statt nur einen dünnen Aufsatz zu verkaufen. Wer tiefer in diese Denkweise einsteigen will, dem hilft “Zero to One” von Peter Thiel.
Fehler vier ist mangelnde Tiefe. Viele Ideen scheitern, weil sie an der Oberfläche bleiben. “Ich mache nur rote Creatives” ist keine Produktidee, sondern ein Bauchgefühl ohne Marktlogik. Erst wenn du tief genug reingehst, findest du den Punkt, an dem ein Kunde wirklich mehr Wert hat und dafür zahlt. Diese Tiefe unterscheidet ein tragfähiges Produkt von einem, das der Markt in Monaten wieder ausspuckt.
Wie steuert man Entwicklung und Marketing gleichzeitig?
Du steuerst beides über eine simple Priorisierungslogik: Du hörst dem Kunden zu, sammelst seine Wünsche und filterst sie durch die Frage, ob du selbst den Nutzen siehst. Als grobe Verteilung funktioniert oft ein Split, bei dem etwa die Hälfte in Entwicklung und die Hälfte in Marketing fließt, je nach Kapitalintensität auch 70 bis 80 Prozent Marketing.
Der Kern ist eine Priorisierung, die nicht auf Bauchgefühl beruht. Wer ein “Heft voller Features” hat, das Kunden sich wünschen, braucht ein Raster. Das Raster hier: Erst fragen die Kunden danach, dann prüft das Team, ob es die Sache selbst gut findet. Nur wenn beides zusammenkommt, wird gebaut. So entsteht kein Feature-Friedhof, sondern ein Produkt, das echten Bedarf trifft.
Beim Personal gilt eine vorausschauende Regel: Rund drei Monate nach vorne schauen und einstellen, bevor der Engpass da ist. Wer die Person erst sucht, wenn sie schon fehlt, verliert Monate. Qualität schlägt dabei Menge. Statt gegen Konzerne wie Google oder Meta um Gehälter zu bieten, gewinnt man Top-Leute über Kultur, Netzwerk, spannende Projekte und viel Eigenverantwortung. Das Ergebnis ist kaum Fluktuation, Leute bleiben jahrelang.
Der Erfolg eines Datenprodukts lässt sich dabei zweiteilen. Ein automatisierter Teil, in diesem Fall die Datenverarbeitung und Datenrückführung, macht erfahrungsgemäß rund 60 bis 65 Prozent des Nutzens aus und läuft ohne menschliches Zutun. Der Rest, etwa 35 bis 40 Prozent, ist manuelle Analytik: auswerten, vergleichen, Entscheidungen treffen. Diese Aufteilung erklärt, warum ein gutes Tool auch dann Wert liefert, wenn der Nutzer nur die Basis nutzt.
Für die Steuerung heißt das: Automatisiere alles, was du automatisieren kannst, und halte die manuelle Ebene simpel. Zwei Klicks bis zur relevanten Erkenntnis sind mehr wert als ein Dashboard, in dem sich jeder verliert. Wer regelmäßig zwingt, die eigenen Auswertungen zu vereinfachen, trifft schnellere Entscheidungen und baut kein Monster, das keiner mehr bedient.
Welche Denkweise trennt gute Software-Gruender von schlechten?
Gute Gründer denken langfristig und iterativ. Sie jagen nicht dem schnellen Monatsumsatz hinterher, sondern bauen auf einer soliden Basis Stufe um Stufe auf. Der Antrieb ist nicht der Ferrari, sondern die Frage, wie lange das Geschäft tragen soll. Wer stehen bleibt und aufhört, sich neu zu erfinden, bewegt sich faktisch rückwärts.
Der erste Baustein ist Langfristigkeit. Wer 20 Jahre exakt dasselbe macht und jeden Monat einen guten Betrag mit nach Hause nimmt, hat nicht zwangsläufig 20 Jahre Erfahrung, sondern oft einmal ein Jahr zwanzigmal. Der Unterschied entsteht durch kleine Iterationen: nicht ständig Nische oder Produkt wechseln, sondern eine gute Basis nehmen und immer die nächste Stufe draufsetzen.
Der zweite Baustein ist Selbstreflexion ohne Selbstbetrug. Erfahrungsgemäß begegnen einem im Leben nur eine Handvoll wirklich verändernder Ideen, in einer Größenordnung von sieben bis acht Chancen. Sie zu erkennen und in der Position zu sein, sie zu nutzen, ist der eigentliche Hebel. Das gelingt nur, wenn du scharf an der Realität bleibst und dir nicht selbst in die Tasche lügst.
Der dritte Baustein ist Value vor Geld. Wer echten Wert liefert und versteht, wie Geschäft funktioniert, verdient ohnehin. Geld ist die Folge, nicht das Ziel. Diese Reihenfolge klingt banal, dreht aber die Prioritäten um: Erst baust du etwas, das Menschen wirklich brauchen, dann kümmert sich die Monetarisierung fast von selbst. Wie sich diese Haltung in eine belastbare Firmenstruktur übersetzt, zeigt der Beitrag Von einer Agentur zu sechs Firmen mit 100 Mitarbeitern.
Am Ende steht Führung durch Klarheit statt durch Druck oder Angst. Ein schlankes Team von rund 35 Leuten trägt eine achtstellige Software, weil die richtigen Menschen an den richtigen Positionen sitzen und sich aufeinander verlassen können. Druck hat man als Unternehmer immer, die Frage ist, wie viel davon man weitergibt. Wer auf Angst setzt, gewinnt kurzfristig und verliert langfristig. Wer auf Klarheit setzt, baut ein Fundament, das auch die nächste Verdreifachung übersteht.
Der Rest ist Wiederholung: Bedarf prüfen, kaufbares MVP bauen, warme Kunden zuerst, iterieren, antizipieren, langfristig denken. Genau so wird aus einem Engpass in der eigenen Agentur ein Datenprodukt, das mit Konzern-Lösungen konkurriert.
Häufige Fragen
Wie lange dauert es, ein Software Business aufzubauen?
Rechne mit einem halben Jahr für einen brauchbaren MVP, danach oft sechs Wochen bis zu den ersten zehn Kunden und rund acht Monate bis zur monatlichen Nullsumme. Bis zur echten Skalierung vergehen Jahre. In der Praxis waren bis zum achtstelligen Niveau viereinhalb Jahre nötig.
Sollte man die Agentur aufgeben, um Software zu bauen?
Nicht zwingend. Der All-in-Weg funktioniert nur mit Rücklagen und klarem Fokus. Wer nebenbei baut, teilt seine Zeit und riskiert, dass beides leidet. Entscheidend ist nicht der Weg, sondern ob du stabil stehst und dein Markt den Bedarf wirklich hat.
Was ist ein MVP wirklich?
Ein MVP ist nicht das am wenigsten Gebaute, das irgendwie läuft. Es ist das am wenigsten Gebaute, das für einen Kunden interessant ist, echten Mehrwert liefert und das er kauft. Wer das verwechselt, baut monatelang an etwas, das niemand haben will.