Dein MVP ist nicht dein Produkt: Die technischen Schulden, die du behalten solltest
„Baut eure technischen Schulden ab" ist der häufigste Ratschlag im Software Engineering. Er ist auch gefährlich unvollständig.
Nach dem Bau Dutzender MVPs haben wir gelernt, dass manche technische Schulden strategisch sind. Abkürzungen nehmen ist nicht Faulheit, wenn es bewusst, dokumentiert und reversibel geschieht. Das Ziel eines MVPs ist nicht sauberer Code — es ist validiertes Lernen. Und validiertes Lernen hat eine Deadline.
Hier ist unsere Taxonomie: was man behält, was man fixt, und was nie wichtig war.
Stufe 1: Schulden, die man behält
Absichtliche, zeitlich begrenzte Schulden, die schnelleres Shipping ermöglichen, ohne die Sicherheit zu gefährden.
Hardcodierte Konfiguration
// „Schulden" — aber es shippt heute
const SUPPORTED_CURRENCIES = ["EUR", "USD"];
const MAX_ORDER_ITEMS = 50;
const FREE_SHIPPING_THRESHOLD = 50;
// „Sauber" — aber es shippt nächste Woche
const config = await prisma.systemConfig.findMany();
// Plus: Admin-UI, Validierung, Caching, Migration...Eine Config-Tabelle, Admin-Interface und Caching-Layer, um einen Schwellenwert zu ändern, der sich vielleicht nie ändert? Das ist eine Woche Arbeit für ein Problem, das noch nicht existiert. Hardcoden. // TODO: konfigurierbar machen wenn nötig. Weiter.
Einfache Authentifizierung
Euer MVP braucht am ersten Tag kein „Sign in with Google", SAML SSO oder passwortlose Authentifizierung. E-Mail und Passwort mit ordentlichem Hashing ist sicher und in Stunden implementiert, nicht Wochen.
Manuelle Prozesse
Manche Dinge müssen noch nicht automatisiert werden:
- User-Onboarding: Accounts manuell erstellen statt Self-Service-Signup zu bauen
- Rechnungsstellung: Rechnungen in einer Tabelle generieren statt ein Billing-System zu integrieren
- Reporting: SQL-Queries ausführen statt ein Dashboard zu bauen
Automatisiert etwas, wenn ihr es mehr als 10 Mal pro Woche macht. Darunter ist manuell okay. Ihr seid ein MVP — ihr habt wahrscheinlich 20 Nutzer, nicht 20.000.
Stufe 2: Schulden, die vor der Skalierung gefixt werden müssen
Die gefährliche Kategorie. Sie killt euer MVP nicht, aber sie killt euer Produkt, wenn ihr sie nicht angeht, bevor ihr wachst.
Keine Tests
Ein MVP mit null Tests ist für die ersten 4 Wochen okay. Ein MVP, das zu einem Produkt skaliert, mit null Tests ist eine tickende Zeitbombe.
Was zuerst testen: Nicht Unit Tests für Utility-Funktionen. Testet die kritischen Pfade:
describe("Kritische Pfade", () => {
it("Nutzer kann sich registrieren und einloggen");
it("Nutzer kann eine Bestellung erstellen");
it("Zahlung wird erfolgreich verarbeitet");
it("Nutzer erhält Bestätigungs-E-Mail");
});Vier Tests. Sie decken den Revenue-Pfad ab.
Kein CI/CD
Wenn Deployment „SSH auf den Server und git pull" bedeutet, seid ihr einen schlechten Merge von Downtime ohne Rollback-Plan entfernt.
Kein Error Monitoring
Sentry.init({
dsn: process.env.SENTRY_DSN,
environment: process.env.NODE_ENV,
});15 Minuten Setup. Free Tier reicht für die meisten MVPs. Es gibt keine Ausrede.
Wir haben eine Codebase geerbt, die 3 Monate „problemlos lief". Sie hatte ein Memory Leak, das den Server alle 72 Stunden abstürzen ließ. Der Fix des vorherigen Teams? Ein Cronjob, der den Server jede Nacht neustartet. Ohne Error Monitoring wusste niemand, warum die Neustarts nötig waren.
Stufe 3: Schulden, die nie wichtig waren
Perfekte Ordnerstruktur
Clean Architecture, Hexagonal Architecture, Onion Architecture — das sind wertvolle Patterns für große, langlebige Systeme. Für ein MVP sind sie premature Abstraction. Nutzt die Konventionen des Frameworks.
100 % TypeScript Strictness
strict: true ist nicht verhandelbar. Die zusätzlichen Flags? Sie fangen Edge Cases, die in einer Million-Zeilen-Codebase wichtig sind, aber Friction in einem 10.000-Zeilen-MVP erzeugen.
Umfassende Docstrings
Wenn eure Funktion calculateOrderTotal heißt und ein Order-Objekt nimmt, braucht sie keinen JSDoc-Kommentar, der erklärt, dass sie die Bestellsumme berechnet. Benennt Dinge gut. Spart Dokumentation für das Nicht-Offensichtliche.
Die Schulden-Audit-Checkliste
Muss vorhanden sein (blockierend):
- Tests für kritische Pfade existieren und bestehen
- CI/CD-Pipeline deployed automatisch
- Error Monitoring ist aktiv und alarmiert
- Strukturiertes Logging ist vorhanden
- Datenbank-Backups laufen automatisch
- Secrets sind in Umgebungsvariablen, nicht im Code
Sollte vorhanden sein (nächster Sprint):
- Auth behandelt Edge Cases (Passwort-Reset, Session-Ablauf)
- Rate Limiting auf öffentlichen Endpoints
- Input-Validierung auf allen API-Routes
- README, mit dem ein neuer Dev das Projekt in 30 Min zum Laufen bringt
Nice to have (wenn es sich richtig anfühlt):
- Admin-Dashboard für gängige Operationen
- Automatisierte E-Mail-Workflows
- Performance-Monitoring
- Konfigurierbare Business Rules
Das Fazit
Technische Schulden sind ein Werkzeug, keine Sünde. Die Frage ist nicht „haben wir Schulden?" — sondern „wissen wir, wo sie sind, und wissen wir, wann wir sie abbezahlen?"
Dokumentiert eure Abkürzungen. Macht sie absichtlich. Und verwechselt nie ein MVP mit einem Produkt — der ganze Sinn eines MVPs ist herauszufinden, ob es eins werden sollte.
