Eigenes Tool verkaufen: Wenn deine Lösung anderen hilft

Du hast für deinen eigenen Betrieb, deine Praxis oder deine Kunden ein kleines Werkzeug mit Lovable oder Claude Code gebaut. Es spart Zeit, die Kollegen mögen es, und irgendwann fragt jemand: „Kann ich das auch haben?“ Ab diesem Moment steht eine neue Frage im Raum. Kann man so eine App verkaufen? Ja. Aber ein Tool, das dir hilft, und ein Produkt, für das andere zahlen, sind zwei verschiedene Dinge. Dieser Artikel zeigt dir, wo der Unterschied liegt.

Der beste Startpunkt: ein Problem, das noch auf Papier liegt

In einer viel diskutierten Reddit-Diskussion beschreibt jemand, wie eine Zahnarztpraxis die Läufe ihres Sterilisators auf einem Klemmbrett direkt am Gerät dokumentierte: Uhrzeit, Temperatur, Kürzel. Daraus wurde eine kleine Lovable-App, in der das Team jeden Durchlauf vom Handy aus einträgt. Patientendaten speichert sie bewusst nicht. Der Praxisinhaber erzählte Kollegen davon, und laut dem Beitrag nutzen inzwischen rund 90 Praxen die App gegen eine monatliche Gebühr.

Ob die Geschichte genau so stimmt, lässt sich nicht prüfen. Mehrere Kommentatoren hielten sie sogar für Werbung. Das Muster dahinter ist trotzdem lehrreich: ein enger, wiederkehrender Ablauf, ein klarer Nutzer, ein analoger Ist-Zustand. Genau solche Ideen eignen sich für einen schlanken Kern. Ob deine Idee diesen Zuschnitt hat, kannst du mit dem Selbsttest prüfen.

Interesse ist nicht gleich Bedarf

Ein zweiter Fall aus derselben Community zeigt die Kehrseite. Ein Fabrikmitarbeiter baute eine App für die Abläufe seiner Firma. Die Geschäftsführung war begeistert, er bekam sogar eine neue Stelle. Die App selbst wird aber nicht genutzt. Der Grund: Im Betrieb lief bereits eine ausgereifte Lösung.

Für dich heißt das: Lob vom Chef oder von Kollegen ist ein Signal, kein Beweis. Frag konkret, womit die anderen das Problem heute lösen. Lautet die Antwort „mit einer etablierten Software, die alle kennen“, brauchst du einen sehr guten Grund für den Wechsel. Lautet sie „mit Papier“ oder „mit einer Tabelle“, ist die Lücke echt. Wie du das vor dem Bauen testest, steht in Idee validieren, bevor du den ersten Prompt schreibst.

Kunden zahlen dafür, sich nicht kümmern zu müssen

Eine dritte Reddit-Diskussion bringt es auf den Punkt. Jemand baute per Vibe Coding eine Open-Source-Alternative zu einem bekannten SaaS-Tool, mit denselben Kernfunktionen. Ein Kontakt aus genau der Zielgruppe winkte ab: Er zahle lieber weiter für das Original. Die monatliche Gebühr deckt eben nicht nur Funktionen ab. Sie bezahlt dafür, dass sich jemand anderes um Updates, Datenbank-Backups, SSL-Zertifikate und Serverprobleme kümmert.

Die Kommentare ergänzen zwei wichtige Punkte. Erstens kaufen Unternehmen mit Software auch Schutz vor Haftung und einen Ansprechpartner, wenn etwas schiefgeht. Zweitens bringt dir Funktionsgleichheit einen Platz in der Vergleichstabelle, aber keinen Wechsel. Etablierte Anbieter gewinnen über Vertrauen, Integrationen und Daten, die schon bei ihnen liegen. Und ein deutlich billigerer Preis wirkt auf Geschäftskunden eher riskant als attraktiv. Besser ist ein Vorteil, den der Große nicht bietet, zum Beispiel ein Mensch, der Support-Mails schnell beantwortet.

Mit dem ersten zahlenden Kunden ändert sich deine Rolle

Zurück zur Sterilisator-App. Im Beitrag selbst steht, was nach dem Verkauf kam: Fällt morgens vor dem ersten Patienten etwas aus, merkt es ein ganzes Praxisteam. Einmal kam früh am Morgen eine panische Mail, weil die Einträge scheinbar verschwunden waren. Die Ursache war ein Zeitzonenfehler, gefunden durch Fehlermeldungen, die in Lovable kopiert wurden.

Die Kommentare waren deutlich. In einer regulierten Branche entsteht mit der ersten Zahlung echte Verantwortung. Was passiert, wenn bei einer Kontrolle die Aufzeichnungen fehlen? Mehrere erfahrene Entwickler rieten zu:

• automatischen Backups und einer Wiederherstellung, die wirklich getestet wurde
• einer Änderungshistorie, die sich nicht nachträglich überschreiben lässt
• Exporten, die Kunden selbst aufbewahren können
• einem Blick darauf, welche Dokumentationspflichten in jedem Markt gelten
• einem Review durch jemanden, der Software professionell baut

Ein Vorschlag fand besonders viel Anklang: Die App als digitale Ergänzung zum bestehenden Ablauf zu verkaufen, nicht als Ersatz. Wer zusätzlich ausdruckt oder exportiert, verliert bei einem Ausfall nichts. Wie du Zugriffe und Daten vor dem Livegang selbst prüfst, zeigt der Zwei-Konten-Test.

Was das für deinen Launch bedeutet

Dein internes Tool ist ein guter Ausgangspunkt, weil du das Problem aus eigener Erfahrung kennst. Bevor du Geld nimmst, plan aber drei Dinge mit ein, die beim Eigengebrauch keine Rolle spielten.

Erstens die Daten: Backups, Wiederherstellung, Export. Zweitens die Erreichbarkeit: Wer antwortet, wenn es beim Kunden früh am Morgen brennt? Drittens den Rahmen: Welche Pflichten gelten in der Branche, und was versprichst du vertraglich? Arbeite die Punkte der Launch-Checkliste durch, bevor der erste Kunde zahlt.

Deine To-dos für diese Woche: Schreib auf, womit drei potenzielle Kunden das Problem heute lösen. Notiere, was im schlimmsten Fall passiert, wenn deine App einen Tag ausfällt. Und teste einmal, ob du ein Backup wirklich zurückspielen kannst.

Du hast ein Werkzeug, das im eigenen Alltag funktioniert, und willst wissen, ob es das Zeug zum Produkt hat? Trag dich in die Warteliste ein und schildere deine Idee – du bekommst eine ehrliche Einschätzung, ob sie zum geplanten Bootcamp passt.