Prototyp-Härtungs-Sprint
Was wir in Ihrem Prototyp härten
Audit, dann ein Festumfang-Sprint
KI-Coding-Werkzeuge liefern in Tagen einen funktionierenden Demo — und dieselbe Geschwindigkeit hinterlässt Auth-Gerüste, fehlende Tests und Datenbank-Abkürzungen. Wir führen ein einwöchiges Audit am echten Code durch, kartieren die produktionskritischen Lücken und setzen anschliessend einen Fix-Sprint von 6 bis 12 Wochen auf. Der Umfang ist nach dem Audit fix. Der Code bleibt durchgängig beim Kunden; der Sprint endet mit Produktionsübergabe oder optionalem Retainer.
Echtes Auth und Zugriffssteuerung
Von KI generiertes Auth-Gerüst liefert ein Login-Formular und ein Token, kein produktives Session-Modell. Wir refaktorieren auf echtes RBAC, JWT oder Server-Session mit Ablauf und Rotation, Passwort-Reset und E-Mail-Verifikation, optional MFA und Audit-Log auf jeder priviligierten Aktion. Berechtigungs-Checks wandern aus dem UI in die API, wo sie hingehören.
Security-Audit und OWASP-Härtung
Eingabevalidierung, Secret-Rotation, Rate-Limiting, CORS, CSP, Dependency-Upgrades und ein Durchgang gegen die OWASP Top 10. Geheimnisse, die im Client-Bundle oder im öffentlichen Repo gelandet sind, werden rotiert und in einen echten Secrets-Manager verschoben. CSP und Rate-Limits werden auf das echte Verkehrsmuster zugeschnitten, nicht aus einer Vorlage kopiert.
Datenbank- und Datenmodell-Refactor
Der typische KI-gebaute Prototyp legt alles in eine breite JSON-Spalte und fragt sie bei jedem Render ab. Wir refaktorieren in normalisierte Tabellen mit Fremdschlüsseln und Indexen, schreiben die Migrationen vom Ist- in den Ziel-Stand ohne Downtime, und beheben die N+1-Muster, die bei echter Last umfallen.
Tests dort, wo keine waren
Die meisten Vibe-Coded-Prototypen kommen ohne Tests. Wir setzen Unit-Tests rund um die Geschäftslogik, Integrationstests an der API-/Datenbank-Grenze und End-to-End-Tests für die kritischen Benutzerpfade. Ziel ist keine 100-Prozent-Deckung — sondern ein Sicherheitsnetz, das die nächste Änderung erlaubt, ohne die produktiven Pfade stillschweigend zu brechen.
CI/CD, Observability und Skalierungsreife
Echte Deploy-Pipelines mit Umgebungstrennung (lokal, Staging, Produktion), Secrets-Management und ein Observability-Stack — Logs, Traces, Errors und einfache SLOs. Wir lasttesten die heissen Pfade, ergänzen Caching dort, wo es zählt, und stellen eine Queue- und Background-Job-Architektur auf, damit der Prototyp die eigentliche Arbeit nicht mehr auf dem Request-Thread macht.
So härten wir einen Prototyp
Einwöchiges Audit am echten Code
Wir lesen den Prototyp so, wie eine eintretende Engineering-Hire es täte — Auth-Fluss, Datenbankschema, Request-Handler, Geheimnisse, Abhängigkeiten, Deploy-Setup, Test-Abdeckung. Ergebnis ist ein schriftliches Audit mit den produktionskritischen Lücken, der empfohlenen Fix-Reihenfolge und einem Festumfang-Angebot für den anschliessenden Sprint.
Fundament zuerst — Auth, Security, Datenbank
Die ersten Wochen des Sprints gehen an die Fundamente, auf denen alles andere ruht. Echtes Auth und RBAC, OWASP-Fixes und der Datenbank-Refactor landen, bevor wir den Rest anfassen. Wir arbeiten auf einem Feature-Branch des Prototyps des Kunden, nicht in einer Parallel-Neuschreibung, damit das Team weiter shippen kann.
Tests, CI/CD und Observability
Sobald die Fundamente stehen, kommen Tests, Deploy-Pipelines und Observability online. Wir säen die Test-Suite um die kritischen Pfade, hängen sie in die CI ein und stellen Staging- und Produktionsumgebungen mit echtem Secrets-Management und Basis-Logging, Traces und Error-Reporting auf.
Skalierungsreife und Produktionsübergabe
Die Schlussphase umfasst Lasttests, Caching, Queues und Background-Jobs — was immer der Prototyp braucht, um den nächsten Traffic-Schritt zu halten. Wir schliessen mit einer Produktionsübergabe ab: Runbooks, On-Call-Notizen, Deploy- und Rollback-Playbooks. Danach betreibt das Gründerteam es selbst oder behält uns auf Retainer.
Wir lesen den Prototyp so, wie eine eintretende Engineering-Hire es täte — Auth-Fluss, Datenbankschema, Request-Handler, Geheimnisse, Abhängigkeiten, Deploy-Setup, Test-Abdeckung. Ergebnis ist ein schriftliches Audit mit den produktionskritischen Lücken, der empfohlenen Fix-Reihenfolge und einem Festumfang-Angebot für den anschliessenden Sprint.
Die ersten Wochen des Sprints gehen an die Fundamente, auf denen alles andere ruht. Echtes Auth und RBAC, OWASP-Fixes und der Datenbank-Refactor landen, bevor wir den Rest anfassen. Wir arbeiten auf einem Feature-Branch des Prototyps des Kunden, nicht in einer Parallel-Neuschreibung, damit das Team weiter shippen kann.
Sobald die Fundamente stehen, kommen Tests, Deploy-Pipelines und Observability online. Wir säen die Test-Suite um die kritischen Pfade, hängen sie in die CI ein und stellen Staging- und Produktionsumgebungen mit echtem Secrets-Management und Basis-Logging, Traces und Error-Reporting auf.
Die Schlussphase umfasst Lasttests, Caching, Queues und Background-Jobs — was immer der Prototyp braucht, um den nächsten Traffic-Schritt zu halten. Wir schliessen mit einer Produktionsübergabe ab: Runbooks, On-Call-Notizen, Deploy- und Rollback-Playbooks. Danach betreibt das Gründerteam es selbst oder behält uns auf Retainer.
Warum Härtung sinnvoller ist als ein Rewrite
Ihr Prototyp hat das Produkt schon bewiesen
Die KI-Coding-Werkzeuge haben ihren Platz verdient — sie haben eine funktionierende Idee in Tagen vor echten Nutzern gehabt, nicht in Monaten. Den Code wegzuwerfen, um neu zu schreiben, verbrennt dieses Signal. Härtung erhält die Produktform, die die Nutzer bereits bestätigt haben, und ersetzt nur die Teile, die die Produktion blockieren.
Auth-Gerüst ist das Erste, das bricht
Demo-Auth ist ein Login-Formular und ein Token im Local Storage. Produktions-Auth sind Sessions mit Ablauf und Rotation, Passwort-Reset- und Verifikationsflüsse, Audit-Log auf priviligierten Aktionen und Berechtigungs-Checks, die auf dem Server durchgesetzt werden. Wir machen diesen Refactor früh, weil jede weitere Änderung davon abhängt, wer was darf.
Sicherheits-Defaults aus einer Vorlage sind nicht Ihre Defaults
KI-Werkzeuge liefern vernünftig wirkende Defaults, die einem Tutorial besser stehen als einem Live-Produkt. Rate-Limits sind meistens zu grosszügig oder fehlen, CSP ist freizügig, CORS ist offen, Secrets landen im Client-Bundle. Wir prüfen das gegen die OWASP Top 10 und schneiden es auf die Verkehrsform zu, die das Produkt wirklich hat.
Die Datenbank ist der Ort, an dem Prototypen unter Last sterben
JSON-Spalten und N+1-Abfragen funktionieren prima bei den ersten zehn Nutzern. Sie versagen zwischen Nutzer hundert und Nutzer tausend — genau dann, wenn das Produkt anfängt zu zählen. Wir refaktorieren in ein echtes Schema mit Indexen und Migrationen, ohne die Produktionsdaten zu verlieren, die der Prototyp bereits gesammelt hat.
Tests sind eine Einstellungsentscheidung, kein Luxus
Das Team, das eine Codebasis ohne Tests erbt, liefert mit jedem Feature langsamer, weil jede Änderung ein Tippen ins Blaue ist. Wir säen genug Deckung, damit der nächste Engineer — intern oder als Auftrag — den Code ändern kann, ohne die stille Regression zu fürchten. Diese Deckung entscheidet, ob die Codebasis wächst oder steckenbleibt.
Übergabe heisst, dass Sie es ohne uns betreiben können
Der Sprint endet mit Runbooks, Deploy- und Rollback-Playbooks, On-Call-Notizen und einer schriftlichen Tour durch den Produktions-Stack. Wenn das Gründerteam uns lieber auf Retainer behält, ist dieser Weg offen — aber die Übergabe ist in jedem Fall real. Das Produkt war von Anfang an Ihres und bleibt es, wenn wir gehen.
Häufig gestellte Fragen
Sechs bis zwölf Wochen. Eine Woche Audit am echten Code, dann ein Festumfang-Sprint, den das Audit beziffert. Wir deckeln Engagements bei sechzehn Wochen — wenn die Arbeit länger dauern würde, ist der Prototyp über die Härtung hinaus, und ein Custom-Platform-Development-Rewrite ist die ehrliche Empfehlung.
Diese drei decken das meiste Inbound ab, das wir sehen. Wir haben auch Prototypen aus Cursor-gesteuerten Greenfields, Replit Agent und handgerollten GPT-Coded-Codebasen gehärtet. Die Pipeline ist werkzeugagnostisch — wir lesen das echte Repository in Woche eins und beziffern den Sprint daraus.
Nein. Rewrites sind ein separates Custom-Platform-Development-Engagement. Härtung erhält den Prototyp, den die Nutzer bestätigt haben, und ersetzt nur die Teile, die die Produktion blockieren — Auth, Security, Datenbank, Tests, CI, Skalierung. Zeigt das Audit, dass der Code jenseits der Härtung ist, sagen wir das und beziffern stattdessen den Rewrite-Pfad.
Ein schriftliches Audit zu Auth-Fluss, Datenbankschema, Request-Handlern, Geheimnissen, Abhängigkeiten, Deploy-Setup und Test-Abdeckung — mit produktionskritischen Lücken priorisiert, empfohlener Fix-Reihenfolge und einem Festumfang-Angebot für den Sprint. Das Audit ist ein vergütetes Einwochen-Engagement; die Lieferung gehört Ihnen, ob Sie uns für den Sprint engagieren oder nicht.
Ihnen. Das Prototyp-Repository bleibt vom ersten Tag in Ihrem Account. Wir committen auf einen Feature-Branch, den Sie kontrollieren, Sie mergen nach Ihrem Zeitplan, und wir halten den Code nicht als Teil eines Retainers fest. Die Übergabe nach Woche zwölf umfasst Runbooks und Playbooks, damit das Team es ohne uns betreiben kann.
Wir migrieren in der bestehenden Engine, wenn sie passt — PostgreSQL mit Schema-Refactor ist der Standardpfad. Auf eine andere Engine wechseln wir nur, wenn der Prototyp etwas gewählt hat, worauf das Produkt unter Skalierung nicht leben kann. So oder so schreiben wir die Migrationen, die die Live-Daten von der heutigen Form ins Zielschema bringen, ohne Downtime.
Ja — die meisten Engagements enden mit einem kleineren Engineering-Retainer (ein bis zwei Engineers für zwei bis vier Monate), der die nächsten Features auf der gehärteten Basis liefert. Der Retainer ist optional, wird separat skoptiert und beginnt erst nach abgeschlossener Produktionsübergabe.
Über SAPIENTROQ
Sind Sie an einer Lösung interessiert?
Wir freuen uns, Ihnen die Möglichkeiten unverbindlich aufzuzeigen.
Roland Kurmann
CEO, SAPIENTROQ
