Kosten der SaaS-Sanierung für eine kleine KI-App

Ein Festpreis für die Reparatur eines kleinen, mit KI erstellten SaaS sollte auf eine bezahlte oder klar begrenzte Diagnose folgen, nicht auf einen flüchtigen Blick ins Repository und eine Vermutung. Bei den meisten kleinen Produkten bilde ich das Angebot aus sechs Arbeitspaketen: Diagnose, Sicherheitsreparatur, Logikreparatur, gezieltes Refactoring, Tests und Vorbereitung der Bereitstellung. Der Preis ist nur glaubwürdig, wenn jedes Paket seine Nachweise, Annahmen und Abnahmekriterien nennt.

Das Unangenehme daran ist, dass sich unter einem ordentlichen Prototyp teure Fehler verbergen können. Ein funktionierender Anmeldebildschirm sagt nichts über die Trennung verschiedener Mandanten aus. Eine erfolgreiche Testzahlung sagt wenig über wiederholte Webhooks, Änderungen der Berechtigungen oder Erstattungen. Die nützliche Frage lautet nicht, wie viele Bildschirme die App hat. Entscheidend ist, wie viele geschäftliche Versprechen Vertrauensgrenzen überschreiten, Daten schreiben, kostenpflichtige Dienste aufrufen oder von der Produktionskonfiguration abhängen.

Die folgenden Dollarspannen sind Planungswerte in USD für die Eingrenzung einer kleinen App, keine veröffentlichten Marktdurchschnitte. Sie setzen eine Webanwendung, eine zentrale Datenbank, ein übliches verwaltetes Bereitstellungsziel und eine lokal ausführbare Codebasis voraus. Nutzen Sie die Methode, um ein Angebot aus Nachweisen zu entwickeln. Übertragen Sie die Summen nicht auf ein Projekt mit anderen Tatsachen.

Ein Festpreis beginnt nach einer begrenzten Diagnose

Ein Dienstleister kann den Preis erst verantwortungsvoll festlegen, nachdem er die App reproduziert, ihre wichtigsten Abläufe verfolgt und die verbleibenden Unbekannten festgehalten hat. Vor diesem Punkt ist ein fester Betrag entweder aus Angst aufgebläht oder zu niedrig, sobald er auf den Code trifft.

Bei einem kleinen SaaS bedeutet Diagnose gewöhnlich 8 bis 20 Stunden konzentrierte Entwicklungsarbeit. Eine praktische Planungsspanne liegt bei 1.000 bis 3.000 Dollar, wenn sich das Repository mit einer üblichen Einrichtung starten lässt und der Eigentümer das erwartete Verhalten erklären kann. Die Spanne steigt, wenn niemand das Bereitstellungskonto kontrolliert, Migrationen keine verlässliche Reihenfolge haben, das Datenbankschema vom Repository abweicht oder wesentliche Funktionen in einem visuellen Baukasten außerhalb der Versionsverwaltung liegen.

Das Ergebnis sollte mehr als eine Liste von Lint-Fehlern sein. Ich erwarte eine Karte der Routen und Abläufe, ein Inventar der Datenspeicher und externen Dienste, eine Prüfung der Geheimnisse, Abhängigkeiten und des Builds, bereinigte Beispiele aus Produktionsprotokollen und ein priorisiertes Befundregister. Jeder Befund braucht vier Felder: beobachtbarer Fehler, wahrscheinliche Ursache, betroffener Ablauf und vorgeschlagener Nachweis der Reparatur. Aus diesem Register entsteht die Schätzung.

Auch die Diagnose braucht eine Abbruchregel. Der Prüfer sollte jeden kritischen Ablauf untersuchen, muss aber nicht jede generierte Komponente erklären, bevor er eine begrenzte Reparatur bepreist. Halten Sie fest, welche Routen ausgeführt, welche Rollen verwendet, wie viele Produktionsnachweise verfügbar und welche Bereiche stichprobenartig geprüft wurden. Wenn die App ein ungenutztes Berichtsmodul oder einen unfertigen Verwaltungsbildschirm enthält, nehmen Sie ihn in den Umfang auf oder kennzeichnen ihn als außerhalb der geprüften Grenze. Schweigen ist keine Annahme.

Ein Entwickler kann ein erstes Nachweispaket mit gewöhnlichen Repository-Befehlen zusammenstellen:

$ git status -s
 M src/auth/session.ts
?? notes/production-errors.txt

$ git ls-files | sed -n '1,12p'
.env.example
package.json
src/auth/session.ts
src/billing/webhook.ts
...

$ git log -1
commit a1b2c3d
Author: Example Developer
Date: Mon Jul 20 10:14:00 2026 +0000
    fix checkout callback

Die genauen Dateinamen sind nicht wichtig. Die Ausgabe zeigt, welcher Commit geprüft wurde, ob unbestätigte Änderungen vorliegen und wo sich wahrscheinlich sicherheitsrelevanter Code befindet. Ergänzen Sie bereinigte Produktionsfehler, Bereitstellungseinstellungen, den Stand der Datenbankmigrationen und Testbefehle. Kopieren Sie niemals aktive Geheimnisse in das Paket.

Ich lehne das beliebte Angebot ab, kostenlos zu diagnostizieren und gleichzeitig einen verbindlichen Gesamtpreis für die Reparatur zu versprechen. Eine kurze kostenlose Vorprüfung kann klären, ob das Projekt grundsätzlich passt. Ein verbindliches Angebot verlangt jedoch eine echte Untersuchung. Wenn ein Anbieter diese Arbeit übernimmt, verschwindet der Aufwand nicht. Er kehrt als aufgeblähte Schätzung, oberflächliche Prüfung oder vorhersehbarer Nachtrag zurück.

Arbeit wird nach Risiko statt Dateizahl bepreist

Die Schätzung sollte beobachtbare Verantwortlichkeiten und Risiken bewerten, weil die Zahl der Codezeilen kaum verlässlich mit dem Reparaturaufwand zusammenhängt. Generierte Projekte enthalten oft Tausende wiederholte Zeilen um eine einzige falsche Annahme zur Autorisierung. Die gefährliche Änderung kann sechs Zeilen umfassen, während ihr Sicherheitsnachweis zwei Tage dauert.

Ich teile Befunde in Defekte, Entwurfslücken und Betriebslücken. Ein Defekt verletzt ein bereits beabsichtigtes Verhalten, etwa wenn ein Checkout-Handler den falschen Tarif speichert. Bei einer Entwurfslücke fehlt das gewünschte Verhalten oder widerspricht sich, etwa wenn keine Regel für ein abgelaufenes Abonnement existiert. Eine Betriebslücke erscheint erst außerhalb des Entwicklerrechners, zum Beispiel fehlende Umgebungsvariablen, kein Migrationsbefehl oder ein Host, der lange Aufgaben beendet. Diese Kategorien verlangen verschiedene Preise. Defekte lassen sich häufig aus dem Code eingrenzen. Entwurfslücken brauchen Produktentscheidungen. Betriebslücken hängen von Zugängen und Zielumgebung ab.

Ein brauchbares Schätzblatt hat eine Zeile pro Arbeitspaket. Die Diagnose für 1.000 bis 3.000 Dollar endet mit Reproduktionsnotizen und einem priorisierten Befundregister. Die Sicherheitsreparatur für 1.500 bis 6.000 Dollar endet mit Missbrauchstests und einer Prüfung der jeweiligen Kontrollen. Die Logikreparatur für 1.500 bis 5.000 Dollar endet mit bestandenen Abnahmefällen für die Abläufe.

Gezieltes Refactoring für 1.000 bis 4.000 Dollar muss eine benannte Änderungsfläche verkleinern, ohne das Verhalten zu verändern. Tests für 1.500 bis 4.000 Dollar liefern eine automatisierte Suite für kritische Pfade und einen Bericht. Die Vorbereitung der Bereitstellung für 750 bis 2.500 Dollar liefert eine wiederholbare Test- oder Produktionsfreigabe samt Hinweisen zur Rücknahme. Bis die Diagnose die Werte mit Befunden verbindet, bleiben es Planungsspannen.

Die Addition aller Höchstwerte ergibt eine beängstigende Zahl, doch so sollte das Blatt nicht verwendet werden. Einige Pakete überschneiden sich. Eine Sicherheitsreparatur kann die Tests enthalten, die die Autorisierung nachweisen. Eine Logikreparatur kann Duplikate beseitigen, die sonst ein Refactoring erfordern würden. Das Angebot sollte Überschneidungen nennen, damit der Käufer nicht doppelt zahlt.

Der Anbieter wird den Arbeitsaufwand intern trotzdem schätzen. Ein sinnvoller Festbetrag kombiniert gewöhnlich die erwartete Entwicklungszeit, Prüfung, Abstimmung und eine Reserve für normale Abweichungen innerhalb des bekannten Umfangs. Diese Reserve ist keine Erlaubnis, die Berechnung zu verbergen. Fragen Sie nach Arbeitspaketen und Abnahmenachweisen, nicht nach Stundenzetteln einzelner Beschäftigter. Der Anbieter trägt das Risiko, dass eine benannte Reparatur etwas länger dauert. Der Käufer trägt Änderungen an Tatsachen und Entscheidungen, die er für die Schätzung geliefert hat.

Auch die Reihenfolge beeinflusst die Gesamtsumme. Sicherheits- und Logikreparaturen sollten einer breiten Testautomatisierung vorausgehen, weil Tests um falsches Verhalten sonst erneut geschrieben werden müssen. Die Bereitstellungsumgebung muss früh genug untersucht werden, um Plattformgrenzen zu erkennen, auch wenn die Freigabe zuletzt erfolgt. Ein Angebot mit sechs unabhängigen Phasen kann dieselbe Einrichtung und Codelektüre sechsmal zählen. Eine einzige ungeteilte Aufgabe kann dagegen verbergen, wohin das Geld fließt.

Bei einer wirklich kleinen App mit begrenzten Befunden liegt der kombinierte Festpreis unter diesen Annahmen häufig bei etwa 7.000 bis 18.000 Dollar. Behandeln Sie das als berechneten Planungsrahmen, nicht als Versprechen oder Marktvergleich. Eine Reparatur für 3.000 Dollar kann sinnvoll sein, wenn der Fehler isoliert ist und die Bereitstellung schon funktioniert. Auch ein Angebot über 30.000 Dollar kann sinnvoll sein, wenn das Wort «klein» nur die Oberfläche beschreibt, nicht aber Berechtigungen, Abrechnungszustände, Datenbereinigung oder Freigaberisiko.

Der Sicherheitsumfang folgt den Vertrauensgrenzen

Sicherheitsarbeit sollte anhand der Vertrauensgrenzen und Datenaktionen der App geschätzt werden, nicht anhand eines allgemeinen Versprechens, den Code zu «härten». Dieses Wort verdeckt den Umfang. Das Angebot sollte die Kontrollen und ihre Prüfverfahren benennen.

Beginnen Sie mit Authentifizierung, Sitzungsverwaltung, Autorisierung, Eingabebehandlung, Geheimnissen und Datenoffenlegung. Verfolgen Sie anschließend jede Stelle, an der die App in ein anderes System wechselt: Zahlungswebhooks, E-Mail-Links, Dateispeicher, Hintergrundaufgaben, Verwaltungsendpunkte, Analytik und Aufrufe von KI-Modellen. Jede Grenze fügt Fehlermöglichkeiten hinzu, die ein erfolgreicher Browserablauf nicht zeigt.

Der Application Security Verification Standard von OWASP bietet eine Grundlage zum Testen technischer Kontrollen von Webanwendungen und eine Anforderungsliste für sichere Entwicklung. Ich nutze ihn als Abdeckungsindex, nicht als Behauptung, jedes kleine SaaS brauche jede einzelne Anforderung. Wählen Sie die zutreffenden Kontrollen aus, notieren Sie die verwendete Version und hängen Sie konkrete Tests an. Das ist ehrlicher als eine undefinierte «OWASP-Prüfung».

Sicherheitsbefunde, die das Angebot häufig vergrößern, sind:

• Autorisierung nur in der Oberfläche, ohne serverseitige Prüfung des Eigentümers;
• offengelegte Zugangsdaten, die Rotation, Verlaufsprüfung und Änderungen der Bereitstellung verlangen;
• als Zeichenkette gebaute Datenbankabfragen mit nutzergesteuerten Werten;
• gemeinsame Verwaltungsrouten ohne Rollenmodell oder Prüfprotokoll;
• öffentliche Datei-URLs, obwohl das Produkt private Dateien verspricht.

Schweregrad und Reparaturaufwand gehören in getrennte Spalten. Ein schwerwiegendes offengelegtes Geheimnis kann günstig zu ändern sein, wenn die Zugangsdaten nur ein deaktivierter Testwert waren. Ein mittlerer Autorisierungsdefekt kann teuer werden, wenn er in Dutzenden Handlern und alten Datensätzen steckt. Bepreisen Sie den Aufwand nach der betroffenen Fläche und dem verlangten Nachweis. Nutzen Sie den Schweregrad für Priorität, Eindämmung und Freigabebedingungen. Wer beides vermischt, lädt den Anbieter dazu ein, Angst zu berechnen.

Betrachten Sie eine App mit zwei Mandanten, bei der der Browser Datensätze anderer Konten ausblendet. Die API akzeptiert /projects/123, lädt Projekt 123 und gibt es ohne Prüfung der Mandantenkennung zurück. Die Abfrage zu korrigieren kann Minuten dauern. Alle ähnlichen Endpunkte zu finden, das Verhalten von Administratoren festzulegen, Hintergrundaufgaben zu reparieren, negative Tests zu ergänzen und eine mögliche Datenoffenlegung zu prüfen, ist die eigentliche Arbeit. Ein Angebot für eine Zeile hat den Fehler nicht verstanden.

Das Secure Software Development Framework des NIST fordert, Ursachen zu beheben, damit Schwachstellen nicht erneut auftreten. Für eine Sanierung heißt das: Ein geleaktes Geheimnis ist nicht erledigt, sobald es aus der aktuellen Datei gelöscht wurde. Die Arbeit kann Widerruf, Ersatz, Prüfung der Repository-Historie, Bereitstellungskonfiguration, geringere Berechtigungen und einen Test gegen weitere eingecheckte Geheimnisse umfassen. Bepreisen Sie die ganze Kette oder schließen Sie Teile ausdrücklich aus.

Vor der Logikreparatur steht eine Produktentscheidung

Eine Logikreparatur lässt sich nur dann zum Festpreis anbieten, wenn der Eigentümer für jeden wichtigen Ablauf das erwartete Ergebnis nennen kann. Generierter Code setzt oft einen plausiblen Pfad um, aber plausibel bedeutet nicht vereinbart.

Die Abrechnung macht das deutlich. Angenommen, der Checkout erstellt ein bezahltes Konto, aber der Code reagiert nicht einheitlich auf eine fehlgeschlagene Verlängerung, Erstattung, Zahlungsanfechtung, Herabstufung, einen verspäteten Webhook oder ein doppeltes Ereignis. Ein Entwickler kann die Abrechnung nicht nach Geschmack «reparieren». Der Eigentümer muss entscheiden, wann sich der Zugriff ändert, welche Daten verfügbar bleiben und ob ein Administrator den Zustand überschreiben darf.

Vor der Preisfindung forme ich jeden Ablauf in eine kurze Entscheidungsliste:

• Ein Testkonto mit bestätigter gültiger Zahlung wird aktiv, und bezahlte Funktionen werden einmal freigeschaltet.
• Ein aktives Konto mit doppelter Bestätigung bleibt aktiv, ohne doppelte Gutschrift oder E-Mail.
• Ein aktives Konto mit fehlgeschlagener Verlängerung wechselt in den festgelegten Kulanz- oder Sperrzustand und zeigt einen klaren Status.
• Ein aktives Konto mit bestätigter Erstattung wechselt in den schriftlich festgelegten Zustand nach der Erstattung, und der Zugriff folgt dieser Regel.

Die Liste deckt fehlende Produktregeln auf, ohne sie als technischen Defekt darzustellen. Liefert der Eigentümer die Entscheidungen während der Diagnose, kann der Entwickler Umsetzung und Tests bepreisen. Fallen die Entscheidungen erst während der Reparatur, braucht das Angebot eine Entscheidungsreserve, eine stündliche Untersuchungsposition oder einen ausdrücklichen Änderungsmechanismus.

Für eine kleine App mit zwei bis vier beschädigten Kernabläufen ist eine Planungsspanne von 1.500 bis 5.000 Dollar angemessen. Das untere Ende passt zu örtlich begrenzten Zustands- oder Validierungsfehlern mit klaren Abnahmefällen. Das obere Ende passt zu Verhalten, das über Browserzustand, API-Handler, Datenbanktrigger und externe Callbacks verteilt ist. Rechnen Sie mehr ein, wenn Produktionsdaten korrigiert werden müssen, denn eine sichere Nachpflege braucht Probeläufe, Zählungen, Sicherungen, Idempotenz und einen Plan zur Umkehr.

Die Datenkorrektur sollte als eigene Größe erscheinen, auch wenn die Codekorrektur einen Festpreis hat. Die Schätzung kann eine bekannte Tabelle, einen Datumsbereich und eine maximale Datensatzmenge festlegen und anschließend ein wiederholbares Skript samt Prüfquery bepreisen. Wenn der tatsächliche Umfang die Grenze überschreitet, wissen beide Seiten bereits, welche Tatsache sich geändert hat. Akzeptieren Sie nie das Versprechen, «die Datenbank zu bereinigen», ohne Auswahlregel und Zählungen vor und nach dem Lauf.

Verwechseln Sie eine funktionierende Vorführung nicht mit einer korrekten Zustandsmaschine. Klicktests beweisen meist nur eine Reihenfolge von Ereignissen. In Produktion treffen Ereignisse spät, doppelt und manchmal erst nach einer Änderung durch den Administrator ein. Ein Festpreisangebot sollte nennen, welche Ereignisfolgen und Fehlerzustände die Tests abdecken.

Refactoring braucht einen Reparaturgrund

Refactoring gehört nur dann in ein Sanierungsangebot, wenn es das Risiko oder die Kosten einer benannten Reparatur senkt. Ein allgemeiner Auftrag zur Bereinigung gibt dem Entwickler unbegrenzten geschmacklichen Spielraum und dem Käufer kein objektives Ende.

Nützliches Refactoring hängt direkt mit den Befunden zusammen. Eine zentrale Autorisierungsfunktion kann verhindern, dass fünf Endpunkte Eigentum unterschiedlich prüfen. Das Ersetzen dreier widersprüchlicher Abonnementmerkmale durch einen definierten Zustand kann die Abrechnungsreparatur testbar machen. Die Trennung von Umgebungskonfiguration und Code kann verhindern, dass Testwerte in Produktion gelangen.

The Twelve-Factor App empfiehlt, bereitstellungsabhängige Konfiguration wie Zugangsdaten und Ressourcenadressen in Umgebungsvariablen statt in Codekonstanten zu speichern. Der Trennung stimme ich zu, aber das Verschieben von Zeichenketten reicht nicht. Die Sanierung braucht außerdem eine Prüfung beim Start, eine dokumentierte Variablenliste, sinnvolle sichere Standardwerte und einen klaren Fehler bei fehlenden Pflichtwerten. Sonst sieht die App auf dem Papier sauberer aus und scheitert weiterhin bei der Bereitstellung.

Ein gezieltes Refactoring-Paket für eine kleine Codebasis kann 8 bis 30 Stunden dauern und im hier verwendeten Modell oft 1.000 bis 4.000 Dollar kosten. Definieren Sie es über Grenze und Ergebnis: «Autorisierung für Projekt- und Rechnungsrouten zentralisieren, vorhandenes erlaubtes Verhalten erhalten und die Zugriffsmatrix bestehen». Vermeiden Sie «Architektur verbessern» oder «Spaghetti-Code bereinigen». Niemand kann beweisen, wann solche Formulierungen abgeschlossen sind.

Ich widerspreche auch der automatischen Empfehlung für eine Neuentwicklung. Leere Dateien gefallen Entwicklern, weil sie unbequemen Code dann nicht verstehen müssen. Eine Neuentwicklung verwirft jedoch funktionierendes Randverhalten, verzögert Rückmeldungen und schafft ein zweites System, dessen Unbekannte noch nicht sichtbar sind. Schreiben Sie eine Komponente neu, wenn ihr Vertrag verstanden ist und die Reparatur mehr als der Ersatz kostet. Schreiben Sie die gesamte App nur neu, wenn die Diagnose zeigt, dass die aktuelle Struktur das verlangte Verhalten nicht sicher bewahren kann. Bepreisen Sie Datenmigration und Umschaltung als eigenständige Arbeit.

Refactoring darf keine Zusatzabgabe sein, nur weil ein KI-Werkzeug den Code erzeugt hat. Berechnen Sie Arbeit, die das Ergebnis verändert. Harmlose Hässlichkeit darf bleiben.

Tests belegen den Abschluss des Angebots

Tests brauchen einen eigenen Umfang, weil «die App funktioniert jetzt» keinen Abschluss der Sanierung beweist. Der Testplan sollte direkt zum Befundregister und den kritischen Abläufen des Eigentümers passen.

Bei einem kleinen SaaS möchte ich gewöhnlich eine schmale automatisierte Suite für Authentifizierung, Zugriff zwischen Mandanten, den wichtigsten Erstellungs- oder Bearbeitungsablauf, Änderungen des Abrechnungszustands und jede zerstörerische Verwaltungsaktion. Fügen Sie an Grenzen Integrationstests hinzu, wenn Attrappen den Fehler verdecken würden. Ein simulierter Zahlungs-Callback kann keine Signaturprüfung nachweisen. Eine Datenbank im Arbeitsspeicher bildet womöglich die Beschränkungen und Abfragen der Produktionsdatenbank nicht ab.

The Twelve-Factor App empfiehlt, Entwicklung und Produktion so ähnlich wie möglich zu halten. Das ist hier wichtig, weil generierte Prototypen häufig lokal eine andere Datenbank als in Produktion verwenden oder nur im Browser mit großzügiger Entwicklungskonfiguration getestet werden. Testvergleichbarkeit verlangt keinen Produktionsklon. Sie verlangt dieselben wichtigen Diensttypen, denselben Migrationspfad, dieselbe Laufzeitversion und dieselben Konfigurationsregeln.

Ein kompakter Abnahmenachweis kann so aussehen:

AC-07 Cross-tenant project read
Given: user A belongs to tenant A; project B belongs to tenant B
When:  user A requests the project B identifier through the API
Then:  response is 404; no project fields are returned; denial is logged
Evidence: integration test authz.projects.spec, run 184, passed

Dieser Eintrag erfüllt drei Aufgaben. Er sagt dem Entwickler, was zu bauen ist, gibt dem Käufer ein überprüfbares Ende und begrenzt Diskussionen darüber, ob ein Bildschirmfoto als Beweis zählt. Bei Angeboten dieser Größe decken 1.500 bis 4.000 Dollar häufig die Testeinrichtung und kritischen Fälle ab. Der Preis steigt, wenn der Code keine Testansatzpunkte bietet, externe Dienste keinen sicheren Testmodus haben oder asynchrone Arbeit eine deterministische Steuerung benötigt.

Manuelle Kontrollen bleiben für das visuelle Verhalten und schnelle Bereitstellungsprüfungen wichtig. Sie sollten wiederholbare Tests ergänzen, nicht ersetzen. Streicht ein Anbieter Tests für einen niedrigeren Preis, kauft der Kunde geänderten Code und verschiebt die Prüfung auf die Nutzer.

Die Testverantwortung ist nach der Übergabe wichtig. Das Angebot sollte nennen, welche Befehle lokal und in der kontinuierlichen Integration laufen, welche Testdaten sie erzeugen und welche externen Zugangsdaten sie brauchen. Instabile Tests taugen nicht als Abnahmenachweis. Lässt sich eine Grenze im Budget nicht automatisieren, nennen Sie das manuelle Verfahren, das erwartete Ergebnis und die verantwortliche Person, statt die Prüfung still zu streichen.

Die Bereitstellung gehört zur Sanierung

Die Vorbereitung der Bereitstellung muss als Entwicklungsarbeit bepreist werden, denn eine Reparatur nur auf einem Notebook hat das Produkt nicht repariert. Der Umfang braucht eine Zielumgebung, erforderliche Zugänge, Freigabeschritte, Migrationsverhalten, Zustandsprüfungen und Rücknahmebedingungen.

Bei einem üblichen verwalteten Host können 750 bis 2.500 Dollar die Konfigurationsprüfung, einen wiederholbaren Build, die Einbindung der Migrationen, eine Testfreigabe, schnelle Prüfungen, die Kontrolle von Protokollen und eine kurze Betriebsanleitung abdecken. Diese Spanne setzt vorhandene Konten und eine zur Technik passende Plattform voraus. Fehlende Eigentümerschaft, unpassende Laufzeitgrenzen, Netzwerkbeschränkungen oder ein nicht genannter Hintergrundprozess können die Aufgabe verändern.

Build, Freigabe und Ausführung sind im Twelve-Factor-Modell getrennte Phasen. Diese Unterscheidung findet einen häufigen Fehler von KI-erstellten Apps: Ein Build-Skript greift auf eine aktive Datenbank zu, eine Migration läuft bei jedem Prozessstart oder die Laufzeitkonfiguration landet in einem öffentlichen Browserpaket. Die Sanierung muss jede Aktion in die richtige Phase legen und nachweisen, dass aus dem geprüften Commit eine frische Freigabe entsteht.

Der Bereitstellungsnachweis sollte Commit, Migrationsversion, Konfigurationscheckliste, Ergebnis der Schnellprüfung und Rücknahmepunkt festhalten. Ändert eine Schemamigration vorhandene Zeilen, verlangen Sie eine Sicherung oder Wiederherstellungsmethode und eine Zählung im Probelauf. Kann die Plattform die Datenbank nicht gemeinsam mit der Anwendung zurücksetzen, muss die Anleitung den Reparaturweg nach vorn erklären.

FixMyMess verbindet KI-gestützte Werkzeuge mit menschlicher Prüfung für Codediagnose, Logikreparatur, Sicherheitshärtung, Refactoring und Bereitstellungsvorbereitung. Das kostenlose Code-Audit kann klären, ob ein Projekt eine begrenzte Reparatur oder einen größeren Neuaufbau braucht. Das hilft bei der Vorprüfung, doch der daraus entstehende Festpreis braucht weiterhin die hier beschriebenen Annahmen und Abnahmenachweise.

«Bereitstellung enthalten» darf nicht heißen, dass jemand einmal einen Knopf drückt. Das Ergebnis ist eine Freigabe, die eine andere kompetente Person verstehen und wiederholen kann.

Einige Befunde müssen das Angebot neu öffnen

Eine gute Festpreisvereinbarung nennt Entdeckungen, die das Angebot ändern dürfen, denn der Festpreis überträgt gewöhnliches Ausführungsrisiko, nicht alle verborgenen Bedingungen. Der Auslöser muss sachlich und überprüfbar sein, nicht «der Code war schlimmer als erwartet».

Ich verwende Auslöser wie diese:

• Ein erforderliches Repository, Dienstkonto oder eine Produktionsumgebung fehlt nach dem vereinbarten Zugangsdatum.
• Das Produktionsschema oder die Laufzeitumgebung weicht wesentlich von der diagnostizierten Version ab.
• Die Untersuchung bestätigt eine mandantenübergreifende Offenlegung, aktiven Missbrauch von Zugangsdaten oder eine notwendige Vorfallprüfung.
• Der Eigentümer ändert eine Abnahmeregel, fügt einen Ablauf hinzu oder wählt ein anderes Bereitstellungsziel.
• Die Datenkorrektur betrifft Datensätze oder Systeme außerhalb der geprüften und dokumentierten Grenze.

Jeder Auslöser sollte den nächsten Schritt bestimmen. Der Anbieter pausiert das betroffene Paket, zeigt die Nachweise, erklärt die Möglichkeiten und bepreist nur die Differenz. Nicht betroffene Arbeiten können fortgesetzt werden, wenn es sicher ist. Der Käufer sollte die Änderung ablehnen und die bereits bezahlten abgeschlossenen Arbeiten und Notizen erhalten können.

Gewöhnliche Abweichungen bleiben beim Anbieter. Umfasst das Angebot die Reparatur von fünf benannten Endpunkten, ist ein längerer Handler keine Änderung. Verweist das geprüfte Repository auf eine Datenbank und hängt die Produktion tatsächlich von einer zweiten, nicht dokumentierten Datenbank mit widersprüchlichen Datensätzen ab, liegt wahrscheinlich eine Änderung vor. Die Vereinbarung sollte einen Schätzfehler von geänderten Tatsachen unterscheiden.

Sicherheitsentdeckungen brauchen besondere Behandlung. Eine vermutete Offenlegung kann Fragen zur Beweissicherung, Rotation, Meldung oder Rechtslage außerhalb des ursprünglichen Programmierumfangs auslösen. Der Entwickler sollte diese Arbeit weder in einer kleinen Reparaturreserve verstecken noch selbst über die Reaktion der Organisation entscheiden. Das Angebot kann Eindämmungscode abdecken, während eine andere verantwortliche Person die Pflichten aus dem Vorfall koordiniert.

Eine Obergrenze kann unsichere Arbeit kaufbar machen. Genehmigen Sie zum Beispiel bis zu acht Stunden, um ein unerwartetes Datenproblem zu untersuchen, und verlangen Sie danach eine neue Entscheidung. Damit kaufen Sie Nachweise statt einer unbegrenzten Reparatur.

Ein belastbares Angebot zeigt seine Rechnung

Das endgültige Angebot sollte Pakete, Annahmen, Ausschlüsse, Abnahmetests, Terminabhängigkeiten und die Gesamtsumme zeigen. So kann ein nicht technischer Eigentümer Angebote vergleichen, ohne die Bedeutung von «produktionsbereit» erraten zu müssen. Eine einzelne Gesamtsumme verbirgt zu viel.

Nehmen wir eine diagnostizierte App mit fehlerhafter mandantenübergreifender Autorisierung in vier API-Routen, widersprüchlichem Abonnementzustand, eingecheckten Testzugangsdaten, die nie in Produktion verwendet wurden, doppelter Konfiguration, fast keinen automatisierten Tests und einer funktionierenden verwalteten Bereitstellung. Ein Beispielangebot könnte verteilen:

• 1.500 Dollar auf Diagnose und Befundregister;
• 3.200 Dollar auf die Reparatur von Autorisierung und Geheimnissen;
• 2.800 Dollar auf die Reparatur der Abonnementlogik;
• 1.400 Dollar auf das für diese Reparaturen nötige Refactoring;
• 3.800 Dollar auf Tests der kritischen Abläufe, Testfreigabe und Anleitung.

Der Festpreis beträgt insgesamt 12.700 Dollar.

Diese Summe ist nur zusammen mit ihren Annahmen belastbar. Die Zugangsdaten sind nachweislich nicht in Produktion genutzt worden und werden trotzdem entfernt und ersetzt. Der Eigentümer liefert Entscheidungen zur Abrechnung innerhalb von zwei Arbeitstagen. Der vorhandene Host bleibt das Ziel. Das Angebot schließt eine historische Vorfalluntersuchung, ein neues visuelles Design, zusätzliche Funktionen und die Korrektur von Produktionsdaten über eine benannte Stichprobe hinaus aus.

Die Zahlungsstruktur sollte den Nachweisen folgen. Eine Anzahlung reserviert die Arbeit, eine Zwischenzahlung kann auf nachgewiesene Reparaturen in der Testumgebung folgen und die Schlusszahlung auf den Abnahmenachweis und die Übergabe. Die genauen Prozentsätze sind Geschäftsbedingungen, aber Meilensteine sollten beobachtbare Ergebnisse statt vergangener Tage beschreiben.

Vergleichen Sie Ausschlüsse ebenso sorgfältig wie Summen. Ein Angebot kann Steuern, Projektleitung, eine Testumgebung und dreißig Tage Fehlerkorrektur enthalten, während ein anderes bei einem Integrationsvorschlag endet. Dieser Rahmen setzt keine Gewährleistungsfrist voraus. Käufer sollten daher fragen, was passiert, wenn ein enthaltener Abnahmefall nach der Übergabe fehlschlägt. Ein Korrekturzeitraum sollte Abweichungen vom vereinbarten Verhalten abdecken, nicht neue Anforderungen oder Ausfälle fremder Dienste.

Terminversprechen brauchen dieselbe Disziplin. Entwicklungsaufwand entspricht nicht der Kalenderdauer, wenn der Anbieter auf Kontenzugänge, Produktentscheidungen oder eine Prüfung durch Dritte wartet. Das Angebot sollte Antwortfristen des Eigentümers nennen und erklären, ob Verzögerungen den Liefertermin verschieben. Ein kurzes Lieferversprechen ohne Zugangsannahmen ist Werbung, keine Planung.

Stellen Sie jedem Anbieter dieselben fünf Fragen: Welchen Commit und welche Umgebung haben Sie geprüft, welche Befunde sind enthalten, was beweist jede Reparatur, welche Tatsachen dürfen den Preis ändern und was besitze ich bei der Übergabe? Ein günstigeres Angebot ohne Antworten ist nicht vergleichbar. Es hat die Kosten in Unklarheit verschoben.

Ein Festpreis funktioniert, wenn die Diagnose Unsicherheit in benannte Annahmen und Tests verwandelt. Zeigt ein Anbieter die Rechnung nicht, kaufen Sie zuerst eine begrenzte Diagnose. Wenn die Nachweise zeigen, dass eine Reparatur die falsche Wahl ist, kostet diese frühe Erkenntnis weniger als ein ordentliches Angebot für ein unordentliches System zu erzwingen.