19. Juli 2025·7 Min
KI-Baukostenschätzung nach Feature: eine einfache Budgetmethode
KI-Kostenschätzung leicht gemacht: Prognostiziere Credits und Tokens pro Feature, grenze Prompts ein und vermeide Nacharbeit, damit deine App im Budget bleibt.
KI-Kostenschätzung leicht gemacht: Prognostiziere Credits und Tokens pro Feature, grenze Prompts ein und vermeide Nacharbeit, damit deine App im Budget bleibt.
KI-gestütztes Bauen wirkt günstig — bis es plötzlich teuer wird. Das liegt daran, dass du nicht für einen festen Feature-Preis zahlst, sondern für Versuche: Nachrichten, generierten Code, Revisionen, Tests und Nacharbeit. Wenn der Plan verschwommen ist, steigt die Anzahl der Versuche schnell.
Die meisten Kostenexplosionen folgen den gleichen Mustern:
Wenn du schätzt, sei klar, wofür du das Budget eigentlich ansetzt:
Betrachte jede Schätzung als Bereich, nicht als Einzelwert. Ein Feature kann in der UI klein aussehen, aber komplizierte Logik erfordern — oder umgekehrt. Best-Case ist ein starker erster Entwurf. Worst-Case sind mehrere Korrekturschleifen.
Der Rest dieses Guides nutzt wiederholbare Feature-Buckets: Auth, CRUD, Integrationen und UI-Redesigns. Wenn du eine kreditbasierte Vibe-Coding-Plattform wie Koder.ai (koder.ai) nutzt, bemerkst du das schnell: mit „Baue ein Dashboard“ starten und später Rollen, Audit-Logs und neues Layout hinzufügen verbraucht deutlich mehr Credits, als diese Anforderungen vorher klar zu beschreiben.
Manche vermischen drei verschiedene Ideen: Tokens, Credits und Build-Schritte. Wenn du sie trennst, wird Kostenprognose einfacher.
Ein Token ist ein kleines Textstück, das das Modell liest oder schreibt. Dein Prompt nutzt Tokens, die Antwort des Modells nutzt Tokens, und ein langer Chatverlauf verbraucht Tokens, weil das Modell ihn erneut lesen muss.
Ein Credit ist die Abrechnungseinheit deiner Plattform. Bei Tools wie Koder.ai decken Credits in der Regel die Modellnutzung plus Plattformarbeit hinter dem Chat (zum Beispiel Agenten, die Aufgaben ausführen, Dateien erstellen und Ergebnisse prüfen). Du musst nicht die internen Details kennen, aber du musst erkennen, was die Nutzung wachsen lässt.
Ein Build-Schritt ist eine sinnvolle Änderung am Projekt: „E-Mail-Login hinzufügen“, „Users-Tabelle erstellen“ oder „diesen Screen an einen Endpoint anbinden“. Ein einzelnes Feature braucht oft viele Schritte, und jeder Schritt kann mehrere Modellaufrufe auslösen.
Die Nutzung steigt am schnellsten, wenn du langen Kontext hast (große Specs, viel Chatverlauf, viele referenzierte Dateien), viele Iterationen, große Outputs (vollständige Dateinewrites, große Codeblöcke) oder mehrdeutige Anforderungen, die das Modell raten lassen.
Kleine Prompt-Änderungen können die Kosten stark beeinflussen, weil sie die Anzahl der notwendigen Retries ändern. „Ein komplettes Auth-System“ lädt Optionen ein, die du nicht wolltest. „E-Mail und Passwort nur, kein Social Login, genau zwei Screens“ reduziert die beweglichen Teile.
Eine Regel, die sich bewährt: weniger bewegliche Teile bedeuten weniger Retries.
Hör auf, in „Screens“ oder „Nachrichten“ zu schätzen. Schätze in Features, die ein Nutzer laut nennen würde. Das verbindet das Budget mit Ergebnissen, nicht mit der Gesprächigkeit des Builds.
Für jedes Feature schätze drei Teile:
Die meisten Überschreitungen passieren beim Testen und bei Revisionen, nicht beim ersten Entwurf.
Verwende für jeden Teil eine Spanne: niedrig (einfach), typisch (einige Rückfragen), hoch (Überraschungen). Wenn deine Plattform kreditbasiert ist, verfolge es in Credits. Wenn du Tokens direkt verfolgst, halte Tokens fest. Der Punkt ist: eine Prognose, die ehrlich bleibt, wenn die Realität sich ändert.
Zwei Zeilen helfen, selbstverursachte Überschreitungen zu verhindern:
Unknowns-Buffer (10–20%) als eigene Zeile. Verstecke ihn nicht in den Features.
Später angeforderte Änderungen als separater Posten für neue Ideen nach Abnahme eines Features („auch Teams hinzufügen“, „Dashboard soll wie X aussehen“). Wenn du das nicht trennst, wirfst du der ursprünglichen Schätzung normale Änderungen vor.
Hier ein leichtes Template, das du kopieren kannst:
Feature: Password login
- Build: low 30 | typical 60 | high 120
- Test: low 15 | typical 30 | high 60
- Revise: low 10 | typical 20 | high 40
Subtotal (typical): 110
Buffer (15%): 17
Later changes (held): 50
Wiederhole das für jedes Feature (Auth, CRUD, eine Integration, ein UI-Refresh). Addiere die typischen Werte für deinen Plan und die hohen Werte als Worst-Case-Check.
Auth und CRUD wirken grundlegend, werden aber teuer, wenn der Scope unscharf ist. Behandle sie wie ein Menü: jede Option erhöht die Kosten.
Schreibe auf, wann Auth als erledigt gilt. Die größten Treiber sind die Anzahl der Login-Methoden und die Anzahl der Berechtigungspfade.
Sei konkret bei:
Wenn du nur „Auth hinzufügen“ sagst, bekommst du eine generische Lösung und zahlst später für Nachbesserungen. Die Form vorher zu entscheiden ist günstiger.
CRUD-Kosten hängen davon ab, wie viele Entities du hast und wie viel Verhalten jede benötigt. Ein praktisches Modell: jede Entität impliziert oft 3–6 Screens (Liste, Detail, Erstellen, Bearbeiten, manchmal Admin- oder Audit-Views), plus API-Arbeit und Validierung.
Wenn du CRUD scopst, nenne die Entities und füge Felder, Typen und Validierungsregeln (required, unique, Ranges) hinzu. Definiere dann das Listenverhalten: Filter, Sortierung, Pagination und Suche. „Suche“ kann eine einfache Contains-Filterung sein oder etwas deutlich Schwereres.
Entscheide auch, ob Admin-Screens sich von Nutzer-Screens unterscheiden. Separate Layouts, Extra-Felder und Bulk-Aktionen können die Arbeit verdoppeln.
Edge-Cases, die Kosten schnell erhöhen, sind Row-Level-Permissions, Audit-Logs, CSV-Import/Export, Soft-Delete und Genehmigungs-Workflows. All das ist machbar, aber das Budget bleibt vorhersehbar, wenn du explizit auswählst, was du willst, bevor du generierst.
Integrationen wirken teuer, weil sie Arbeit verbergen. Die Lösung ist, sie in kleine, testbare Brocken zu zerlegen statt „Verbinde mit X“. Das macht die Schätzung vorhersehbarer und ergibt klarere Prompts.
Ein solides Integrations-Scope umfasst in der Regel:
Schließe vor dem Prompt den Datenvertrag ab. Liste die Objekte und exakten Felder, die du brauchst. „Sync Customers“ ist vage. „Sync Customer{id, email, status} und Order{id, total, updated_at}“ verhindert, dass das Modell zusätzliche Tabellen, Screens und Endpoints erfindet.
Entscheide als Nächstes Richtung und Frequenz. Ein Einweg-Sync (nur Import) ist deutlich günstiger als ein Zwei-Wege-Sync, weil Zwei-Wege-Konfliktregeln und mehr Tests braucht. Falls Zwei-Wege nötig ist, wähle die Gewinnerregel vorab (Source of Truth, Last-Write-Wins oder manuelle Review).
Plane Fehlerfälle, als wären sie garantiert. Eine Log-Eintrag plus Alert und ein manueller „Re-Run Sync“-Button reicht oft aus. Minimal halten verhindert, dass du für ein vollwertiges Ops-System zahlst, das du nicht angefordert hast.
Füge abschließend einen Puffer für Drittanbieter-Zwicken und Tests hinzu. Selbst „einfache" APIs bringen Pagination, seltsame Enums, inkonsistente Docs und Rate Limits mit. 20–40% Extra für Integrationstests und Fixes sind realistisch.
UI-Arbeit ist eine Stelle, an der Budgets leise und stetig durchsickern. „Redesign“ kann Farbwechsel oder den kompletten Umbau des Flows bedeuten — benenne also, was sich ändert: Layout, Komponenten, Copy oder Nutzer-Schritte.
Trenne rein visuelle Änderungen von Änderungen, die Verhalten betreffen. Visuelle Anpassungen betreffen Styles, Abstände und Komponentenstruktur. Sobald du änderst, was ein Button macht, wie Validierung läuft oder wie Daten geladen werden, ist es Feature-Arbeit.
Vermeide „Redesign der ganzen App“. Liste die genauen Screens und Zustände. Wenn du die Seiten nicht auflisten kannst, lässt sich das nicht schätzen.
Halte den Scope kurz und konkret:
Diese Art Prompt hindert das Modell daran, Design im gesamten Codebase zu raten, was das Hin-und-Her antreibt.
UI-Änderungen brauchen meist mindestens zwei Checks: Desktop und Mobile. Füge einen schnellen Basis-Accessibility-Check hinzu (Kontrast, Fokuszustände, Tastaturnavigation), auch wenn du keinen vollständigen Audit machst.
Eine praktische Schätzformel ist:
(Anzahl Seiten) x (Änderungstiefe) x (Anzahl Pässe)
Beispiel: 3 Seiten x mittlere Tiefe (neues Layout + Komponenten-Anpassungen) x 2 Pässe (Build + Feinschliff) ist ein vorhersehbares Credits-Paket. Änderst du zusätzlich den Onboarding-Flow, behandle ihn als eigene Zeile.
Die günstigste Methode, Credits zu kontrollieren, ist vorher zu entscheiden, was du willst. Nacharbeit treibt die Kosten.
Beginne mit einem kurzen Absatz, der Nutzer und Ziel nennt. Zum Beispiel: „Eine Arzthelferin loggt sich ein, fügt Patienten hinzu, plant Termine und sieht die heutige Liste.“ Das setzt Grenzen und entmutigt das Modell, zusätzliche Rollen, Screens oder Workflows zu erfinden.
Beschreibe das Produkt dann als Screens und Aktionen, nicht als vage Module. Statt „Appointments-Modul“ schreibe „Kalender-Screen: erstellen, verschieben, stornieren, suchen.“ Das macht die Arbeit zählbar.
Füge nur die notwendigen Daten hinzu. Du brauchst nicht alle Felder jetzt, nur das, was das Feature real macht. Ein guter Prompt enthält meist:
Akzeptanz-Checks verhindern doppelte Zahlungen. Für jedes Feature schreibe 2–4 Checks wie „Nutzer kann Passwort per E-Mail zurücksetzen“ oder „Termin erstellen verhindert Doppelbuchung.“ Auf Plattformen wie Koder.ai passen diese Checks gut in den Planungsmodus vor der Codegenerierung.
Sei explizit bei Out-of-Scope: „kein Admin-Dashboard“, „keine Zahlungen“, „keine Mehrsprachigkeit“, „kein externes Kalender-Sync“. Das verhindert, dass vermeintliche „Nice-to-Have“-Arbeiten plötzlich auf deinem Budget landen.
Baue in kleinen Stücken und schätze nach jedem Stück neu. Ein einfacher Rhythmus: einen Screen oder Endpoint generieren, testen, Probleme beheben, dann weitermachen. Wenn ein Stück mehr kostet als erwartet, reduziere den Scope oder schneide beim nächsten Stück, bevor du weiter driftest.
Die meisten Kostenexplosionen entstehen, weil zu viel in einer Nachricht steckt. Behandle das Modell wie einen Teamkollegen: brief es in kleinen, klaren Schritten.
Beginne mit einem Plan, nicht mit Code. Bitte zuerst um einen kurzen Bauplan mit Annahmen und offenen Fragen, bestätige ihn, und fordere dann den ersten kleinen Implementierungsschritt an. Wenn du Planung, Bau, Tests, Copywriting und Styling in einem Prompt kombinierst, lädst du lange Outputs und mehr Fehler ein.
Halte Kontext eng. Füge nur die Screens, Komponenten oder API-Notizen bei, die für die Änderung relevant sind. Wenn du Koder.ai nutzt, wähle die spezifischen Dateien aus und nenne sie beim Namen. Extra-Dateien erhöhen Tokens und bringen Änderungen in nicht verwandte Bereiche.
Bitte um kleine Diffs. Ein Prompt sollte wenn möglich nur eine Sache ändern: einen Endpoint, ein Formular, einen Fehlerzustand oder einen Screen. Kleine Änderungen lassen sich leichter prüfen, und wenn etwas schiefgeht, zahlst du nicht für das Neugenerieren von Unrelated-Arbeit.
Einfaches Regelset:
Stoppe Loops früh. Wenn der zweite Versuch noch nicht passt, ändere die Eingabe, nicht nur die Formulierung. Ergänze das fehlende Detail, entferne widersprüchliche Anforderungen oder zeige das konkrete Fehlverhalten. Einfaches „Noch einmal versuchen“ kostet oft Tokens, bringt dich aber nicht weiter.
Beispiel: Du willst „Login + Forgot Password“ und ein schöneres Layout. Mach es in drei Prompts: (1) Flows und benötigte Screens skizzieren, (2) nur Auth-Flow implementieren, (3) UI-Abstände und Farben anpassen. Jeder Schritt bleibt prüfbar und günstig.
Die meisten Überschreitungen entstehen nicht durch große Features, sondern durch kleine Scope-Lücken, die sich in zusätzliche Prompt-Runden, mehr generierten Code und mehr Fixes vervielfachen.
Bauen bevor „Done“ vereinbart ist
Wenn du Code generierst ohne Akzeptanz-Checks, zahlst du für Umschreibungen. Schreibe zuerst 3–5 Checks: was ein Nutzer kann, welche Fehler angezeigt werden, welche Daten gespeichert werden müssen.
Vage Begriffe verwenden
„Modern“, „schön“ und „mach es besser“ laden viel Hin-und-Her ein. Ersetze sie durch Konkretes wie „Zweispaltiges Layout auf Desktop, einspaltig auf Mobile“ oder „Primary-Button-Farbe #1F6FEB."
Mehrere Features in einem Prompt packen
„Auth, Billing, Admin-Dashboard hinzufügen“ macht Änderungen schwer nachzuverfolgen und schätzt Nacharbeit schlecht. Mach ein Feature nach dem anderen und fordere eine kurze Zusammenfassung der berührten Dateien an.
Datenmodell spät ändern
Tabellen umbenennen, Beziehungen ändern oder IDs wechseln zwingt Anpassungen in UI, API und Migrations. Sperre Kern-Entities früh, auch wenn einige Felder als „Future“ markiert bleiben.
Tests bis zum Ende auslassen
Bugs führen zu Regenerate-Fix-Regenerate-Schleifen. Fordere für jedes Feature ein kleines Testset, nicht einen riesigen Testlauf am Ende.
Ein konkretes Beispiel: Du bittest Koder.ai, „mach das CRM besser“ und es ändert Layouts, benennt Felder um und passt Endpoints in einem Rutsch an. Danach bricht eine Integration, und du verbrennst Credits nur, um herauszufinden, was sich verschoben hat. Wenn du stattdessen sagst „Datenmodell unangetastet lassen, nur die Listen-UI updaten, API-Routen nicht anfassen, und diese 4 Checks bestehen“, begrenzt du Churn und hältst die Kosten stabil.
Behandle Budgetplanung wie das Planen eines kleinen Projekts, nicht wie einen magischen Prompt. Ein 2-minütiger Check fängt die meisten Overspend-Probleme.
Gehe diese Punkte durch und behebe jedes „Nein“, bevor du mehr Code generierst:
Wenn du Koder.ai nutzt, behandle jeden Chunk wie einen Snapshot-Punkt: generiere ein Stück, teste es, und fahre erst dann fort. Snapshots und Rollback sind besonders wertvoll vor riskanten Änderungen (Datenmodell-Edits, breite UI-Refactors oder Integrations-Neuschreibungen).
Ein einfaches Beispiel: Statt „Baue User-Management“ zu prompten, scopee auf „E-Mail-Login only, Passwort-Reset inklusive, kein Social Login, Admin kann Nutzer deaktivieren, Tests für Login und Reset.“ Klare Checks reduzieren Retries — und Retries sind der Ort, an dem Token- und Credit-Budgets verschwinden.
Hier ein kleines, realistisches Beispiel, das du übernehmen kannst. Die App ist ein internes Tool für ein Team: Login, zwei einfache Module und eine Integration.
Nimm an, ein "Build-Cycle" ist: kurzer Plan, Code generieren oder aktualisieren, kurzer Review und Fix. Deine Credits tracken hauptsächlich, wie viele Zyklen du fährst und wie groß jeder Zyklus ist.
Feature-Liste für das interne Tool:
| Feature | Was enthalten ist | Low | Typical | High |
|---|---|---|---|---|
| Login + Rollen | Sign-in, Sign-out, zwei Rollen (Admin, User), geschützte Seiten | 1 Cycle | 2 Cycles | 4 Cycles |
| CRUD Modul 1 | „Employees“ Liste, Erstellen/Bearbeiten, Basis-Validierung, Suche | 2 Cycles | 3 Cycles | 6 Cycles |
| CRUD Modul 2 | „Assets“ Liste, Erstellen/Bearbeiten, Zuweisen an Mitarbeiter, Audit-Felder | 2 Cycles | 4 Cycles | 7 Cycles |
| Eine Integration | Sende ein Event an einen externen Service, wenn ein Asset zugewiesen wird | 1 Cycle | 2 Cycles | 5 Cycles |
Eine Prompt-Sequenz, die Checkpoints eng hält:
Kosten steigen, wenn Entscheidungen nachträglich geändert werden. Häufige Auslöser sind Rollenänderungen (neue Rollen oder Permission-Pfade), späte Felder (vor allem solche, die mehrere Module und die Integration tangieren), Integrationsfehler (Auth-Fehler, Payload-Mismatch) und UI-Redesign nachdem Formulare bestehen.
Nächste Schritte: Plane Feature für Feature, baue in Zyklen und prüfe Credits nach jedem Zyklus. Nutze Snapshots vor riskanten Änderungen, damit du schnell zurückrollen kannst und im typischen Bereich bleibst.
Budgetiere immer eine Spanne, weil du für Versuche zahlst, nicht für einen festen Feature-Preis. Kosten steigen durch:
Eine „kleine“ UI-Änderung kann teuer werden, wenn sie Logik, Daten oder Flows verändert.
Tokens sind Textstücke, die das Modell liest/schreibt (dein Prompt, seine Antwort und jeder Chatverlauf, den es erneut lesen muss).
Credits sind die Abrechnungseinheit deiner Plattform (decken oft Modellnutzung plus Plattformaufwand wie Agentenläufe oder Dateibearbeitungen).
Build-Schritte sind sinnvolle Projektänderungen (Tabelle hinzufügen, Screen anbinden, Endpoint erstellen). Ein Feature besteht meist aus vielen Schritten, und jeder Schritt kann mehrere Modellaufrufe auslösen.
Schätze in Features, die Nutzer beim Namen nennen würden ("Passwort-Login", "Mitarbeiterliste", "Asset zuweisen") statt in „Screens“ oder „Nachrichten“. Pro Feature budgetiere drei Teile:
Gib für jeden Teil Low/Typical/High-Werte und addiere sie dann.
Füge zwei klare Zeilen hinzu:
Wenn du „spätere Änderungen“ trennst, kannst du normales Scope-Wachstum nicht dem ursprünglichen Estimate anlasten.
Schreibe auf, was „fertig“ für Auth bedeutet. Die größten Kostentreiber sind:
Standardisiere auf eine Methode (E-Mail/Passwort) und 1–2 Rollen für planbare Kosten.
CRUD-Kosten entstehen aus Verhalten, nicht nur Tabellen. Für jede Entität definiere:
CSV-Import/Export, Audit-Logs, Genehmigungsworkflows oder Zeilenberechtigungen budgetierst du als eigene Feature-Zeilen.
Teile „connect to X“ in kleine, testbare Schritte:
Fixiere außerdem den Datenvertrag (exakte Felder) bevor du Code erzeugst, damit das Modell nicht zusätzliche Tabellen, Screens oder Endpoints erfindet.
Scope UI-Arbeit wie eine Seitenliste mit Zuständen:
Ändert ein Redesign Validierung, Datenladen oder Nutzer-Schritte, behandel es als Feature-Arbeit, nicht als „nur UI“.
Nutze eine präzise Prompt-Struktur:
Baue in kleinen Stücken (ein Endpoint oder ein Screen pro Schritt) und re-schätze nach jedem Stück.
Beende die Schleife nach zwei fehlgeschlagenen Versuchen und ändere die Eingabe, nicht nur die Formulierung. Typische Lösungen:
Fordere am Ende jeder Runde eine kurze Zusammenfassung der geänderten Dateien an, damit unerwünschte Änderungen früh auffallen.