von Eine ehrliche Bilanz nach mehreren Jahren Nebenbei-Produktbau
Es gibt Artikel über Produkt-Launches. Es gibt Artikel über MRR-Meilensteine. Es gibt sehr wenige Artikel darüber, wie man wieder abschaltet, was niemand gebucht hat. Das hier ist so einer.
Ich habe über mehrere Jahre parallel zu meinem Consulting-Geschäft mehrere Produkte gebaut: eine self-hosted Newsletter-Plattform, ein DSGVO-konformes Dokumentenportal, einen License Server, diverse kleinere Tools. Dazu zwei Fachblogs mit über 300 publizierten Artikeln. Technisch funktioniert alles. Kommerziell funktioniert nichts.
Es geht alles vom Netz. Nicht ein Produkt, nicht ein Teilbereich — die Produkte, die Websites, die Blogs, die Kontaktformulare. Vollständig.
Kein Drama, keine Abrechnung mit dem Markt — sondern das, was ich mir vor drei Jahren gerne selbst geschrieben hätte.
Was ich gebaut habe
Alle Produkte hatten dieselbe Entstehungsgeschichte: ein reales Problem aus einem Kundenprojekt, für das die verfügbaren Lösungen entweder zu teuer, zu US-lastig oder DSGVO-technisch fragwürdig waren. Also selbst gebaut. Erst für mich, dann produktisiert.
Das ist auf dem Papier der Lehrbuchweg. „Scratch your own itch.“ Der Vorteil: Man kennt das Problem wirklich. Der Nachteil, den niemand auf die Slides schreibt: Man kennt ein Problem wirklich — nämlich sein eigenes. Ob es dieselbe Ausprägung bei genug zahlungsbereiten anderen gibt, ist eine völlig separate Frage. Ich habe sie nie ernsthaft gestellt.
Was nicht funktioniert hat
1. Vertrieb ist ein Vollzeitjob, kein Feierabend-Task
Das ist die zentrale Erkenntnis, und sie ist unbequem, weil sie nichts mit Technik zu tun hat.
Ich habe die Produktentwicklung neben der Beratung gestemmt — abends, an Wochenenden, in Projektlücken. Das funktioniert für Code. Es funktioniert nicht für Vertrieb. Vertrieb ist kein Vorgang, den man in Zwei-Stunden-Blöcken erledigt. Vertrieb ist Kontinuität: dieselben Leute über Monate ansprechen, nachfassen, Demos halten, Einwände sammeln, das Produkt entlang der Einwände ändern, wieder ansprechen.
Ich habe stattdessen Features gebaut. Weil Features bauen sich gut anfühlt und Kaltakquise sich schlecht anfühlt. Das ist keine Marktanalyse, das ist eine Verhaltensdiagnose — und zwar meine.
2. Die Build-Trap trifft Techniker besonders hart
Wenn man 30 Jahre Infrastruktur macht, ist Bauen die Komfortzone. Jedes ungelöste Vertriebsproblem lässt sich in ein technisches Problem umdeuten: Die Conversion ist schlecht → das Onboarding muss besser werden. Keine Anfragen → die Landingpage braucht ein Redesign. Kunde springt ab → wir brauchen SSO.
Jede dieser Umdeutungen ist plausibel. Alle zusammen sind ein Ausweichmanöver. Ich habe eine OIDC-Integration gebaut für ein Produkt, das zu dem Zeitpunkt zwei aktive Nutzer hatte. Das ist nicht Produktarbeit, das ist Prokrastination mit Git-History.
3. Self-Hosted-SaaS im DACH-Raum ist ein zäher Markt
Das ist kein Ausrede-Argument, aber es gehört zur Bilanz. Die Zielgruppe für self-hosted, DSGVO-first Tools besteht überproportional aus Leuten, die es selbst bauen können — und es dann auch tun. Wer die Souveränitätsargumente versteht, hat meistens auch die Kompetenz, das Problem intern zu lösen.
Die eigentlich zahlungsbereite Gruppe — Mittelstand, Behörden, Organisationen ohne eigene DevOps-Kapazität — kauft nicht über Landingpages. Die kaufen über Ausschreibungen, Rahmenverträge, persönliche Netzwerke und Referenzen. Also über exakt die Kanäle, die ich als Berater längst bediene, aber für die Produkte nie aktiviert habe.
Ich hatte den Zugang. Ich habe ihn nicht genutzt, weil ich in der Produktlogik dachte statt in der Beratungslogik.
4. Kostenloser Content ist kein Vertriebskanal, wenn er nicht verkauft
Über 300 Fachartikel in zwei Blogs. Die werden gelesen. Sie haben mir Reputation gebracht, Netzwerk, gelegentlich Projektanfragen. Was sie nicht gebracht haben: Produktumsatz.
Der Grund ist banal. Meine Artikel sind Anleitungen, wie man Dinge selbst macht. Ich habe jahrelang meiner Zielgruppe beigebracht, wie sie ohne meine Produkte auskommt. Das ist inhaltlich integer und vertrieblich absurd. Content Marketing funktioniert, wenn der Content am Produkt endet. Meiner endete regelmäßig bei „und so baust du das selbst“.
Das ist ein Fehler in der Content-Strategie, nicht im Content. Aber es ist der Grund, warum die Blogs mit abgeschaltet werden statt weiterzulaufen: Ein Kanal, der über Jahre nichts trägt, ist kein Kanal. Er ist ein Hobby mit Betriebspflicht.
5. Kein Feedback ist auch Feedback
Der schmerzhafteste Punkt zum Schluss: Es gab nicht mal Ablehnung. Kein „zu teuer“, kein „fehlt Feature X“, kein „nutzen wir schon Y“. Es gab Stille.
Stille bedeutet fast immer: Das Problem ist real, aber nicht dringend genug. Menschen zahlen für Schmerz, nicht für Verbesserung. Meine Produkte waren durchweg Verbesserungen. Sie haben Dinge eleganter, sauberer, souveräner gemacht — aber niemandem etwas abgenommen, das gerade brannte.
Was konkret passiert
Hier wird es praktisch, und hier liegt der Teil, der für andere in derselben Situation nützlich ist.
Ein kompletter Shutdown ist kein docker compose down über alle Stacks. Wer Kundendaten verarbeitet hat, hat Pflichten, die das Abschalten überdauern — und wer eine Umgebung abreißt, ohne sie vorher zu sichern, hat sie nie ernst genommen. Das Ende soll genauso sauber sein wie der Aufbau. Alles andere wäre die einzige Stelle, an der ich mir handwerklich etwas vorzuwerfen hätte.
Was abgeschaltet wird
- Alle Produktivumgebungen. Container, VMs, Datenbanken, Reverse Proxies, Monitoring-Stacks.
- Alle Websites und Landingpages. Produktseiten, Marketingseiten, Dokumentation.
- Beide Blogs. Keine neuen Artikel, kein Bestand online.
- Sämtliche Kontaktformulare. Auch die auf den Firmenseiten.
- Registrierungen, Trials, Support, Weiterentwicklung. Vollständig eingestellt.
- Jeder bezahlte Drittdienst. Mail-Relay, Payment-Provider, Monitoring, CDN, Statuspage, Fehler-Tracking. Der Punkt, den alle vergessen und der monatelang weiter abbucht.
Die Reihenfolge
Wer das strukturiert durchziehen will:
- Bestandskunden informieren. Vor allem anderen. Fristen aus den AGB prüfen, realistische Übergangszeit setzen, Datenexport aktiv anbieten. Auch bei drei Kunden. Gerade bei drei Kunden.
- Datenexport bereitstellen und dokumentieren. Bei personenbezogenen Daten ist Art. 20 DSGVO nicht optional.
- Registrierungen und Zahlungsflüsse schließen. Keine neuen Verträge, laufende Abos kündigen bzw. auslaufen lassen.
- Vollbackup ziehen, verschlüsselt offline legen. Datenbanken, Konfigurationen, Deployment-Skripte, Container-Images. Nicht aus Sentimentalität — das ist Handwerk. Nachweispflichten enden nicht mit dem Abschalten.
- DSGVO-Löschung durchführen und protokollieren. Nach Ablauf der Übergangsfrist, mit Löschprotokoll. AV-Verträge sauber beenden.
- Dienste stoppen, DNS umstellen. Nicht auf eine Fehlerseite laufen lassen. Eine statische Abschaltseite mit einem einzigen Verweis darauf, wo man mich erreicht — das kostet einen Nginx-Container und verhindert, dass jahrelange Backlinks in ein Timeout laufen.
- Drittanbieter-Accounts kündigen. Mit Bestätigung, nicht mit Klick.
- Aufbewahrungspflichtige Unterlagen archivieren. Kundenkommunikation, Verträge, Rechnungen. Das ist keine Wahl.
Punkt 6 ist der einzige, bei dem ich mit mir selbst diskutiert habe. Es wäre konsequenter, auch die Domains auslaufen zu lassen. Ich lasse sie noch laufen, weil eine tote Domain mit Historie innerhalb von Tagen weg ist und ich diese Entscheidung nicht am selben Abend treffen will wie alle anderen.
Was ich anders machen würde
Nicht als Ratschlag verpackt — als das, was ich mir selbst sagen würde.
Verkaufen, bevor gebaut wird. Nicht validieren im Sinne von Umfragen. Verkaufen: eine Rechnung, eine Vorkasse, eine unterschriebene Absichtserklärung. Wenn niemand für eine Beschreibung zahlt, zahlt auch niemand für die Implementierung.
Den Kanal nutzen, den man schon hat. Ich habe ein funktionierendes Beratungsnetzwerk und habe versucht, Produkte über Landingpages zu verkaufen. Der Kanal war die ganze Zeit da. Ich habe ihn nicht benutzt, weil „Produkt“ sich anders anfühlt als „Beratung“. Das ist eine Kategorie in meinem Kopf, nicht im Markt.
Ein Produkt statt vier. Vier halbe Produkte sind kein diversifiziertes Portfolio, sondern viermal zu wenig Vertrieb. Jedes zusätzliche Produkt war eine Flucht vor dem Vertriebsproblem des vorherigen.
Ein Abbruchkriterium definieren, bevor man anfängt. Nicht „mal sehen“. Sondern: X zahlende Kunden bis Datum Y, sonst Ende. Ohne vorab definierte Grenze verlängert man immer — und die Entscheidung fällt irgendwann nicht rational, sondern aus Erschöpfung. So wie diese hier.
Und jetzt?
Das Beratungsgeschäft läuft. Es lief die ganze Zeit. Das war nie das Problem — im Gegenteil, es hat die Produkte quersubventioniert, was wiederum verhindert hat, dass ich früher die Reißleine ziehe. Ein Produkt, das dich nicht ernährt, aber auch nicht wehtut, kann man jahrelang mitschleppen. Genau das ist passiert, und zwar viermal parallel.
Was ich zurückbekomme, sind Abende und Wochenenden. Was wegfällt, ist ein diffuses Dauer-Schuldgefühl, ständig an vier Dingen zu wenig zu arbeiten. Das ist mehr wert als der nie erzielte MRR.
Die Produkte waren technisch gut. Das ist keine Selbsttröstung, das ist eine Fehlerbeschreibung: Technisch gut zu sein war nie die Anforderung, an der es entschieden wurde. Ich habe die falsche Disziplin trainiert und mich gewundert, dass ich den falschen Wettkampf verliere.
Wer gerade in derselben Schleife steckt: Zieh die Zahlen, setz eine Frist, und wenn sie reißt, schalte ab. Ordentlich, mit Backup und Löschprotokoll — aber ohne Verhandlung mit dir selbst.
Erreichbar bin ich ab sofort ausschließlich hier über LinkedIn. Das Beratungsgeschäft läuft weiter — Infrastruktur, digitale Souveränität, Automatisierung.
