Beispiel-Deliverable
Beispiel-Risikobericht
Beurteilt das Deliverable, nicht den Pitch.
So sieht der Report eines Technical Risk Review aus — volle Struktur, echte Severity-Sprache, evidenzgeführte Findings und eine Fix-Reihenfolge, die ein Board lesen kann.
„Ledgerline“ ist fiktiv. Jedes Finding unten ist ein Muster, das wir in KI-gebauten Apps wiederholt sehen — so rekombiniert, dass kein Kunde erkennbar ist. Kunden-Reports bleiben privat.
Review-Akte
Ledgerline — B2B-Invoicing-SaaS
- Build
- 7 Wochen, KI-Pair-Tools + SaaS-Template
- Team
- 2 Founder, 1 Contractor
- Stack
- Next.js · Postgres · Stripe
- Anlass
- Erste zahlende Kunden; Seed-Diligence in 6 Wochen
- Paket
- Technical Risk Review
Executive Summary
Der Launch-Termin hält — nach zwei P0-Fixes.
Ledgerline ist näher an Launch-Reife als die meisten KI-gebauten Apps, die wir prüfen. Die Kernflows sind kohärent, das Datenmodell ist solide. Zwei Findings blockieren Umsatz: ein Account-Takeover-Pfad im Passwort-Reset und tenant-übergreifender Zugriff auf Rechnungsdaten.
Beides ist Arbeit von Tagen, nicht Wochen. Keins erfordert eine neue Architektur — aber beide brauchen Regressionstests, damit sie gefixt bleiben.
Die Trust-Gaps (P1) blockieren den Launch nicht, tauchen aber in Enterprise-Procurement und Diligence auf: unverifizierte Payment-Webhooks und fehlende Fehlersichtbarkeit. Die technischen Schulden (P2) sind planbar und sollten nichts verzögern.
Risikokarte
Sechs Findings. Severity, Evidenz, Impact, Fix-Pfad.
Echte Reports enthalten pro Finding Request-Traces, Screenshots und Datei-Referenzen. Dieses Beispiel behält die Struktur und kürzt die Evidenz.
P0 — Launch-Blocker
Auth · Passwort-Reset
Reset-Tokens laufen nie ab und überleben Wiederverwendung.
Was wir fanden
Reset-Links tragen ein rohes, im Klartext gespeichertes Token. Es hat kein Ablaufdatum und bleibt nach Nutzung gültig. Wir haben einen benutzten Link aus einer alten E-Mail erneut abgespielt und in einem zweiten Browser ein neues Passwort gesetzt.
Warum es zählt
Jeder mit Zugriff auf eine alte E-Mail — weitergeleiteter Thread, geteiltes Postfach, kompromittierte Mailbox — kann den Account übernehmen. Das ist der leise Account-Takeover-Pfad, der zum Disclosure-Fall wird.
Fix-Pfad
Tokens gehasht speichern, 30 Minuten Gültigkeit, Invalidierung bei Nutzung und Passwortänderung. Regressionstest ergänzen, der ein benutztes Token erneut abspielt und Ablehnung erwartet.
Aufwand: ~1 Tag
Daten · Tenant-Isolation
Invoice-Endpoints vertrauen der ID, nicht der Organisation.
Was wir fanden
Der Invoice-Detail-Endpoint prüft Login, aber nicht Organisationszugehörigkeit — und die IDs sind sequenziell. Eingeloggt in Tenant A haben wir per ID-Dekrement Rechnungen von Tenant B geladen.
Warum es zählt
Tenant-übergreifende Exposition von Kundennamen, Beträgen und Salden. Bei einem Finanzprodukt beendet ein einziger Screenshot davon Deals und kann Meldepflichten auslösen.
Fix-Pfad
Organisations-Scoping in einer gemeinsamen Query-Schicht erzwingen statt pro Route. Tenant-übergreifenden Regressionstest ergänzen, der laut fehlschlägt.
Aufwand: 2–3 Tage
P1 — Trust-Gaps
Payments · Webhooks
Stripe-Webhooks ohne Signatur und Idempotenz akzeptiert.
Was wir fanden
Die Webhook-Route parst den Event-Body direkt — keine Signaturprüfung, kein Replay-Schutz. Ein präparierter POST markiert jede Rechnung als bezahlt.
Warum es zählt
Gefälschte oder duplizierte Events korrumpieren den Zahlungsstatus. Heute still — später ein Audit-Finding und ein Abstimmungs-Albtraum.
Fix-Pfad
Stripe-Signatur verifizieren, Handler per Event-ID idempotent machen, unbekannte Events in eine Dead-Letter-Queue.
Aufwand: ~1 Tag
Operations · Sichtbarkeit
Fehler verschwinden in einem Catch-all.
Was wir fanden
Ein globaler Handler liefert generische 500er ohne kontextbezogenes Logging und ohne Alerting. Während des Reviews lieferte ein fehlschlagendes PDF-Rendering 40 Minuten lang 500er — ohne Spur.
Warum es zählt
Von Ausfällen erfahrt ihr durch Kunden. Diligence-Teams lesen das als Lücke in der operativen Reife.
Fix-Pfad
Strukturierte Logs mit Request-IDs, Error-Tracking mit Alerts auf neue Fehlerklassen, einfache Uptime-Checks.
Aufwand: 1–2 Tage
P2 — Technische Schulden
Codebase · Duplikation
Drei Kopien der Rechnungssummen-Logik.
Was wir fanden
Summen werden unabhängig in API, PDF-Renderer und Dashboard berechnet — beim Rundungsverhalten driften sie bereits.
Warum es zählt
Gewöhnliche KI-Build-Schulden. Wird zum Abrechnungsfehler, sobald sich Steuerregeln das nächste Mal ändern.
Fix-Pfad
Beim nächsten Anfassen dieses Codes in ein gemeinsames Modul konsolidieren. Kein eigener Sprint nötig.
Aufwand: Opportunistisch
Infra · Migrationen
Schema migriert beim Boot, ohne Rollback-Pfad.
Was wir fanden
Die App führt Datenbank-Migrationen beim Start aus. Zwei parallel startende Instanzen würden das Schema korrumpieren. Auf der heutigen Einzelinstanz harmlos.
Warum es zählt
Blockiert später horizontales Skalieren; jetzt kein Launch-Risiko.
Fix-Pfad
Migrationen vor der zweiten Instanz in einen expliziten Deploy-Schritt mit Rollback verlagern.
Aufwand: ~halber Tag, später
Wie es weitergeht
Der Report endet mit Entscheidungen, nicht mit Hausaufgaben.
60-Minuten-Readout
Wir führen Founder und Stakeholder in klarer Sprache durch Urteil und Risikokarte. Engineers bekommen den technischen Anhang mit Traces und Referenzen.
Eine Fix-Reihenfolge, die euren Termin respektiert
P0 zuerst, jeweils mit benanntem Abnahme-Check. Nichts aufgebläht, nichts vage — jeder Punkt wird eingeplant oder bewusst akzeptiert.
P0-Retest
Sobald die Blocker gefixt sind, verifizieren wir sie gegen die ursprüngliche Evidenz und schließen die Findings offiziell.
Wollt ihr diesen Blick auf eure App?
Das Beispiel oben ist ein Komposit. Euer Report ist spezifisch: euer Stack, eure Risiken, eure Fix-Reihenfolge — privat, auf Wunsch unter NDA.
Review anfragenWenn es passt, antworten wir innerhalb von 48 Stunden. Wenn nicht, sagen wir es euch.