Ein MVP hat eine einzige Aufgabe: zu prüfen, ob jemand zahlen will. Alles, was dieser Prüfung nicht dient, ist verlorene Zeit. Doch zwischen «schnell sein» und «schlampig bauen» verläuft eine Grenze, und sie liegt an präzisen Stellen.
Was man guten Gewissens vereinfachen darf
Am Anfang sind diese Abkürzungen gesund:
- Das Backoffice. Eine hässliche Administrationsoberfläche genügt ein Jahr lang bestens. Niemand von aussen sieht sie.
- Die Automatisierung seltener Fälle. Brauchen drei Kunden im Monat eine Sonderbehandlung, machen Sie es von Hand. Zu frühe Automatisierung friert eine Geschäftsregel ein, die sich gerade ändern wird.
- Die Skalierung. Ein einzelner Server trägt Tausende Nutzer. Für eine Million zu bauen, wenn man null hat, ist die teuerste Form der Prokrastination.
- Ein vollständiges Design-System. Fünf gut gemachte Komponenten reichen am Anfang.
Die drei Entscheidungen, die sich nicht rückgängig machen lassen
Drei Weichen strukturieren dagegen alles Weitere. Sie aufzuschieben kostet eine Neuentwicklung.
1. Das Datenmodell
Der Punkt ohne Wiederkehr. Starten Sie mit einem Nutzer, der zu genau einer Organisation gehört, und will ein Kunde sechs Monate später drei Tochtergesellschaften verwalten, betrifft die Migration jede Abfrage der Anwendung.
Stellen Sie die Frage am ersten Tag: wem gehört ein Datensatz? Einem Nutzer, einem Team, einer Organisation? Selbst wenn Sie anfangs nur an Selbstständige verkaufen: eine von Beginn an vorhandene Organisations-ID kostet fast nichts und verhindert das Schlimmste.
2. Authentifizierung und Berechtigungen
Rollen nachträglich einzuführen heisst, jeden Controller erneut zu lesen und zu fragen «wer darf das?». Schon eine minimale Berechtigungsschicht (zwei Rollen genügen) etabliert den Reflex und den Ort, an dem es steht.
3. Tests auf dem kritischen Pfad
Keine 100 % Abdeckung, das wäre in dieser Phase absurd. Aber Registrierung, Zahlung und die Hauptaktion des Produkts müssen abgedeckt sein. Das sind die drei Abläufe, deren Ausfall Kunden kostet, und die Sie am häufigsten ändern werden.
Der Wendepunkt
Der Übergang vom MVP zum Produkt entscheidet sich selten an der Technik. Er entscheidet sich, wenn der Support mehr Zeit frisst als die Entwicklung.
Signale, auf die man achtet:
- Sie beantworten mehrmals pro Woche dieselbe Frage;
- Sie korrigieren Daten von Hand in der Datenbank;
- eine neue Funktion zerstört regelmässig etwas Altes.
Das erste Signal ruft nach Dokumentation oder einer Änderung der Oberfläche. Das zweite nach einem Administrationswerkzeug. Das dritte nach Tests, und das ist das dringendste, weil es alles andere bremst.
In der Praxis
Ein ehrliches MVP entsteht in sechs bis zehn Wochen. Das Produkt danach entsteht laufend, in kurzen Schritten, mit Nutzern, die jede Auslieferung sehen.
Was Projekte auszeichnet, die halten, ist fast nie die technische Raffinesse am Anfang. Es ist ein Datenmodell, das von Tag eins an das Geschäft ehrlich abbildet.
