METHODE

Produktionsreif

Software, die du echten Usern vorsetzen kannst, ohne um 3 Uhr nachts einen Alert zu bekommen: Autorisierung auf jedem Endpoint, validierter Input, keine Secrets im Client, Error Handling, eine Regressions-Suite, Observability, Rollbacks. Ein funktionierendes Demo ist nicht produktionsreif.

Zuletzt geprüft: vonChristof Jori wiki ↗

Produktionsreif ist der Unterschied zwischen Software, die funktioniert wenn du sie demost, und Software, die funktioniert wenn du schläfst und ein Fremder sie falsch benutzt. Es ist kein Gefühl und kein Meilenstein, den du ausrufst. Es ist eine konkrete Checkliste, und die Lücke zwischen Demo und produktionsreif ist exakt die Liste der Dinge, die keinen sichtbaren Payoff haben, bis zu dem Moment, in dem sie failen.

Die Checkliste, klar gesagt: Autorisierung auf jedem Endpoint, nicht nur Authentifizierung am Login; Input-Validierung auf allem, was eine Trust-Boundary überschreitet; keine Secrets im Client-Bundle oder im Repo; Error Handling, das fail-safe ist statt einen Stacktrace zu leaken; eine Regressions-Suite, die bei jeder Änderung läuft, damit der nächste Fix keinen alten Bug wieder aufreißt; Observability, damit du es von einem Dashboard erfährst, nicht von einem wütenden Kunden; und ein Rollback-Pfad in Minuten. Fehlt eines davon, hast du ein Demo im Produktions-Kostüm.

Beispiel. Zwei Versionen derselben Buchungs-App sehen im Demo identisch aus. Version A gibt eine Buchung per ID zurück, nachdem sie nur geprüft hat ob du eingeloggt bist. Version B prüft, dass der eingeloggte User diese Buchung tatsächlich besitzt, validiert das ID-Format, loggt den Zugriff und alertet wenn ein Account anfängt IDs durchzuzählen. Gleiche Screens, gleicher Happy Path, gleiches Demo. Version A ist ein Breach, der auf jemand Neugierigen wartet, Version B ist produktionsreif. Das user-sichtbare Produkt ist identisch, was genau der Grund ist, warum „es funktioniert im Demo" nichts über Produktionsreife aussagt.

Der ehrliche Trade-off: Produktionsreif zu werden kostet echte Zeit, und das meiste davon kauft nichts, was ein Kunde je sehen oder dir danken wird. Das ist genuin frustrierend, wenn ein Demo schon fertig aussieht, und der einzige Grund, warum Teams ausliefern bevor sie sollten. Der Deal ist für alles mit Userdaten nicht optional, aber es ist ehrlich zuzugeben, dass die Rechnung sich wie reiner Overhead anfühlt, bis der 3-Uhr-Alert oder der DSGVO-Brief sie zum billigsten Geld macht, das du je ausgegeben hast. Für einen echten Wegwerf-Prototyp ist das Überspringen die richtige Entscheidung.

Wavects Production-Readiness-Durchlauf ist die Brücke von einem vibe-coded oder KI-generierten Prototyp zu etwas, für das du Geld verlangen kannst, unter Software Quality Assurance. Wir arbeiten die Checkliste in der Reihenfolge des Blast-Radius ab: Autorisierung zuerst, weil dort die schlimmsten Bugs leben, dann Validierung, Secrets, Error Handling, dann die TDD-Regressions-Suite und das CI/CD-Gate, das sie grün hält. Das Ziel ist nicht Perfektion. Das Ziel ist, dass niemand um 3 Uhr nachts wegen etwas geweckt wird, das du vor dem Ausliefern hättest lesen können.

// FAQ

Häufige Fragen

Konkret: Autorisierung auf jedem Endpoint, validierter Input, keine Secrets im Client, fail-safe Error Handling, eine Regressions-Suite die bei jeder Änderung läuft, Observability und ein schneller Rollback-Pfad. Es ist eine Checkliste, kein Gefühl. Ein funktionierendes Demo beweist von alldem nichts.
Ein Demo läuft nur den Happy Path ab, den du durchklickst. Produktion läuft den feindseligen Pfad, den unachtsamen User, den neugierigen User der eine ID in der URL ändert, den unerwarteten Input, die gleichzeitige Last. Produktionsreife ist genau die Arbeit, die das Happy-Path-Demo nie berührt und nie als fehlend aufzeigt.
Es hängt davon ab, wie der Prototyp gebaut wurde, aber weil die Lücken in KI-generiertem Code systematisch sind, ist der Durchlauf meist schneller als befürchtet. Wir arbeiten in Reihenfolge des Blast-Radius (Autorisierung, dann Validierung, Secrets, Error Handling, dann Tests und das CI-Gate), damit die riskantesten Löcher zuerst schließen, selbst wenn das Budget knapp wird.