Wie Sie ein MVP bauen, das auch in Monat neun noch funktioniert

Um ein MVP zu bauen, das auch in Monat neun noch funktioniert, entscheiden Sie vor dem ersten Screen fünf Dinge: das Datenmodell, Konten und Rollen, Zahlungen, die Hosting-Region und die Release-Pipeline. Dann kürzen Sie das erste Release auf einen Nutzer, eine Aufgabe und einen Weg, liefern es über eine automatisierte Pipeline aus und halten jede wesentliche Entscheidung schriftlich fest, sobald Sie sie treffen. Alles andere, vom Admin-Dashboard bis zu Microservices, kann warten.

Der Grund ist Monat neun. Dann haben Sie echte Nutzer, einen zweiten Entwickler und eine Roadmap, und jede Abkürzung aus Monat eins bestimmt das Tempo in Monat zehn. Dieser Leitfaden behandelt die Entscheidungen, die teuer rückgängig zu machen sind, die Wahl, wer baut, die DSGVO-Grundlagen, einen Vierwochenplan, den Zuschnitt und die Übergabe.

#Ein MVP ist kein Prototyp

Eric Ries definierte das Minimum Viable Product als die Version eines neuen Produkts, mit der ein Team mit dem geringsten Aufwand das meiste validierte Wissen über seine Kunden gewinnt. Von echten Kunden zu lernen heißt: echte Konten, echte Daten und früher oder später echtes Geld.

Ein Prototyp beantwortet die Frage „Könnte das funktionieren?“ und ist zum Wegwerfen gedacht: ein klickbares Design, eine Demo für den Pitch-Day, ein Skript auf einem Laptop. Ein MVP beantwortet die Frage „Werden Menschen das nutzen und dafür bezahlen?“, und wer antwortet, hinterlässt darin seine Daten. Das können Sie nicht wegwerfen.

Der Ärger beginnt, wenn ein Prototyp in den Produktivbetrieb rutscht, ohne dass jemand das entschieden hat. Screens, Geschäftsregeln und Datenbankabfragen landen in denselben Dateien, Login und Zahlungen werden spät angeflanscht, und Deployments laufen vom Rechner einer einzelnen Person. In Monat zwei sieht nichts falsch aus. In Monat neun kostet jedes Feature mehr, als es sollte.

Martin Fowler beschreibt diese Mehrkosten als die Zinsen auf technische Schulden: den zusätzlichen Aufwand, den neue Features wegen Mängeln in der inneren Qualität verursachen. Manche Schulden sind ein fairer Tausch gegen Tempo. Das Ziel einer ersten Version ist, Schulden bewusst aufzunehmen, an Stellen, an denen sie günstig zu tilgen sind, und nie im Fundament.

#Fünf Entscheidungen für Woche eins

Woche eins gehört den Entscheidungen auf Papier, nicht den Screens. Jede dieser fünf ist vor der ersten Zeile Produktcode günstig richtig zu treffen und teuer zu ändern, sobald Nutzer davon abhängen.

1. Das Datenmodell

Halten Sie die zentralen Entitäten fest, wie sie zusammenhängen und wem welcher Datensatz gehört. Bei den meisten B2B-Produkten ist die Mandantenfähigkeit die entscheidende Frage: Bekommt jede Kundenorganisation ihren eigenen Bereich, und trägt jede relevante Tabelle vom ersten Tag an einen Verweis auf die Organisation? Mandantenfähigkeit nachträglich in ein Schema für nur einen Mandanten einzubauen, berührt jede Abfrage, die Sie je geschrieben haben. Führen Sie das Schema in versionierten Migrationen, nie in manuellen Änderungen an der Live-Datenbank.

2. Konten, Rollen und Berechtigungen

Legen Sie fest, wie sich Menschen anmelden, wie Nutzer zu Organisationen gehören und welche Rollen es gibt. Zwei oder drei Rollen reichen für den Start, sie sollten aber an einer Stelle auf dem Server geprüft werden, nicht als if-Abfragen über die Screens verstreut. Nutzen Sie einen etablierten Authentifizierungsanbieter oder eine bewährte Bibliothek, statt die Passwortverwaltung selbst zu schreiben, und lassen Sie Raum für Single Sign-on, denn Ihr erster Enterprise-Kunde wird danach fragen.

3. Zahlungen

Auch wenn Sie zum Start nichts berechnen: Entscheiden Sie, wer zahlt (eine Person oder eine Organisation), wofür (Arbeitsplätze, Nutzung oder ein Pauschaltarif) und wo der Abo-Status liegt. Nutzen Sie den gehosteten oder eingebetteten Checkout eines Zahlungsanbieters, damit Kartendaten nie Ihre Server berühren. Stripe etwa erklärt, dass seine risikoarmen Integrationen Zahlungsdaten direkt an Stripe senden und Ihre Pflichten nach PCI DSS verringern.

4. Die Hosting-Region

Wählen Sie die Region für Datenbank, Backups, Protokolle und Dateispeicher und prüfen Sie die Region jedes Anbieters, der personenbezogene Daten berührt. Für ein Produkt, das in Deutschland, Österreich und der Schweiz verkauft wird, ist eine EU-Region die sinnvolle Voreinstellung. Sie nimmt Ihnen die DSGVO-Pflichten nicht ab, streicht aber die Frage nach Drittlandübermittlungen aus den meisten Sicherheitsfragebögen, die Kunden Ihnen schicken werden.

5. Die Release-Pipeline

Vom ersten Commit an läuft jede Änderung durch Versionskontrolle, automatisierte Tests und ein automatisiertes Deployment, erst auf Staging, dann in Produktion. Niemand deployt vom Laptop. Eine Pipeline in Woche eins aufzusetzen ist langweilig; sie in Monat neun einzuführen ist sehr schwer, wenn das Team gelernt hat, von Hand auszuliefern, und jedes Release ein angehaltener Atem ist.

Was Sie bewusst weglassen

• Microservices. Eine gut strukturierte Anwendung mit klaren inneren Schichten (Oberfläche, Geschäftsregeln, Daten) ist für ein kleines Team leichter zu ändern und zu betreiben.
• Ein eigenes Admin-Panel. Nutzen Sie einen Datenbank-Client oder ein einfaches internes Tool, bis die Supportarbeit zeigt, was Admins wirklich brauchen.
• Native Apps für beide Plattformen, sofern das Produkt keine Gerätefunktionen braucht. Eine responsive Web-App reicht oft, um zu lernen.
• Mehr Sprachen, als Ihr erster Markt braucht, wobei Sie Texte, Datumsangaben und Währungen so speichern sollten, dass sie später möglich sind.
• Selbst gebaute Infrastruktur wie ein eigener Analytics-Stack, ein eigener Feature-Flag-Dienst oder ein eigenes Designsystem.
• Sonderfälle für Kunden, die Sie noch nicht haben.

#Welche Entscheidungen teuer rückgängig zu machen sind

In seinem Aktionärsbrief von 2015 teilte Jeff Bezos Entscheidungen in Einbahn- und Zweiwegtüren ein: folgenreiche, kaum umkehrbare, die Sorgfalt verdienen, und umkehrbare, die eine kleine Gruppe schnell treffen sollte. Die meisten Entscheidungen in einem Startup sind Zweiwegtüren. Die Kunst ist, die wenigen zu erkennen, die es nicht sind, und Woche eins nicht von den umkehrbaren auffressen zu lassen.

Sehen Sie sich an, was auf der teuren Seite steht: Daten, Identität, Geld und der Ort, an dem sie liegen. Das sind die Entscheidungen, die Sie in Woche eins schriftlich vereinbaren. Den Rest kann treffen, wer gerade baut, am selben Tag, und ihn ändern, wenn Sie mehr wissen.

#No-Code, Agentur, Freelancer oder eigenes Team

Wie Sie am besten bauen, hängt weniger vom Budget ab als von zwei Fragen: Wer wird den Code in Monat neun besitzen und verstehen, und wie viel Ihres Produkts ist die Software selbst? Wenn Sie als Gründerin oder Gründer nach „App entwickeln lassen“ suchen, stellen Sie jedem Anbieter diese zwei Fragen, bevor Sie Angebote vergleichen.

Wofür Sie sich auch entscheiden: Der Vertrag sollte festhalten, dass Code, Repositories, Cloud-Konten und Domains von Anfang an Ihrem Unternehmen gehören und dass Dokumentation eine geschuldete Leistung ist, kein Gefallen.

#DSGVO-Grundlagen, die vom ersten Tag an stimmen müssen

Die DSGVO verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art. 25). Für eine erste Version läuft das auf vier praktische Punkte hinaus. Das ist eine allgemeine Information: Verarbeiten Sie Gesundheits- oder Finanzdaten, Daten von Kindern oder etwas Ungewöhnliches, sprechen Sie vor dem Start mit einer auf Datenschutz spezialisierten Kanzlei.

Hosting-Region und Drittlandübermittlungen

Die DSGVO verlangt nicht, dass Daten in der EU bleiben. Sie verlangt für jede Übermittlung außerhalb des EWR eine Grundlage nach Kapitel V, etwa einen Angemessenheitsbeschluss oder Standardvertragsklauseln. Für US-Anbieter deckt das EU-US Data Privacy Framework Übermittlungen an danach zertifizierte Unternehmen ab. Das Gericht der EU hat das Framework im September 2025 bestätigt, ein Rechtsmittel (Rechtssache C-703/25 P) ist jedoch beim Gerichtshof anhängig. Wer die Primärdaten in einer EU-Region hält und die Übermittlungsgrundlage jedes Anbieters kennt, begrenzt sein Risiko, wie auch immer entschieden wird.

Ein AVV mit jedem Auftragsverarbeiter

Jeder Anbieter, der in Ihrem Auftrag personenbezogene Daten verarbeitet, vom Hosting über den E-Mail-Versand bis zum Error-Tracking, braucht einen Vertrag nach Art. 28. In Deutschland ist das der Auftragsverarbeitungsvertrag (AVV), und Ihre B2B-Kunden werden auch von Ihnen einen verlangen. Führen Sie eine Liste der Anbieter mit den Daten, die jeder erhält, dem Speicherort und dem Datum des AVV. Diese Liste ist zugleich der Anfang Ihres Verzeichnisses von Verarbeitungstätigkeiten nach Art. 30, dessen Ausnahme für Organisationen unter 250 Beschäftigten nicht greift, sobald die Verarbeitung mehr als gelegentlich erfolgt.

Einwilligung und wann Sie keine brauchen

Viele erste Versionen holen Einwilligungen ein, die sie nicht brauchen, und übersehen die, die sie brauchen. Daten, die Sie zur Erfüllung Ihres Vertrags benötigen, brauchen keine Einwilligung. Nicht notwendige Cookies und ähnliche Zugriffe auf das Endgerät schon: In Deutschland verlangt § 25 TDDDG eine Einwilligung, es sei denn, der Zugriff ist für einen vom Nutzer gewünschten Dienst unbedingt erforderlich. Wo Sie sich auf eine Einwilligung stützen, halten Sie fest, was wann vereinbart wurde, denn Art. 7 verlangt, dass Sie sie nachweisen, und macht den Widerruf so einfach wie die Erteilung.

Löschung, die wirklich löscht

Art. 17 gibt Menschen ein Recht auf Löschung, und Art. 19 verpflichtet Sie, die Empfänger zu informieren, denen Sie die Daten offengelegt haben. Konzipieren Sie die Löschung in Woche eins: welche Datensätze gelöscht werden, welche anonymisiert oder aufbewahrt werden, weil das Gesetz es verlangt (etwa Rechnungen), wie die Löschung Auftragsverarbeiter und Backups erreicht und wer sie auslösen kann. Ein Soft-Delete-Flag in der Nutzertabelle ist kein Löschprozess.

#Ein Plan für die ersten vier Wochen, Woche für Woche

Dieser Plan setzt ein eng zugeschnittenes Produkt und ein kleines, erfahrenes Team voraus. Ein größerer Umfang dauert länger, die Reihenfolge bleibt aber dieselbe: Entscheidungen, dann das Gerüst, dann das erste Release.

Ab dann liefern Sie in festem Rhythmus aus, wöchentlich ist eine gute Voreinstellung, mit einem kurzen Review, das entscheidet, was als Nächstes live geht. Ein gleichmäßiger Rhythmus zählt mehr als die Größe des einzelnen Release.

#Wie Sie das erste Release zuschneiden

Schneiden Sie das erste Release auf einen Nutzer, eine Aufgabe und einen Weg zu. Formulieren Sie es in einem Satz: „Eine Praxismanagerin kann ihr Team einladen und die Buchungen dieser Woche an einem Ort sehen.“ Alles, was diesem Satz nicht dient, kommt auf die Streichliste. Behalten Sie die Liste, denn sie wird Ihre Roadmap.

1. Benennen Sie den ersten Nutzer genau: Rolle, Art des Unternehmens und was er heute nutzt.
2. Listen Sie die Schritte der einen Aufgabe vom ersten Besuch bis zum Ergebnis auf und streichen Sie jeden Schritt, der nicht unverzichtbar ist.
3. Markieren Sie die Schritte, die die teuren Entscheidungen berühren (Daten, Rollen, Geld). Diese bauen Sie ordentlich; der Rest darf schlicht sein.
4. Wählen Sie ein oder zwei Signale, die zeigen, dass es funktioniert hat, etwa Aktivierung oder eine wiederholte Aktion, und messen Sie nur diese.
5. Legen Sie ein Datum fest und kürzen Sie den Umfang, um es zu halten, statt das Datum zu verschieben.

Ein gutes erstes Release fühlt sich für die Gründer klein an und für den ersten Nutzer vollständig. Füllt Ihre Liste der Must-haves eine ganze Seite, beschreiben Sie Version drei.

#Wie eine ordentliche Übergabe aussieht

Der Test einer Übergabe ist einfach: Kann ein Entwickler, der nicht dabei war, das Produkt deployen, Fehler finden und erweitern, ohne die Person anzurufen, die es gebaut hat?

Entscheidungsprotokolle sind der am meisten unterschätzte Teil. Das Format der Architecture Decision Records von Michael Nygard hält jede wesentliche Entscheidung in einer kurzen Datei fest, mit Kontext, Entscheidung, Status und Folgen. Fragt der zweite Entwickler in Monat neun, warum die Mandantenfähigkeit so funktioniert, wie sie funktioniert, steht die Antwort im Repository statt im Gedächtnis eines Einzelnen.

Konten sind die andere Falle, und manche brauchen Zeit. Apple verlangt, dass sich eine Organisation als juristische Person mit einer D-U-N-S-Nummer registriert, und Google Play legt ohne eine solche Nummer kein Entwicklerkonto für Organisationen an; die kostenlose Beantragung kann bis zu 30 Tage dauern. Fangen Sie früh an, auf den Namen des Unternehmens, nie auf den eines Freelancers oder einer Agentur.

#Wie wir Sie unterstützen

Bespoke IT baut erste Versionen für Startups in Deutschland, Österreich und der Schweiz nach dem hier beschriebenen Zeitplan: Architektur in Woche eins, ein funktionierendes Produkt in Woche drei und eine Übergabe, mit der Ihre erste Entwicklerin oder Ihr erster Entwickler ohne uns weiterarbeiten kann. Planen Sie eine erste Version oder haben Sie schon eine, die sich nach Monat neun anfühlt, sehen Sie sich an, wie wir mit Startups arbeiten.