Festpreis vs. Stundenabrechnung bei Fehlerbehebung: Das sicherere Modell wählen

Warum die Preisgestaltung schwierig wird, wenn der Code unordentlich ist

Fehlerbehebung ist eine einfache Idee: Software, die irgendwie funktioniert, zuverlässig machen. Das bedeutet, die sichtbaren Bugs zu beheben und außerdem die Probleme, die erst mit echten Nutzern, echten Daten und echten Sicherheitsanforderungen auftreten.

Die Preisgestaltung wird kompliziert, weil unordentlicher Code Arbeit verbirgt. Du siehst vielleicht ein offensichtliches Problem, zum Beispiel dass das Login fehlschlägt. Oft steckt der Zeitfresser aber in der Kettenreaktion dahinter: kaputtes Session-Handling, fehlende Datenbank-Constraints, unsichere Abkürzungen oder ein Deployment-Setup, das nie fertiggestellt wurde.

KI-generierte Prototypen sehen besonders oft komplett aus, sind aber fragil. Sie fügen Bibliotheken schnell zusammen, wiederholen Muster in mehreren Dateien und hinterlassen Platzhalter, die harmlos wirken, bis die Anwendung live geht. Ein Prototyp kann eine Demo bestehen und trotzdem mit exponierten Secrets, inkonsistenter Validierung oder Logik geliefert werden, die versagt, sobald zwei Personen die App gleichzeitig nutzen.

Für einen nicht-technischen Eigentümer fühlt sich „unordentlich“ meist so an: Ein Bug zu beheben schafft zwei neue, Funktionen verhalten sich je nach Seite oder Gerät unterschiedlich, und kleine Änderungen dauern ewig, weil niemand sicher weiß, was kaputtgeht. Die App läuft lokal, aber nicht in Produktion, und Begriffe wie „Spaghetti“, „hard-coded“ oder „keine Tests“ fallen immer wieder.

Deshalb ist die Entscheidung zwischen Festpreis und Stundenabrechnung zu Beginn oft schwierig. Beide Modelle versuchen dieselbe Frage zu beantworten: Wie zahlt man fair, wenn die vollständige Liste der Probleme noch nicht sichtbar ist?

Unbekanntes ist normal. Es bedeutet nicht, dass dein Projekt zum Scheitern verurteilt ist. Du kannst damit umgehen, wenn du Discovery als Teil der Arbeit behandelst. Ein „einfacher“ Checkout-Bug kann sich als Datenbankschema-Problem plus fehlende serverseitige Validierung entpuppen. Solange niemand den Code liest und reale Nutzerflüsse nachverfolgt, kann niemand verantwortungsvoll den genauen Aufwand versprechen.

Praktisch ist es oft sinnvoll, mit einer kurzen Code-Diagnose zu beginnen und dann die Preisgestaltung für die Reparaturarbeit basierend auf den Erkenntnissen zu entscheiden.

Festpreis vs. Stundenabrechnung: die einfache Definition

Mit „Festpreis“ (oder Festpreisangebot für Softwarereparatur) meint man, dass man drei Dinge im Voraus vereinbart: was repariert wird, wie „fertig“ aussieht und was es kostet. Die Arbeit wird als Paket mit klaren Liefergegenständen behandelt.

Stundenbasierte Fehlerbehebung ist in einer anderen Hinsicht einfacher: Du zahlst für die aufgewendete Zeit. Der Umfang kann sich ändern, während das Team mehr über den Code lernt. Wenn ein neues Problem auftaucht, verhandelst du nicht jedes Mal das ganze Projekt neu. Du entscheidest, ob ihr basierend auf Fortschritt und Budget weitermacht.

Der eigentliche Kompromiss ist vorhersehbare Kosten versus Flexibilität.

Festpreis funktioniert tendenziell am besten, wenn du Kostensicherheit und eine klare Ziellinie willst. Stundenabrechnung ist besser, wenn du Überraschungen erwartest und Spielraum zum Umschwenken brauchst.

Ein kurzes Beispiel: Stell dir einen KI-erstellten Prototyp vor, bei dem das Login in einer Demo funktioniert, in Produktion aber scheitert, weil Secrets exponiert sind und der Auth-Flow inkonsistent ist. Wenn du die genauen notwendigen Änderungen kennst, kann Festpreis gut funktionieren. Wenn du vermutest, dass hinter dem ersten Fehler mehr Probleme stecken, reduziert Stundenabrechnung Konflikte, weil Discovery Teil des Plans ist.

Was die Unbekannten meist sind (und warum sie spät auftauchen)

Unordentlicher Code verbirgt Probleme wie ein Haus versteckte Wasserschäden. Alles sieht gut aus, bis du eine Wand öffnest, die Dusche einschaltest und feststellst, dass der Leckageort hinter den Fliesen liegt. Software-Behebung ist ähnlich: Die größten Risiken sitzen oft hinter der ersten Funktion, die in einer realen Umgebung fehlschlägt.

Die Unbekannten, die am häufigsten auftreten, sind vorhersehbar, auch wenn die genauen Details es nicht sind:

• Authentifizierung, die lokal funktioniert, aber mit echten Sessions, Cookies oder Redirects versagt
• Exponierte Secrets (API-Keys, Datenbankpasswörter), die im Code oder Logs eingebacken sind
• Unklarer Datenfluss (niemand weiß, woher ein Wert kommt oder warum er sich ändert)
• Versteckte Abhängigkeiten, wie ein Drittanbieterdienst, eine fehlende Migration oder eine angenommene Umgebungsvariable
• Sicherheitslücken, die in Happy-Path-Tests nicht auftauchen (unsichere Queries, schwache Zugriffsprüfungen)

Diese Probleme tauchen spät auf, weil frühe Tests oft oberflächlich sind. Ein schnelles Durchklicken übersieht die Teile, die nur unter Last, mit echten Nutzern oder echten Daten erscheinen. Wenn die App schnell von einem KI-Tool generiert oder von mehreren Personen gepatcht wurde, sieht der Code lesbar aus und ist trotzdem logisch fehlerhaft.

Discovery-Arbeit ändert Schätzungen, weil sie Vermutungen in Fakten verwandelt. Solange niemand Schlüssel-Flows Ende-zu-Ende nachverfolgt (Login, Zahlungen, Admin-Aktionen, Daten-Schreibvorgänge), weißt du nicht, ob du an einem kleinen Bug arbeitest oder an einem Faden ziehst, der den ganzen Pullover auflöst.

Unklare Anforderungen verschlimmern das. Wenn niemand sagen kann, was „korrekt“ ist, jagen Ingenieure Symptomen hinterher. In der Praxis ist die größte Unbekannte oft nicht der Code, sondern die Definition von „fertig“, besonders bei Edge-Cases.

Wie Festpreis mit Unbekannten umgeht

Ein Festpreis fühlt sich sicherer an, weil du die Zahl im Voraus kennst. Er funktioniert aber nur, wenn „fertig“ klar ist. Die eigentliche Frage ist nicht der Stundensatz, sondern wie der Plan mit Überraschungen im unordentlichen Code umgeht.

Beim Festpreis wird Unsicherheit meist durch eine engere Abgrenzung des Umfangs gehandhabt. Das bedeutet normalerweise, genau aufzuschreiben, was repariert wird, welche Umgebungen eingeschlossen sind und was als Erfolg zählt. Wenn die App „irgendwie funktioniert“, sind vage Ziele wie „stabil machen“ der Punkt, an dem Festpreis-Angebote schiefgehen.

Ein gesundes Festpreis-Abkommen schützt beide Seiten durch einige Sicherungen:

• Schriftliche Akzeptanzkriterien (was getestet wird und was bestehen muss)
• Annahmen (z. B.: Zugang zum Hosting ist möglich, wichtige APIs existieren noch)
• Klare Ausschlüsse (was nicht enthalten ist, z. B. UI-Redesign oder neue Features)
• Ein Änderungsantragsweg (wie Überraschungen in neue Arbeit überführt werden, mit Preis und Zeitplan)
• Eine Phasenoption (zuerst diagnostizieren, dann reparieren)

Wenn Überraschungen auftreten, „frisst“ ein gutes Festpreis-Team nicht unbegrenzte Arbeit und schneidet auch nicht heimlich Ecken ab. Es pausiert und macht das Problem sichtbar. Dann entscheidest du: neu verhandeln oder eine getrennte Phase hinzufügen.

Um einen schlechten Festpreis zu vermeiden, bestehe auf einer Diagnose, bevor du dich für die komplette Reparatur verpflichtest. Ein kurzer Audit kann versteckte Abhängigkeiten, gebrochene Migrationen, fehlende Env-Variablen und Spaghetti-Architektur aufdecken.

Festpreis eignet sich am besten, wenn Ergebnisse konkret sind: Du kannst die wichtigsten Fehler aufzählen, du hast Zugang zu Logs und Drittanbieter-Konten und du kannst dich auf eine einfache Test-Checkliste einigen, die beweist, dass die App funktioniert.

Wenn ein Anbieter nicht beschreiben kann, wie er mit Change Requests umgeht, ist der „Festpreis“ nicht wirklich sicher — er verbirgt nur das Risiko bis später.

Wie Stundenabrechnung mit Unbekannten umgeht

Stundenarbeit ist oft die ehrlichste Lösung, wenn der Code unordentlich ist und niemand das volle Ausmaß sehen kann. Du zahlst für Untersuchung und Fixes, während sie passieren, statt so zu tun, als wäre der Umfang am ersten Tag bekannt.

Der Vorteil ist Flexibilität. Erkennt das Team, dass das eigentliche Problem nicht der Login-Button, sondern ein schlechtes Datenbankschema ist, kann es ohne ständige Neuverhandlungen umschwenken.

Der Nachteil ist Kostenentwicklung. Stundenarbeit kann in offene Debugging-Sessions ausarten, und „schnelle Fixes“ können später Nacharbeit erzeugen. Budgets wachsen, wenn Teams Symptomen statt Ursachen nachjagen, partielle Rewrites anfangen zu expandieren oder feststellen, dass mehrere Bereiche denselben defekten Mustern folgen.

Damit Stundenarbeit sicher ist, brauchst du Leitplanken und regelmäßige Stopppunkte:

• Discovery zeitlich begrenzen (z. B. 4–8 Stunden) und schriftliche Ergebnisse verlangen
• Eine wöchentliche Obergrenze setzen und Genehmigung verlangen, bevor sie überschritten wird
• „Fertig“ durch sichtbare Meilensteine definieren (z. B. Auth funktioniert Ende-zu-Ende, Deploy besteht)
• Stopp-Regeln hinzufügen (pausieren bei nötigem Rebuild oder wenn versteckte Abhängigkeiten auftauchen)
• Fortschritte in einfacher Sprache dokumentieren lassen, nicht nur Stundenzettel

Stundenarbeit ist am sichersten, wenn sie als kontrollierte Untersuchung plus Reparaturphasen behandelt wird, nicht als endlose Messung.

Eine Schritt-für-Schritt-Methode zur Modellauswahl

Die Wahl zwischen Festpreis und Stundenabrechnung fällt leichter, wenn du sie als zweiphasige Entscheidung behandelst: Zuerst herausfinden, womit du es zu tun hast, dann den Vertrag wählen, der zum Risiko passt.

1. Definiere das Ergebnis in Nutzersprache. Schreibe, was „funktionierend“ bedeutet als reale Aktionen, nicht als technische Aufgaben. Beispiel: „Ein neuer Nutzer kann sich registrieren, E-Mail bestätigen, einloggen und Passwort zurücksetzen, ohne hängen zu bleiben."
2. Bitte um eine kurze Diagnosephase. Bevor jemand ein großes Reparaturangebot macht, fordere einen zeitlich begrenzten Audit, der Probleme und wahrscheinliche Ursachen kartiert.
3. Vereinbare Akzeptanzprüfungen. Lege fest, welche Beweise du als Nachweis für die Fehlerbehebung akzeptierst. Halte sie beobachtbar und wiederholbar.
4. Wähle Modell für Phase 2 basierend auf der Diagnose. Ist die Arbeit klar definiert und testbar, kann Festpreis sicher sein. Zeigt die Diagnose große Unbekannte (verknotete Architektur, unklarer Datenfluss, viele Edge-Cases), ist Stundenarbeit oft sicherer.
5. Plane Härtung und Deployment-Vorbereitung ein. Viele Apps „funktionieren“, bis sie in Produktion gehen. Reserviere Zeit für Sicherheitschecks, Umgebungs-Setup und einen sauberen Deploy-Plan.

Du brauchst kein langes Akzeptanzdokument. Eine Handvoll klarer Punkte reicht meist:

• Login, Logout und Passwort-Zurücksetzen funktionieren in Chrome und Safari.
• Zahlungen gehen durch, und fehlgeschlagene Zahlungen zeigen eine hilfreiche Nachricht.
• Keine Secrets sind in App oder Logs exponiert.
• Ein grundlegender Security-Scan findet keine SQL-Injection-Pfade.

Wenn du mit KI-generierten Prototypen arbeitest (Tools wie Bolt, v0, Cursor, Replit oder Lovable), macht ein kurzer Audit oft den Unterschied zwischen einem selbstbewussten Festpreis-Angebot und einer „Überall Unbekannte“-Stundenlage.

Häufige Fehler, die beide Modelle riskant machen

Die meisten Preisstreitigkeiten drehen sich nicht wirklich um den Preis. Sie entstehen, wenn niemand zustimmt, was „fertig“ bedeutet, und die unordentlichen Teile des Codes erst nach Arbeitsbeginn sichtbar werden.

Eine Falle bei Festpreis ist, einen Umfang zu genehmigen, der mehr Stimmung als Plan ist. Ist der Umfang vage, basiert das Angebot auf Annahmen, die du nie freigegeben hast. Später wird jede Überraschung ein Change Request, und du zahlst extra oder akzeptierst eine Teilreparatur, die nicht hält.

Stundenarbeit hat das Gegenrisiko: Sie wirkt anfangs sicher und wächst dann unbemerkt. Ohne Budget-Deckel, klare Stop-Regel oder regelmäßige Check-ins verwandeln sich kleine Untersuchungen in offene Zeit.

Sicherheit ist ein weiterer Bereich, in dem beide Modelle scheitern. Leute konzentrieren sich auf den sichtbaren Bug und überspringen Basics wie geleakte API-Keys, unsichere DB-Queries oder falsche Zugriffsprüfungen. So wird eine „funktionierende“ App später zum Vorfall.

Ein dritter Fehler ist, Symptome statt Struktur zu behandeln. Ist die App Spaghetti, kann das Patchen einer fehlerhaften Stelle zwei neue Fehler erzeugen. Eine gute Reparatur beinhaltet meist etwas Refactoring und klarere Grenzen.

Warnzeichen, die Probleme voraussagen:

• Der Umfang ist nicht in einfacher Sprache verfasst, die du prüfen kannst.
• Es gibt keine testbare Definition von „fertig“.
• Niemand erwähnt Sicherheit oder Datenhandhabung.
• Updates sind vage („wir machen Fortschritt“) statt abgeschlossene Ergebnisse zu zeigen.
• Der Plan baut auf „wir klären das später“ für Kernfunktionen.

Schnelle Checkliste, bevor du etwas unterschreibst

Unordentlicher Code ist voller Überraschungen. Das Ziel vor Beginn ist nicht, alles vorherzusehen. Es ist, sich zu einigen, was „fertig“ bedeutet, wer welchen Zugriff hat und was passiert, wenn versteckte Probleme auftauchen.

Die fünf Dinge, die du bestätigen solltest

Bevor du ein Angebot genehmigst oder mit Stundenarbeit beginnst, kläre diese Punkte:

• Definiere Erfolg in klaren, testbaren Punkten. Ziel: 3–5 Aussagen wie „Nutzer können sich registrieren und einloggen“, „Passwort-Zurücksetzen-Mail funktioniert“, „Checkout läuft ohne Fehler“ oder „Keine Secrets im Repo sichtbar".
• Bestätige Zugang, nicht nur Berechtigung. Sorge dafür, dass jemand wirklich das Repo öffnen, Logs einsehen und deployen kann. Fehlender Hosting-Zugang oder fehlende Env-Variablen können den Fortschritt am ersten Tag stoppen.
• Benenne die „Muss-behoben“-Risiken vorher. Authentifizierungsfehler, Datenverlust und Sicherheitslücken sollten Priorität haben.
• Setze eine Budgetobergrenze und eine Entscheidungsfrist. Selbst bei Stundenarbeit kannst du Ausgaben begrenzen und einen Stoppzeitpunkt festlegen.
• Prüfe, ob du mehr als Bugfixes brauchst. Wenn das echte Problem verknotete Struktur, unsichere Muster oder wackelige Deployments ist, plane Refactoring und Deployment-Vorbereitung ein.

Folgefrage: Wie werden Change Requests gehandhabt? Wenn neue Probleme auftauchen (und das werden sie), willst du eine einfache Regel, ob sie eingeschlossen sind, separat geschätzt werden oder in eine zweite Phase verschoben werden.

Was du schriftlich verlangen solltest

Du brauchst keinen langen Vertrag, aber eine klare Dokumentation:

• Eine kurze Umfangszusammenfassung plus explizite Ausschlüsse
• Die Akzeptanzmethode (Tests, Staging-Demo oder eine Checklisten-Abnahme)
• Einen Risikoplan (was passiert, wenn eine kritische Abhängigkeit oder ein verstecktes Modul bricht)

Beispiel: Ein Prototyp, der in Produktion zerbricht

Ein Gründer hat eine KI-erstellte App, die in der Demo großartig aussieht. Du kannst klicken, Items hinzufügen und ein Dashboard sehen. Dann versuchen echte Nutzer, sich anzumelden, und alles bricht zusammen: Einige bekommen nie die Bestätigungs-Mail, andere sind als falscher Nutzer eingeloggt und einige Registrierungen lassen die App abstürzen.

Bei genauerem Hinsehen tauchen die Unbekannten schnell auf:

• Der Authentifizierungsfluss ist aus mehreren Bibliotheken zusammengesetzt, sodass Sessions zufällig auslaufen.
• Secrets (API-Keys und Tokens) wurden ins Repo committet, sodass die App einen Leak davon entfernt ist, ein teurer Vorfall zu werden.
• Datenbank-Queries funktionieren mit kleinen Demo-Daten, werden aber bei echten Registrierungen langsam und inkonsistent.

Nun musst du Festpreis vs. Stundenabrechnung wählen, und die sicherste Option hängt davon ab, wie viel Unsicherheit noch besteht.

Option A: Festpreis nach kurzem Audit

Festpreis kann gut funktionieren, wenn du zuerst ein kurzes Audit machst und Entdeckungen in eine definierte Reparaturliste übersetzt. Für diesen Prototyp könnte das heißen: Login- und Session-Flow Ende-zu-Ende reparieren, exponierte Secrets rotieren und entfernen sowie die schlimmsten Queries stabilisieren.

Du zahlst für einen klar formulierten Umfang und eine eindeutige „Fertig“-Definition. Wenn neue Probleme außerhalb des Umfangs auftauchen (z. B. ein tiefer Framework-Mismatch), werden sie ein separater Change Request statt stillschweigend den Umfang zu erweitern.

Option B: Stundenarbeit mit Timebox und Obergrenze

Stundenarbeit kann sicherer sein, wenn du versteckte Probleme erwartest und Flexibilität brauchst. Wichtig ist, die Arbeit nicht offen laufen zu lassen. Ein praktisches Vorgehen ist eine zeitlich begrenzte Untersuchung (z. B. 6–10 Stunden), gefolgt von wöchentlichen Obergrenzen und einem kurzen Wochenplan.

Fordere eine wöchentliche Stundenobergrenze, einen schriftlichen „nächsten 3 Aufgaben“-Plan vor Arbeitsbeginn und eine Stopp-Regel, wenn ein Fix zum Rebuild wird.

Was sich ändert, wenn ein partieller Rebuild nötig ist

Zeigt das Audit, dass die Auth-Schicht grundsätzlich falsch ist (kein verlässliches Nutzermodell, widersprüchliche Middleware oder ein Schema, das keine echten Accounts unterstützt), kann ein partieller Rebuild günstiger und sicherer sein als Patching. In diesem Fall wird Festpreis wieder attraktiv, weil der Rebuild-Umfang um eine saubere, testbare Teilmenge (Auth + Kern-Datenfluss) definiert werden kann, statt endlosen Edge-Cases hinterherzulaufen.

Nächste Schritte: Risiko reduzieren und vorankommen

Wenn du weniger Überraschungen willst, fang nicht mit Streit um den Preis an. Fang damit an, die Arbeit kleiner und klarer zu machen. Unordentlicher Code verbirgt Probleme, also ist der sicherste Schritt, Unbekanntes in eine kurze Liste bekannter Probleme zu verwandeln, bevor sich jemand zu einer großen Reparatur verpflichtet.

Wenn du Kostensicherheit brauchst, beginne mit einer Diagnosephase und fordere eine schriftliche Liste dessen, was kaputt ist, was riskant ist und was warten kann. Sobald das klar ist, kannst du zu einer Festpreis-Phase wechseln, die einen definierten Ausschnitt der Arbeit abdeckt (nicht „alles reparieren").

Wenn du Flexibilität brauchst, kann Stundenabrechnung mit Leitplanken sicher sein: eine wöchentliche Obergrenze, klare Meilensteine und vereinbarte Stopp-Punkte, an denen du entscheidest, ob weitergemacht, die Richtung geändert oder pausiert wird.

Manchmal ist die sicherste „Reparatur“ ein Rebuild. Ist die Architektur verknotet, sind Sicherheitsprobleme überall oder brechen grundlegende Features ständig gegenseitig, kann Patchen teurer sein als Ersetzen.

Wenn du einen KI-erstellten Prototypen von Tools wie Lovable, Bolt, v0, Cursor oder Replit geerbt hast, bietet FixMyMess (fixmymess.ai) eine kostenlose Code-Prüfung an, um zuerst die wirkliche Fehlerliste aufzudecken. Danach fällt die Wahl des passenden Preismodells leichter, und viele Behebungsprojekte lassen sich innerhalb von 48–72 Stunden abschließen, sobald der Umfang klar ist.