Schritt 5: Red-Team-Kill-List, Exit und De-Risking¶

Diese Datei ist der Gegenpol zum Happy Path. Sie beantwortet vier Fragen:

Was wuerde Phase A vor Unterschrift killen?
Was wuerde sie nach Go-live killen?
Wann ist Pause / Remediate sinnvoll und wann nur noch De-Risk oder Exit?
Wie sieht ein geordneter Rueckzug konkret aus?

Sie wird zusammen mit 03-go-no-go.md und 04-live-gehen.md verwendet.

Datenbasierte Pruefung: Fuer die automatisierbare Gate-Pruefung gegen aktuelle Marktdaten siehe Phase A Gate-Check und Phase B Gate-Check.

Schnellreferenz fuer harte Trigger¶

Diese Werte sind die wichtigsten numerischen Warnschilder in Phase A:

Reserve vor Unterschrift: >= 6 Monate Fixkosten nach Anzahlung und Setup
Go-Ziel UG-Konto: grob ~20.000 EUR
Stop-Loss nach Launch: 2-Monats-Rolling-Netto < -400 EUR/Mo
Erfolgskorridor nach Ramp-up: 70-80% Rolling-Auslastung
Kill-/Neubewertungszone: <45% Auslastung ueber den Ramp-up-Zeitraum

A0. Marktdaten Kill-Signale (vor IC-Entscheidung)¶

Diese Signale werden waehrend der Datensammlungsphase (min. 30 Tage) ueberwacht. Wenn eines eintritt, wird die IC-Entscheidung verschoben oder abgebrochen — bevor Geld gebunden wird.

Kill-Signal	Schwelle	Datenquelle	Konsequenz
DE-Auslastung bricht ein	`<50%` ueber 20+ Werktage	`peer_host_daily` DE-Maschinen	No-Go — Nachfrage in DE nicht ausreichend
EU A100-Preis crasht	Median faellt `>25%` vs. erste Messwoche	`snapshots` EU A100 80GB Segmente	No-Go — Preisbasis traegt nicht
Break-even nicht erreichbar	EU Median (netto EUR) faellt unter `€0,718` fuer `>14 Tage`	`snapshots` + FX	No-Go — kein profitabler Betrieb moeglich
Vast.ai fuehrt Host-Fee wieder ein	Jede Aenderung `>5%` am Fee-Modell	Vast.ai Announcements / Docs	Pause — Economics komplett neu rechnen
H100/H200 verdraengt A100	A100-Auslastung faellt `>20pp` waehrend H100-Angebot waechst	`offers` nach GPU-Typ	Pause — SKU-Wahl ueberpruefen

Automatisierung: Diese Signale werden durch die bestehende Datensammlungspipeline (alle 30 Min Snapshots, taegliches Peer-Tracking) ueberwacht. Der taegliche Report (07:00 Cronjob) sollte Abweichungen flaggen.

Wichtig: Keines dieser Signale ist bisher eingetreten. Aber wir haben erst 3 Tage Daten (Ostern). Die Signale koennen erst nach 20+ Werktagen belastbar geprueft werden.

A. Pre-IC Kill-Tests¶

Wenn einer dieser Punkte eintritt und kurzfristig nicht sauber loesbar ist: nicht unterschreiben.

Kill-Test	Warum kritisch	Standard-Reaktion
Marktdaten Kill-Signal ausgeloest	Eines der Signale aus A0 ist eingetreten	Entsprechend A0 reagieren
Kein Vast-faehiger Colo-Vertrag	Ohne 500/500 Mbps, offene Ports, statische IPv4 und genug Strom ist Phase A kein valider Test	Anbieter wechseln oder Phase A pausieren
Nur Finanzierung mit unbeschraenkter persoenlicher Haftung	Downside waere nicht mehr auf UG-Kapital, Reserve und Hardware begrenzt	Nicht unterschreiben
Wirtschaftlichkeit nur bei optimistischen Mittelwerten	`80% util > 0` allein reicht nicht; Stress und Worst-Credible-Month muessen ueberlebbar sein	Nachverhandeln oder nicht starten
Restschuld-/Exit-Pfad unklar	Ein frueher Ausstieg kann sonst teurer sein als angenommen	Vor Vertrag modellieren oder abbrechen
Reserve nach Setup zu duenn	Der erste schwache Monat zwingt sonst sofort in Hoffnung statt Disziplin	Kapital erhoehen oder Go verschieben
Weniger als 30 Tage Marktdaten	Entscheidung auf zu duenner Datenbasis	Warten bis Daten vorliegen

B. Ramp-up Kill-Tests (nach Go-live)¶

Diese Punkte pruefen, ob Phase A ein echter Markt- und Betriebsnachweis ist oder nur ein teurer Lernversuch.

Kill-Test	Beobachtung	Reaktion
Kein Listing-Fit	Nach 30 Tagen keine belastbare Buchungsdynamik trotz funktionierendem Setup	Pricing, Template, Verification pruefen; wenn weiter schwach: De-Risk / Exit
Reliability bleibt zu schwach	Incidents, langsame Reaktion oder Backlog druecken Ranking und Buchungen	Kein Wachstum; Betrieb stabilisieren
Oekonomie wird durch Payout/FX/Remote Hands fragil	Nachfrage da, aber echter Netto-Ertrag zu niedrig oder zu volatil	Kostenbasis / Vertrag / Pricing neu setzen
Root Cause ist nicht isolierbar	Es ist unklar, ob Problem Nachfrage, Preis, Hardware oder Platform Fit ist	Kein weiterer Kapitalcommit, bis Ursache klar ist

Praktische Lesart fuer Tag 60 / 90:

Wenn 2-Monats-Rolling-Netto < -400 EUR/Mo, keine Expansion und sofort in pause-remediate
Wenn Auslastung nach Ramp-up Richtung 70-80% laeuft, ist das mit dem Plan konsistent
Wenn Auslastung ueber den Ramp-up-Zeitraum unter 45% bleibt und keine klare Remediation sichtbar ist, Richtung de-risk oder exit

C. Scale Kill-Tests (vor Server #2+)¶

Wenn einer dieser Punkte zutrifft, ist Wachstum der falsche Reflex.

Kill-Test	Warum kritisch	Reaktion
Flotten-Stress-Netto nicht positiv	Mehr Server verstaerken dann nur die gleiche Schwachstelle	Expansion stoppen
Reserve reicht nur fuer den Ist-Zustand, nicht fuer die groessere Flotte	Mehr Fixlast ohne Puffer fuehrt in schleichenden Liquiditaetsstress	Erst Reserve aufbauen
Founder-Bandwidth ist bereits am Limit	Mehr Hardware ohne mehr Operations-Kapazitaet verschlechtert Reliability	Kein Wachstum ohne Entlastung
Wachstum wird mit Hoffnung auf bessere Marketplace-Raten begruendet	Das ist keine belastbare Investment-These	De-Risk statt Expand

D. Phase-C Kill-Tests¶

Diese Punkte verhindern, dass Phase C aus Vision statt aus Evidenz gestartet wird.

Kill-Test	Warum kritisch	Reaktion
BtM-/Direktleitungsstruktur rechtlich unsauber	Der Kostenvorteil kann sich sonst in Regulierung aufloesen	Bei Colo bleiben
Standort-Konnektivitaet nur ueber fragilen Fallback	Schlechtere Reliability kann Markt- und Betriebsvorteile auffressen	Nicht migrieren
Standort-OPEX + Migration schlagen Colo nicht klar	Phase C waere dann ein teurer Umbau ohne oekonomische Ueberlegenheit	Nicht ausloesen
B2B-/Green-Premium unbewiesen	Bessere Story ersetzt keine zahlenden Kunden	Marketplace-/Colo-Fallback behalten

Eskalationsstufen¶

Zustand	Bedeutung	Standard-Aktion
Go	Annahmen halten, Downside bleibt kontrolliert	Naechsten Schritt freigeben
Pause / Remediate	Operative Abweichung, aber noch klar behebbar	Kein Wachstum; Fehlerbild eingrenzen
De-Risk	Modell ist zu duenn fuer Wachstum, aber noch nicht exit-reif	Fixlast, Vertragsrisiko oder Footprint reduzieren
Exit	Kernannahmen sind gebrochen oder Downside wird asymmetrisch	Geordneter Rueckzug

Exit-Ablauf¶

Kein neues Kapital binden.
Listing reduzieren oder abschalten.
Offene Workloads sauber auslaufen lassen.
Colo-Kuendigung und Ausbau abstimmen.
Restschuld, Rueckkaufoptionen und Wiederverkaufswert zusammenrechnen.
Hardware verkaufen oder in minimalem Footprint weiterbetreiben.

Grundsatz¶

Exit ist kein Scheitern des Gesamtprojekts, sondern Schutz vor falscher Eskalation.
Wenn Phase A zeigt, dass das colo-basierte GPU-Hosting schon nicht robust genug ist, darf Phase B oder C nicht als psychologischer Rettungsversuch dienen.