Headerpicture

Software bauen, bevor der Kunde bestellt?

Klassische Individualsoftware wird meist über Spezifikationen und Tagessätze verkauft. Mit einem vorbereiteten Tech-Stack und KI-Agenten lässt sich ein lauffähiges MVP bereits auf Basis des Erstgesprächs bauen und zusammen mit dem Angebot vorlegen. Bezahlt wird dabei der funktionierende Prototyp zum Festpreis statt der dafür aufgewendeten Arbeitsstunden.

Abonniere meinen Newsletter!

Wöchentliche Updates zu Tools, KI und digitalem Alltag. Ohne Buzzword-Bingo. E-Mail eintragen und los.

Nur mal ein Gedankenexperiment:

Softwareunternehmen könnten im Vertrieb von Individualsoftware auf Leistungsbeschreibungen verzichten und die Anwendung direkt als MVP bauen. Skizziert ein Kunde einen konkreten Bedarf, entsteht das System auf eigenes Risiko. Passt das Ergebnis, greift ein Festpreis von, sagen wir mal, 30.000 Euro. Lehnt der Kunde ab, bleibt die Software beim Dienstleister.

Die technische Grundlage dafür ist eine KI-gestützte Software-Factory. Der Ablauf beginnt mit einem Gespräch von 1 bis 2 Stunden über Problemstellung und Arbeitsabläufe. Das Transkript dient als strukturierter Input für die Agenten-Pipeline.

Ein vordefiniertes Agent OS übernimmt die Detailumsetzung. Feste Stacks für Authentifizierung, Routing, UX-Patterns und DevOps nehmen Standardentscheidungen vorweg. Entwickler definieren Datenmodell und Systemarchitektur, die Agents generieren den Code. Nach kurzer Zeit steht ein lauffähiger MVP bereit. Dessen Qualität hängt direkt am Reifegrad der Software-Factory. Über diesen Reifegrad differenzieren sich Dienstleister künftig im Wettbewerb.

Ohne Auftrag und Vergütung Software zu entwickeln, war bisher betriebswirtschaftlich unsinnig. Der geringe Erstellungsaufwand in der Factory verändert diese Rechnung: Der Kunde bedient direkt ein funktionierendes System, statt Spezifikationen freizugeben.

Entscheidet sich der Kunde für den Kauf, folgen Finetuning, technische Härtung, Deployment auf seiner Infrastruktur und Gewährleistung. Lehnt er das System ab, wandern Code und Patterns zurück in die interne Bibliothek. Eine lauffähige Anwendung beendet die Diskussion über Annahmen und Pflichtenhefte.