Wenn KI fast alles baut: Wie bleibt SaaS bestehen?

Wenn Code kaum noch etwas kostet, schützen nicht Funktionen ein SaaS-Produkt, sondern Daten, Vertrauen und Vertrieb, und wer etwas Neues baut, gibt womöglich mehr Geld und Zeit dafür aus, gefunden zu werden, als dafür, es zu bauen.

SaaS (Software, für die man Abo-Gebühren zahlt und die man über das Internet nutzt) gibt es nach wie vor. Aber wird es sich weiter verkaufen, wenn KI den größten Teil des Codes schreibt? Diese Frage stelle ich mir derzeit oft. Dieser Text ist kein Nachrichtenbericht, sondern meine Meinung.

Werkzeuge wie Claude Code haben das Tempo, mit dem sich Software bauen lässt, fast unheimlich gesteigert. Was früher Wochen oder Monate dauerte, geht heute in ein paar Tagen. Wer eine Idee in Worte fassen und ein paar APIs anschließen kann, hat übers Wochenende ein laufendes Produkt. Dann spricht nichts dagegen, dass jemand anderes dasselbe baut.

Nehmen wir ein einfaches SaaS für 29 US-Dollar (rund 26 Euro) im Monat. Wenn sich seine Kernfunktion mit einem guten Prompt und ein paar Stunden Arbeit nachbauen lässt, wer zahlt dann weiter?

Diese Sorge hat ein Projekt noch verstärkt, das zuletzt auf GitHub viel Aufmerksamkeit bekam: REA.

REA (Reverse Engineer Anything) ist ein Open-Source-Werkzeug unter MIT-Lizenz, das KI-Coding-Agenten wie Claude Code, Codex und Cursor mit Reverse-Engineering-Werkzeugen verbindet. Reverse Engineering heißt, ein Programm ohne Quellcode auseinanderzunehmen, um herauszufinden, wie es funktioniert. Der Agent nutzt Analysewerkzeuge wie Ghidra, Hopper und IDA (Programme, die eine ausführbare Datei lesbar machen) und erklärt anhand von Belegen, wie sich eine Datei oder App verhält. Das Ergebnis ist nicht der ursprüngliche Quellcode, sondern Pseudocode (eine für Menschen lesbare, codeähnliche Umschreibung) und Assembler (maschinennahe Befehle). Außerdem betrachtet REA nur, was auf der Seite der Nutzer liegt: Desktop- oder Mobil-Apps, den Frontend-Code von Websites, Firmware und Ähnliches. Der Backend-Code eines SaaS, der nur auf den Servern eines Unternehmens läuft, ist davon nicht betroffen.

Einige Berichte melden, das Projekt habe innerhalb einer Woche über 100.000 Sterne auf GitHub bekommen. Die Zahlen unterscheiden sich je nach Quelle, die genaue Zahl konnte ich nicht bestätigen. Manche Entwickler reagierten mit „Kann man Apps jetzt allein aus der Binärdatei nachbauen?“ und „Der Burggraben der Software (die Hürde, die Wettbewerber fernhält) ist weg.“

Was mich dabei beschäftigt, ist weniger die Leistung des Tools als der Wandel in der Wahrnehmung. Früher war „Programmieren ist schwer“ die Schutzmauer. Dann geriet „einfach bauen“ ins Wanken, und nun kommt hinzu: „Man kann das Verhalten auch ohne Quellcode einsehen.“ Zwischen Demo und echtem Produkt klafft weiterhin eine große Lücke. Wer aber etwas auf den Geräten der Nutzer ausliefert, etwa eine Desktop- oder Mobil-App oder eine Browser-Erweiterung, kann sich nicht mehr ohne Weiteres darauf verlassen, dass „meine Logik geheim bleibt“. Code, der nur auf einem Server liegt, lässt sich mit diesem Tool nicht lesen, aber Oberfläche und Verhalten sind so weit nachbaubar, wie man sie sieht. Der Wert der Fähigkeit zu bauen und der Fähigkeit zu verstecken sinkt, und zwar beide. Was an ihre Stelle tritt, kann auch ich noch nicht sagen.

Wächst bestehendes SaaS weiter?

Ein etabliertes SaaS stirbt nicht über Nacht. Kundschaft hat Daten und Arbeitsabläufe längst darin abgelegt, und im Unternehmen ist schon der Satz „Lasst uns auf etwas anderes wechseln“ ein Kostenfaktor. Schnittstellen, Rechte, Prüfprotokolle und Support ersetzt kein Klon (ein nachgebautes Imitat) vom Wochenende von heute auf morgen.

Es verschiebt sich aber, woran das Wachstum hängt. Produkte, die sich nur über Funktionen abhoben, bekommen zuerst Preisdruck. Abos pro Arbeitsplatz, bei denen jede nutzende Person einzeln bezahlt wird, laufen womöglich nicht mehr so glatt, wenn Automatisierung die Zahl der Arbeitsplätze schrumpfen lässt. Umgekehrt kann ein Produkt, das die Arbeit einer bestimmten Branche bis zum Ende übernimmt, stärker werden. Je mehr Daten sich ansammeln und je tiefer die Anbindungen reichen, desto weniger ist die Monatsgebühr ein Geld für Funktionen und desto mehr ein Geld dafür, das Problem nicht selbst tragen zu müssen. Was REA erschüttert hat, ist die Annahme „Den Code sieht niemand, also ist er sicher“. Nicht erschüttert hat es: „Unsere Daten liegen hier, und wir arbeiten jeden Tag mit diesem Bildschirm.“

Wer neu baut: Welche Risiken kommen dazu?

Dass Bauen billig geworden ist, heißt auch: Der Einstieg mit derselben Idee ist billig geworden. Ich sehe vier Risiken.

Nachbau und Preis.
Was am Wochenende gebaut wurde, kann auch jemand anderes am Wochenende bauen. Die Haltbarkeit von „Ich war zuerst da“ ist kurz geworden. 29 bis 99 US-Dollar (rund 26 bis 88 Euro) im Monat halte ich weiterhin für möglich. Wenn der Grund dafür aber „Das zu programmieren ist schwer“ oder „Der Quellcode ist geschlossen“ lautet, wird es unsicher. Sobald Kundschaft glaubt, selbst etwas Ähnliches bauen zu können, wird das Abo zum Luxus. Man muss überzeugen, dass man Bau, Reparatur und Schutz stellvertretend übernimmt.

Wartung und Betrieb.
Demos sind leicht, der Betrieb bleibt schwer. Ausfälle, Sicherheit, Zahlungen, Kundenanfragen und Änderungen an Modellen oder APIs beantworten die Frage „Wer haftet?“ nicht, auch wenn KI den Code schneller schreibt. Wer allein betreibt, trägt alles allein.

Marktwahl.
Wer in einem breiten Markt eine dünne Funktion verkauft, stößt sofort auf größere Werkzeuge und billigere Kopien. Wer ein enges Problem tief angeht, hat einen kleinen Markt, muss die Branche kennen und braucht Zeit, um Vertrauen aufzubauen. Der Wunsch nach schnellem Umsatz und der Wunsch nach einem schwer kopierbaren Platz ziehen oft in verschiedene Richtungen.

Vertrieb.
Je leichter das Bauen, desto mehr Produkte werden nie gefunden. Heute ist ein Produkt, das gebaut, aber nicht gesehen wird, so gut wie nicht vorhanden. Ohne Kanal bleibt selbst ein gut gemachtes fertiges Produkt Ladenhüter.

Produkte im Überfluss: Steigen die Marketingkosten?

Ich glaube ja, zumindest wenn man dieselbe Menge an Aufmerksamkeit kaufen will. Das Angebot an Produkten ist gewachsen, die Aufmerksamkeit der Menschen, die Suchergebnisse und der Platz in Feeds aber nicht im gleichen Maß. Wenn sich ähnliche Landingpages (die erste Seite, die ein Produkt vorstellt) und ähnliche „KI-gebaute ___“ häufen, kostet es Kundschaft mehr, auszuwählen, und Anbieter mehr, im Gedächtnis zu bleiben.

Wird Entwicklung billiger, können sich auch Einzelentwickler Werbung leisten, die dafür vorher kein Geld hatten. Dann bieten aber auch mehr Menschen mit. Der Engpass wandert von der Entwicklung zu den Kosten der Kundengewinnung (CAC, das Geld, das ein neuer Kunde oder eine neue Kundin kostet). Bei einem Produkt für 29 US-Dollar im Monat verlängert schon ein kleiner Anstieg des CAC die Zeit, bis sich das Produkt trägt. Bauen dauert ein Wochenende, Marketing kann Monate dauern.

Eine enge Nische, ein bestehendes Kundennetz, Mundpropaganda und Fachwissen, das in der Suche lange auffindbar bleibt, spüren steigende Werbepreise weniger. Das heißt aber nicht, dass Marketing billig ist. Es heißt, dass man den Vertrieb schon besitzt oder selbst aufbaut.

Muss man sich bei den Firmen mit dem Traffic gut stellen?

Steigen die Marketingkosten, lautet die nächste Frage, ob man sich bei den Plattformen anstellen muss, die die Menschen versammeln. Suche, App-Stores, soziale Netzwerke, Marktplätze, Plug-in-Läden großer SaaS-Anbieter und künftig auch die Plätze, an denen KI-Assistenten etwas empfehlen: Der Traffic sammelt sich vor wenigen Türen. Wer hindurch will, muss sich an Regeln, Gebühren und Empfehlungslogik anpassen. „Sich gut stellen“ ist keine Schmeichelei, sondern eher die Frage, ob das eigene Produkt zu den Anreizen dieses Unternehmens passt.

Das hat seinen Preis. Ändern sich Rankings oder API-Regeln oder baut die Plattform eine ähnliche Funktion selbst ein, kann die Sichtbarkeit über Nacht verschwinden. Ignorieren lässt sich das trotzdem schwer. Abo-Kundschaft allein über eigenen Vertrieb zu gewinnen, ist eine größere Aufgabe als die Entwicklung. Deshalb gilt für mich: Wer den Traffic nur einer Tür anvertraut, macht diese Tür zum Geschäft. Wer sich auf eine Plattform setzt, aber einen Teil der Kundenbeziehung, der Daten und der Ausstiegswege in eigener Hand behält, schließt einen Kompromiss. Wer die gesamte Sichtbarkeit abgibt, mietet nur.

Braucht man Geld, um zu entwickeln?

Fürs reine Entwickeln gilt eher das Gegenteil. KI-Coding-Werkzeuge, Cloud, Zahlungsdienste und Vorlagen haben die Schwelle gesenkt, ein Produkt zu bauen und online zu stellen. „Man braucht Kapital, um zu entwickeln“ trifft im Jahr 2026 in der Prototypenphase immer weniger zu.

Übrig bleibt eine andere Sorte Geld: Geld, um sichtbar zu werden, abzuwarten und Ausfälle und Kundschaft zu verkraften. Steigt der CAC, kommen Plattformgebühren dazu und beginnt ein Preiskampf, braucht man Bargeld, um bis zum Gewinn durchzuhalten. Der Zweck des Geldes verschiebt sich vom Kauf von Code zum Kauf von Zeit. Bootstrapping (mit selbst verdientem Geld wachsen, ohne Investoren) ist nicht unmöglich geworden. Die Strecke, die man bewältigen muss, hat sich von der Entwicklung zu Vertrieb und Überleben verschoben. Mit viel Geld kann man diese Strecke durch Werbung und Einstellungen kaufen. Mit wenig muss man früher billigere Wege des Vertriebs wählen: einen engen Markt, bestehende Beziehungen oder Inhalte.

Fazit

Ich habe noch keine Antwort. Die Richtung ist aber etwas klarer geworden. Das Risiko für alle, die neu bauen, ist weniger technisches Scheitern als die Lage auf der Seite, die leicht zu bauen, leicht abzuschauen und leicht zu übersehen ist. Was andere am Wochenende nicht einholen, sind das Verständnis für das Problem der Kundschaft, Anbindungen und Daten, Vertrauen und Vertrieb. Diese vier lagen schon immer außerhalb des Codes. Ein Produkt muss deshalb von Anfang an drei Fragen beantworten, finde ich: „Warum ist dieses Abo schwer zu kündigen?“, „Wie wird es gefunden?“ und „An wen vermiete ich diese Sichtbarkeit nicht?“ Das Bauen ist billig geworden, und was danach kommt, teuer.

Was sich für Entwickler ändern könnte

Das Folgende ist unsere Einschätzung und unser Rat, der auf der persönlichen Sicht dieses Textes beruht.

• Prüfen Sie, womit Ihr Preis begründet ist. Stellen Sie fest, ob Datenhaltung, Anbindungen, Verantwortung und Vertrauen den Preis tragen und nicht „Programmieren ist schwer“ oder „Der Quellcode ist geschlossen“.
• Wer auf den Geräten der Nutzer ausliefert, etwa als Desktop- oder Mobil-App oder als Browser-Erweiterung, sollte davon ausgehen, dass sich die Kernlogik von außen lesen lässt, und festlegen, welche Teile auf einen Server wandern.
• Legen Sie vor dem Bauen fest, wo Sie Ihre Kundschaft treffen. Überlassen Sie die Sichtbarkeit nicht nur einer Plattform und behalten Sie einen Teil von Kundenliste und Daten in eigener Hand.
• Bei knappem Geld wählen Sie zuerst Vertrieb, der wenig Werbung kostet: einen engen Markt, bestehende Beziehungen oder Inhalte.

Was als Nächstes zu beobachten ist

• Wie stark Reverse-Engineering-Werkzeuge wie REA tatsächlich zum Nachbau kommerzieller Produkte genutzt werden und welche Regeln Hersteller und Plattformen darauf einführen.
• Ob die Kriterien öffentlich werden, nach denen KI-Assistenten und App-Stores Werkzeuge empfehlen.

Umrechnung in Euro nach dem Kurs vom 16. Okt. 2026 (1 US-Dollar ≈ 0,89 Euro), gerundet.

Quellen

• REA: Reverse Engineer Anything (GitHub)