Technisches MVP-Audit: Was wir in den ersten 48 Stunden prüfen

Die meisten MVP-Audits produzieren ein Dokument. Ein nützliches produziert Entscheidungen: Was brennt, was kann warten, und was kostet die Behebung.

Ein technisches MVP-Audit beantwortet eine Frage: Trägt diese Codebasis die nächsten zwölf Monate des Geschäfts — und wenn nicht, was genau muss sich ändern? Alles andere — Tooling-Meinungen, Stildebatten, Framework-Präferenzen — ist Rauschen.

Dies ist die Checkliste, die wir in den ersten 48 Stunden abarbeiten. Sie ist bewusst nach den Kosten eines Fehlers geordnet: Die Punkte oben können ein Unternehmen beenden, die unten kosten Geschwindigkeit.

1. Geld- und Datenintegrität (höchste Fehlerkosten)

Bewegt das Produkt Geld oder hält es regulierte Daten, kommt das zuerst. Fehler hier sind keine Störungen — sie sind Haftungsrisiken. Wir prüfen:

• Ob Salden aus einem append-only Journal abgeleitet werden oder als veränderbare Zahl gespeichert sind, die Code überschreiben kann
• Idempotenz auf jedem Zahlungs- und Webhook-Pfad — kann ein wiederholter Request doppelt belasten oder gutschreiben?
• Exakte Dezimal- oder ganzzahlige Untereinheiten mit Währungsregeln verwenden.
• Transaktionsgrenzen: Kann ein Teilausfall einen Zustand hinterlassen, in dem Geld doppelt oder gar nicht existiert
• Abstimmung: Gibt es einen Prozess, der eine Differenz erkennt — oder erfahren Sie es vom Kunden?

2. Sicherheit und Zugriffskontrolle

• Autorisierung serverseitig pro Request geprüft — oder angenommen, weil die UI den Button versteckt
• Secrets in Umgebungsvariablen und einem Secret Manager, nicht in der Repository-Historie
• PII und Kartendaten: Was wird gespeichert, wo, und sollte es überhaupt gespeichert werden
• Erreichbare Schwachstellen in Abhängigkeiten, nicht nur eine rote Zahl im Report
• Mandantentrennung: Kann ein präparierter Request Daten anderer Kunden lesen?

3. Architektur und Skalierungsgrenzen

Wir suchen keine Eleganz. Wir suchen die konkrete Wand, gegen die das System läuft — und wie weit sie entfernt ist.

• Single Points of Failure — die Datenbank, die Queue, der eine Service, den alle aufrufen
• Query-Muster, die bei 1.000 Zeilen unauffällig und bei 1.000.000 fatal sind (N+1, fehlende Indizes, unbegrenzte Scans)
• Ob ohne Downtime deployt werden kann — und ob es je jemand versucht hat
• Kopplung, die verhindert, ein Feature auszuliefern, ohne fünf Module anzufassen
• Ob die Architektur zur Teamgröße passt — Microservices mit vier Entwicklern sind ein Skalierungsproblem, keine Lösung

4. Delivery und Betrieb

Codebasen verfallen nicht von selbst; der Prozess bestimmt das Tempo. Was wir messen:

5. Technische Schulden: triagiert, nicht aufgelistet

Jede Codebasis hat Schulden. Eine Liste davon ist nutzlos. Entscheidend ist die Einordnung in drei Kategorien:

1. Blockierend — verhindert die Roadmap oder gefährdet Geld/Daten. Sofort beheben.
2. Kumulierend — macht jede künftige Änderung langsamer. Bewusst einplanen.
3. Kosmetisch — stört den Geschmack, kostet nichts. In Ruhe lassen.

Ziel eines Audits ist nicht, alles Falsche zu finden. Es ist, die wenigen Dinge zu finden, die falsch genug sind, um zu zählen — und konkret zu benennen, was sie kosten.

Was Sie am Ende erhalten sollten

• Priorisierte Befunde mit Schweregrad und Geschäftsauswirkung — kein Katalog
• Pro Befund: die Behebung, ein realistischer Aufwand und die Folgen des Nichtstuns
• Eine sequenzierte Roadmap: dieses Quartal, nächstes Quartal, später
• Belege — die konkrete Query, der konkrete Endpoint — damit Ihr Team prüfen statt glauben kann

Aus der Erstprüfung einen überprüfbaren Backlog machen

Eine zeitlich begrenzte Prüfung beschreibt die Abdeckung, nicht die Abwesenheit aller Fehler. Jeder Befund braucht nachvollziehbare Belege.

1. Betroffenen Nutzerablauf und Reproduktionsbedingungen dokumentieren.
2. Beobachtete Fehler, vermutete Risiken und unzugängliche Bereiche unterscheiden.
3. Für jede Korrektur Verantwortung und Regressionstest festlegen.

• MVP Rettung →
• MVP reparieren →