Freitagnachmittag, drei Stunden mit Claude, und aus dem alten Excel-Sheet ist eine Web-App geworden. Sieht gut aus, rechnet richtig, das Team ist begeistert. Wir kennen dieses Gefühl – wir haben genau das mit unserem eigenen Schätz-Tool durchgespielt.
Und dann kommt der Montag. Jemand fragt: „Können wir das nicht unseren Kunden geben?" Die IT fragt: „Wer wartet das?" Und du fragst dich: Was würde es eigentlich kosten, daraus eine richtige Software zu machen?
Genau darum geht es hier. Nicht um die Frage, ob KI Software-Entwicklung billiger macht (kurze Antwort: ja, aber vielleicht an einer anderen Stelle als vermutet), sondern um die ehrliche Rechnung dahinter – mit echten Zahlen aus unseren Projekten.
- Ein einfacher Prototyp per Vibe Coding kostet heutzutage "fast nichts". Produktionsreife Software kostet weiterhin Geld – die Positionen haben sich aber verschoben.
- KI senkt vor allem die Kosten fürs Code schreiben. Architektur, Security, Review und Betrieb bleiben – oder werden unter Umständen zu größeren Posten. Man darf nicht vergessen, dass bspw. Vibe Coding (ohne harte Eingrenzung) oft zu aufgeblähten Apps führt. Funktions-Überfluss sozusagen.
- Unsere realen Projekte lagen zwischen 6.000 € (Prototyp) und 90.000 € (komplexe Anwendung mit Rechtemanagement). Es bleibt eine große Spanne, aber KI verschiebt sie nach unten – wenn das Setup stimmt.
- Der Hebel dafür ist kein einzelnes Tool, sondern ein KI Engineering Framework: gemeinsame Standards, Guardrails, Referenzarchitektur.
- Die frei werdenden Ressourcen gehören nicht in mehr Features, sondern in Research und Design. Produkte scheitern selten am Code sondern am Markt.
Der Prototyp ist nicht dein Produkt
Als wir unser Excel-Schätz-Tool per Vibe Coding in eine Web-App verwandelt haben, stand am Ende eine funktionierende Anwendung: 918 Zeilen Code in einer einzigen HTML-Datei, PERT-Berechnungen korrekt, UI ansehnlich. Kostenpunkt: ein paar Stunden und ein Claude-Abo. Ein schöner Test.
Beim ersten Blick unter die Haube sah es damals anders aus: XSS-Lücken durch unsicheres innerHTML, alles im globalen Scope, keine Validierung (der Best Case durfte größer sein als der Worst Case), keine Tests, keine Dokumentation. Für ein internes Einzelnutzer-Tool: völlig okay. Für alles, was mehrere Menschen, echte Daten oder eine IT-Abteilung berührt: nicht deploybar.
Da hört man gleich die Unkenrufe: "Das kann KI halt nicht..." Das wäre aber zu pauschal. Was hier passiert ist, ist der Unterschied zwischen einem schmutzigem Prototypen und echter Software. Der Prototype beweist, dass eine Idee funktioniert. Software muss auch nächstes Jahr noch funktionieren – wenn der Praktikant sie bedient, der Angreifer sie testet und die Kollegin sie weiterentwickeln möchte.
Was Software wirklich kostet: ein Tool, drei Ausbaustufen
Bevor wir zur KI-Frage kommen, die Baseline. Bleiben wir beim Beispiel, das du schon kennst: ein gewachsenes Excel-Tool zur Projektkalkulation, das echte Software werden soll. Je nachdem, was „echte Software" heißen soll, reden wir über sehr unterschiedliche Projekte. Die Preisspannen stammen aus realen Projekten unserer Praxis – ausführlicher aufgeschlüsselt im Kosten-Artikel:
| Ausbaustufe | Was dazukommt | Kostenrahmen |
|---|---|---|
| „S" – der validierte Prototyp | Workshop, Berechnungslogik sauber als Web-App umgesetzt, einfaches UI, mobiltauglich, Hosting. Ein kleiner Nutzerkreis, keine Rollen, keine Integrationen. | 6.000–9.000 € |
| „M" – die Abteilungslösung | Login und zentrale Datenhaltung mit Datenbank, mehrere Nutzer:innen arbeiten gleichzeitig, Anbindung bestehender Schnittstellen (z. B. Projektdaten aus dem ERP), Frontend nach eurer Design-Vorlage. | 10.000–20.000 € |
| „L" – die unternehmensweite Software | Integration ins zentrale User-Management, 3-stufige Nutzerrollen mit eigenen Rechten, Datenversionierung, 3 Sprachen, Testumgebung ohne Live-Daten, automatisiertes Deployment, On-Premise-Betrieb. | 80.000–90.000 € |
Auffällig: Die Kernfunktion – kalkulieren, speichern, anzeigen – ist auf allen drei Stufen praktisch dieselbe. Was den Preis mehr als verzehnfacht, ist alles drumherum: Authentifizierung, Rollen und Rechte, Datenversionierung, Integration in bestehende IT, Deployment, Testumgebung.
Und genau diese Posten gehen oftmals unter.
Wohin das Geld heute fließt (und wohin nicht mehr)
Die gute Nachricht: KI-gestützte Entwicklung verändert die Rechnung wirklich. Die reine Implementierung – das Tippen von Komponenten, Formularen, CRUD-Logik – ist deutlich schneller geworden. In unserem Home-Turf-Stack (TypeScript, React, Next.js) funktioniert das besonders gut, weil die Modelle dieses Ökosystem in- und auswendig kennen und der TypeScript-Compiler Fehler oft schon beim Kompilieren abfängt.
Die nicht-so-schöne Nachricht: Die Posten, die schon immer den Unterschied zwischen „S" und „L" ausgemacht haben, werden durch KI nicht billiger. Teilweise werden sie teurer:
- Review statt Schreiben. Wenn die KI in einer Stunde 2.000 Zeilen produziert, wird das Nadelöhr die Frage, wer diese Zeilen versteht und verantwortet. Ungelesener Code ist keine Ersparnis. Sowas rächt sich meistens eher früher als später.
- Security und Compliance. Secrets im Code, ungeprüfte Dependencies, fehlende Zugriffskontrollen – die klassischen Prototyp-Sünden skalieren mit dem Tempo der Codegenerierung mit. Je tiefer dein Tool in dein Geschäft integriert ist, desto kritischer werden diese Punkte.
- Architektur und Konsistenz. Vier Teams mit vier KI-Setups bauen vier verschiedene Lösungen für dasselbe Problem. Jede App eine Insel – und jede Insel kostet eigene Wartung.
KI hat nicht die Kosten von Software gesenkt. Sie hat die Kostenstruktur gedreht. Früher war Schreiben teuer und der Rest kam obendrauf. Heute ist Schreiben billig – und der Rest ist das Projekt.
Ein Teil der Lösung: ein KI Engineering Framework
An dieser Stelle könnten Agenturen schnell sagen: „Deshalb braucht ihr Profis." Stimmt aber nur halb. Was Teams tatsächlich brauchen, ist ein Setup, in dem KI-Geschwindigkeit und Produktionsqualität kein Widerspruch sind. Wir nennen das ein KI Engineering Framework, und es besteht aus drei Bausteinen die wir zum Beispiel bei einem großen Automobilhersteller einsetzen. Das schöne ist hierbei auch, dass du KI-Modell-unabhängig bleibst:
1. Team-Standards
Eine AGENTS.md mit euren Konventionen – dem offenen Standard, den Cursor, Copilot und Codex nativ lesen. Claude Code setzt zwar auf CLAUDE.md, lässt sich aber problemlos an die AGENTS.md anbinden. So liegt eure Konvention an einer zentralen Stelle, nicht verstreut über vier verschiedene Tools. Was heute im Kopf einzelner Entwickler:innen steckt, wird dokumentiert und versioniert. Das senkt die Review-Kosten, weil die KI von Anfang an so baut, wie euer Team baut.
2. Technische Guardrails
Automatisierte Prüfungen in Schichten, geordnet von billig nach teuer: Pre-Commit-Hooks, statische Analyse, Supply-Chain-Checks, KI-Review, menschliches Review. Jede Schicht fängt eine andere Fehlerklasse ab. Eine Regel ist dabei nicht verhandelbar: KI-generierter Code geht nie ungeprüft in Produktion.
3. Referenzarchitektur
Ein forkbares Setup mit Auth, Tests, CI/CD und Security-Checks, fertig verdrahtet. Neue Projekte starten von einer erprobten Basis statt von einer leeren Datei. Genau die Posten, die Projekt „L" teuer gemacht haben – Authentifizierung, Rollen, Deployment – sind hier bereits gelöst.
Der Effekt auf die Kostenrechnung: Der Weg vom Prototyp zur Software ist kein Neuanfang mehr sondern du startest mit einem stabilen Fundament. Die L-Kategorie mit 80.000€ verschwindet nicht, aber sie rückt näher an die 20.000-€-Kategorie heran – und vor allem wird sie planbar.
Was würde der Weg für euren Prototyp konkret kosten?
Im Erstgespräch schauen wir uns euer Setup an und sagen euch ehrlich, welche Bausteine sich lohnen – und welche nicht.
Gespräch vereinbarenDer zweite Shift: Das Geld wandert von Code zu Produkt
Bis hierhin klingt es, als wäre der Weg vom Prototyp zur Software vor allem ein Engineering-Problem. Ist er aber nur zur Hälfte. Denn die unbequemste Wahrheit ist: Die meisten Produkte scheitern weder am Code noch am Design – sie scheitern daran, dass niemand sie braucht.
Und genau hier wird KI-Prototyping richtig interessant. Wenn ein Prototyp statt Wochen nur noch Tage kostet, gibt es zwei Möglichkeiten, mit der gewonnenen Zeit umzugehen: schneller mehr bauen – oder schneller herausfinden, was überhaupt gebaut werden sollte.
Hypothesen testen statt Features stapeln
Erinnerst du dich an Projekt „S" von oben, den Prototyp für 6.000–9.000 €? Für dasselbe Budget bauen wir heute mit KI-Unterstützung deutlich komplexere Prototypen. Aber ob deine Zielgruppe das Ergebnis auch „kauft", steht auf einem anderen Papier – und diese Frage beantwortet kein noch so schneller Prototyp von allein.
Unsere Empfehlung ist deshalb ziemlich einfach: Steck die frei werdenden Ressourcen nicht in mehr Features, sondern in (User)Research. Sprich mit deiner Zielgruppe, formuliere Hypothesen, und teste sie – gerne mit selbst gebauten Vibe-Coding-Prototypen, das ist genau ihr Sweet Spot. Was sich bewährt, überführen wir anschließend in ein verlässliches Produkt. So entsteht nicht schneller Müll, sondern schneller validiertes Wissen über deinen Markt. Genau dafür machen wir zum Beispiel Lean-Inception- und Design-Sprint-Workshops.
Deine Brand gehört nicht der KI
Der zweite Punkt, der beim schnellen Bauen gern hinten runterfällt: das Interface. Ist dir aufgefallen, dass sich Software-Produkte immer ähnlicher sehen? Das ist kein Bauchgefühl. Ein Forschungsteam der Indiana University hat vor Jahren bereits rund 200.000 Screenshots von 10.000 Websites analysiert: Die Layout-Unterschiede zwischen Websites sind zwischen 2010 und 2016 um über 30 % geschrumpft – am vielfältigsten war das Web 2008 bis 2010 (Goree et al., CHI 2021). Haupttreiber war damals, ohne KI: geteilte Libraries wie Bootstrap mit ihren Default-Layouts.
Das war vor KI-Coding. Heute generieren Millionen Entwickler:innen ihre UIs mit denselben Modellen, die auf denselben Patterns trainiert wurden und dieselben Defaults vorschlagen. Belastbare Studien zur KI-Ära gibt es noch nicht – aber die Mechanik ist dieselbe wie bei den Libraries, nur mit ganz anderem Umfang.
Für dein Produkt heißt das: Wenn du die KI einfach machen lässt, bekommst du das Durchschnitts-Interface des Internets. Funktional, aufgeräumt – und austauschbar. Deine Brand sollte nicht von der KI überrollt werden, sondern die KI sollte in deinem Design System agieren. Technisch ist das einfach lösbar: Ein ans Design System angebundenes KI-Setup (etwa per MCP) sorgt dafür, dass Agenten eure Komponenten wiederverwenden, statt bei jedem Feature neue Varianten zu erfinden. Das ist übrigens ein fester Baustein im Framework.
Je einzigartiger dein Geschäft, desto weniger hilft dir der Autopilot
Dahinter steckt ein Muster, das man sich klarmachen sollte: KIs sind richtig gut in dem, was oft gebaut wurde. Login, Dashboard, Checkout, CRUD – davon hat sie Millionen Varianten im Training gesehen. Deine interne Domänenlogik hat sie (hoffentlich) noch nie gesehen. Die Preisstaffel, die euer Vertrieb über Jahre verhandelt hat, die Sonderfälle in eurer Produktionsplanung, die Regel, warum Kunde A anders abgerechnet wird als Kunde B: Genau dort rät das Modell, statt zu wissen.
Das ist keine schlechte Nachricht, im Gegenteil. Ein einzigartiges Business besteht technisch trotzdem größtenteils aus Standardbausteinen – und die baut die KI schnell und günstig. Aber der Teil, mit dem du dich vom Wettbewerb unterscheidest, ist zugleich der Teil, bei dem Vibe Coding am wenigsten hilft. KI kommoditisiert das Austauschbare. Dein Wert wandert in genau die Teile, die sie nicht kann: deine Domäne, dein Design, dein Verständnis der Zielgruppe. Umso wichtiger, dass diese Teile sauber gebaut, getestet und verantwortet werden.
Wir arbeiten seit 2012 im Stack, den KI liebt
Ein Punkt zum Abrunden, der uns zugegebenermaßen in die Karten spielt: Im August 2025 wurde TypeScript erstmals die meistgenutzte Sprache auf GitHub – vor Python und JavaScript, mit rund 2,6 Millionen monatlichen Contributors und einem Zuwachs von über 66 % in einem Jahr (GitHub Octoverse 2025). GitHub selbst nennt den Treiber beim Namen: KI. Typisierte Sprachen geben Agenten Leitplanken – die GitHub-Studie aus 2025 fand, dass 94 % der Kompilierfehler in LLM-generiertem Code Type-Check-Fehler waren. Genau die Fehler, die TypeScript abfängt, bevor sie in Produktion landen.
Anders gesagt: Das Ökosystem, in dem KI-Coding heute am zuverlässigsten funktioniert – TypeScript, React, Node.js – ist das Ökosystem, in dem wir seit 2012 Software bauen. Wir mussten unseren Stack für die KI-Ära nicht wechseln. Die KI-Ära ist zu unserem Stack gekommen. Puh :)
Was heißt das für dich?
Du hast einen Prototyp, der sich bewährt hat? Dann lass ihn nicht in der Schublade sterben und bau ihn auch nicht heimlich produktiv aus. Der eleganteste Zwischenschritt: Lass die KI selbst die Anforderungen dokumentieren („Fasse alle Requirements aus unserer Konversation zusammen, ich möchte sie einer Software-Firma zeigen") – und hol dir dann eine ehrliche Einschätzung von uns. Unser Vibe Coding Audit prüft Architektur, Security und Wartbarkeit, bevor aus Risiken teure Probleme werden.
Du hast noch gar nichts gebaut, nur eine Idee? Beste Ausgangslage. Bevor auch nur ein Prototyp entsteht: Hypothesen formulieren, Zielgruppe verstehen, dann klein testen. Ein Lean-Inception- oder Design-Sprint-Workshop klärt in wenigen Tagen, was dein Produkt beweisen muss – bevor du Geld in die falsche Richtung baust.
Dein Team entwickelt schon mit KI? Dann ist die Frage nicht mehr ob, sondern wie konsistent. Wenn jede:r ein eigenes Setup hat, Secrets im Repository liegen oder Pull Requests auf tausend Zeilen anwachsen, die niemand mehr liest, wird das zu deinem Kernproblem werden. Genau dafür gibt es das Framework – vom 1–2-tägigen Workshop bis zum Rollout.
