Wie ich ein MVP bauen würde - und wie ich den Stack wirklich auswähle

Wenn Sie mich morgen bäten, ein MVP zu bauen, würde ich keine Tabelle mit 40 Frameworks öffnen. Ich würde keine Microservice-Karte zeichnen. Ich würde kein Produkt „zukunftssicher“ machen, das noch nie einen zahlenden Nutzer getroffen hat. Ich würde einen Satz aufschreiben: für wen das ist, welche Aufgabe es erledigt, und was wir in vier Wochen messen. Der Stack kommt nach diesem Satz - nicht davor.

Die meisten gescheiterten MVPs sind nicht zu klein. Sie sind falsch-groß: eine halb gebaute „Plattform“ mit Auth, Dashboards, Benachrichtigungen und drei Umgebungen - und trotzdem erledigt niemand die eine Aufgabe, die die Idee beweisen würde. Technologie ist oft das Alibi. Dieser Artikel ist, wie ich wirklich ausliefern würde.

1. Was ein MVP ist - und was ich nicht so nenne

MVP ist nicht „Version 1 mit weniger Bildschirmen“. Es ist das billigste Experiment, das die riskanteste Annahme töten oder stärken kann. Wenn die Annahme lautet „Menschen zahlen, um diesen Service online zu buchen“, ist das MVP ein Buchungsfluss plus Zahlung plus ein Mensch am anderen Ende - kein CRM, kein Treueprogramm, keine native App.

• Viable heißt: ein echter Nutzer kann eine echte Aufgabe zu Ende bringen. Ein klickbares Figma-Prototyp ist Forschung, kein MVP.
• Minimum heißt: alles, was diese Aufgabe nicht bedient, ist ein späteres Ticket - auch wenn es „leicht hinzuzufügen“ wirkt.
• Product heißt: nächste Woche können Sie es ohne Heldentum wiederholen. Ein Google Form plus Tabelle kann ein MVP sein. Ein Rewrite der Netflix-Architektur nicht.

2. Fünf Fragen, bevor ein Repository existiert

Stack-Debatten sind billig. Offene Produktfragen sind teuer. Ich wähle Postgres gegen Mongo nicht, bevor ich das laut beantworten kann - mit der Gründerin, nicht mit einem Blogpost.

• Wer sind die ersten zehn Nutzer, möglichst namentlich - nicht „jeder mit einem Handy“.
• Für welche eine Aufgabe stellen sie das Produkt diesen Monat ein? Eine. Keine Plattform.
• Woher kommt das Geld oder das Signal - Kartenzahlung, unterschriebener Vertrag, gebuchter Slot, qualifizierter Lead?
• Welche Einschränkung ist echt: vier Wochen, eine Entwicklerin, regulierte Nische, bestehendes CRM, Telegram-Publikum?
• Was würde uns stoppen? Wenn wir kein Abbruchkriterium nennen können, bauen wir ein Hobby, kein Experiment.

3. Fünf Filter, mit denen ich Technologie wähle

Ich wähle Tools nicht, weil sie trendig sind. Ich wähle sie, weil sie den Kontakt mit einer Solo-Entwicklerin, einem kleinen Budget und dem ersten wütenden Nutzer überleben. Jede Technologie muss durch diese Filter.

• Zeit bis zum ersten echten Nutzer. Wenn der Stack eine Woche kostet, bevor jemand klicken kann, ist er falsch für ein MVP. Langweilige Tools, die ich schon in Produktion ausliefere, schlagen ein modisches, das ich unter Deadline lernen müsste.
• Bedienbarkeit durch eine Person. Ich muss deployen, Logs lesen, ein Backup wiederherstellen und einen Key rotieren können - ohne Platform-Team. Kubernetes fällt diesen Test für fast jedes frühe Produkt.
• Einstellbar und ersetzbar. TypeScript, Postgres und React sind nicht aufregend. Es sind Sprachen, die andere gute Leute schon sprechen. Ein MVP, das nur ich erweitern kann, ist eine Geisel, kein Asset.
• Datengravitation. Die Quelle der Wahrheit gehört in eine echte Datenbank mit Migrationen ab Tag eins, wenn Nutzer und Geld im Spiel sind. Tabellen sind okay für das Experiment neben dem Produkt - nicht an der Kasse.
• Notausstieg. Ich nutze Managed Auth, gehostetes Postgres, einen Payment-Provider. Ich unterschreibe kein Fünf-Jahres-Lock-in, aus dem der Export weh tut. Vendor ist okay. Falle nicht.

4. Der Standard-Webstack, mit dem ich 2026 starten würde

Für ein typisches B2B- oder Service-MVP - Buchung, Lead-Erfassung, kleines Kundenportal, Rechner der zum Angebot wird - würde ich hier starten. Nicht weil es modisch ist. Weil ich es ausliefern, SEO-fähig machen und in sechs Monaten jemand anderen einstellen kann.

• Next.js + TypeScript + Tailwind: eine App für Marketingseiten (SEO, Server-Rendering) und Produkt-UI. Weniger Repos, ein Deploy, geteilte Typen. App Router ist okay, wenn das Team ihn schon kennt; eine funktionierende Pages-App schreibe ich nicht „der Reinheit wegen“ um.
• Postgres (oft über Supabase, Neon oder einen kleinen VPS): relationale Daten, Transaktionen und SQL, das ich um 2 Uhr nachts lesen kann. Einen Document Store hole ich nur, wenn die Form wirklich dokumentförmig ist - nicht weil „NoSQL schneller ist“.
• Auth: ein Managed Provider (Clerk, Auth.js plus bekannter IdP, oder Supabase Auth), außer das Produkt ist die Auth. Eigene Sessions in Woche eins sind, wie man Tokens leakt und das eigentliche Feature stoppt.
• Zahlungen: Stripe (oder das lokale Äquivalent, das die ersten Nutzer wirklich nutzen). Keine selbst gebaute Billing-Engine. Rechnungen können warten; eine funktionierende Abbuchung nicht.
• Hosting: Vercel für die Next.js-App, wenn der Traffic web-förmig ist und das Team Previews will; Hetzner/VPS + Docker Compose, wenn wir einen langlebigen Worker, planbare Kosten oder Data Residency brauchen. Den Abgleich habe ich separat beschrieben. MVP-Regel: eine Umgebung, die Sie verstehen, nächtliche Backups, HTTPS, eine Domain.
• E-Mail und Dateien: Resend oder eine ähnliche Transaktions-API; S3-kompatibler Speicher. Nicht „wir bauen ein Anhangs-Modul“.

5. Wann ich den Standard aufgebe

Ein Standard ist eine Startwette, keine Religion. Ich ändere ihn, wenn die Einschränkung das Produkt ist.

• Das Publikum lebt schon in Telegram: ein Bot oder Mini App kann das ganze MVP sein. Eine Website, die niemand öffnet, ist nicht „professioneller“. Es ist ein zweites leeres Zimmer.
• Die Aufgabe ist im Feld mit schlechtem Empfang: ich prüfe local-first oder PWA, keinen Native-Rewrite in Woche eins. Native ist eine Distributionsentscheidung, kein Abzeichen.
• Der Kern ist Sprache (Support, Angebote, Dokumentextraktion): ich hänge eine LLM-API hinter ein striktes Schema und einen menschlichen Prüfschritt. Ich wickle kein Chat-Widget ein und nenne es Produkt.
• Die Gründerin ist die Operatorin und Content ist das Produkt: eine schnelle Site plus ein CMS, das sie wirklich nutzt, kann ein Custom-Admin schlagen. WordPress ist noch erlaubt, wenn die Aufgabe Publizieren ist - keine Anwendung.
• Zweiseitiger Marktplatz: ich liefere trotzdem zuerst eine Seite. Angebot oder Nachfrage - was schwerer zu bekommen ist. Eine „Plattform“ mit leeren Stühlen auf beiden Seiten ist eine Landingpage mit Extra-Tabellen.

6. Was ich vor den ersten Nutzern ablehne

Der schnellste Weg, das Experiment zu verfehlen, ist, die Firma um das Experiment herum zu bauen. Diese Liste liegt neben dem Backlog.

• Microservices, Message Bus und Kubernetes. Ein Prozess, eine Datenbank, ein Deploy. Teilen, wenn ein echter Engpass oder eine echte Teamgrenze da ist - nicht wenn ein Diagramm senior wirkt.
• Ein Design System mit 80 Tokens und keinen Screens. Die drei Screens ausliefern, die Geld einsammeln. Komponenten extrahieren, wenn das dritte Copy-Paste weh tut.
• Rollen, Rechte, Audit-Logs und SSO - außer ein zahlender B2B-Käufer hat den Deal daran blockiert. Dann sind sie das MVP, keine Nebenquest.
• Eine zweite Mobile App. Responsives Web oder eine Mini App deckt die ersten hundert Nutzer in den meisten Service-Geschäften ab, die ich sehe.
• Perfekte Testabdeckung von Klebecode. Tests für Geld, Auth und die Kernaufgabe will ich. Eine Woche Mocks für ein Landing-Formular nicht.

7. Wie die ersten vier Wochen wirklich aussehen würden

Den Kalender behandle ich als Produktentscheidung. Wenn wir Wochen nicht beschreiben können, haben wir keinen Plan - wir haben einen Wunsch.

• Woche 0 (zwei Tage, nicht zwei Wochen): One-Pager. Nutzer, Aufgabe, Abbruchkriterium, Nicht-Ziele. Drei Screens skizzieren. Sich auf „fertig“ einigen: eine fremde Person schafft die Aufgabe ohne unseren Zoom-Call.
• Woche 1: vertikaler Schnitt. Domain, Deploy, Datenbank, leeres Layout, ein Happy Path in Produktion (auch wenn hässlich). Wenn wir an Tag drei nicht deployen können, lügt der Stack schon.
• Woche 2: die Aufgabe. Buchung, Angebot, Upload, Zahlung - was wir in Woche 0 genannt haben. Manuelle Abläufe hinter der Oberfläche sind erlaubt: ein Telegram-Ping an die Inhaberin ist eine Funktion, wenn es die Schleife schließt.
• Woche 3: die hässlichen Kanten. Leerzustände, Fehler, Mobile, E-Mails, Basis-Analytics (wo sie abbrechen). Kein Data Warehouse. Ein Trichter, den man lesen kann.
• Woche 4: den zehn namentlich genannten Menschen zeigen. Zuschauen. Während der Calls keine Funktion hinzufügen. Aufschreiben, was sie taten - nicht was sie sich wünschten.

8. Nach dem Launch: behalten, extrahieren oder neu schreiben

Ein gutes MVP darf leicht peinlich sein. Es darf keine Falle sein. Der Stack oben ist absichtlich langweilig: Sie können hineinwachsen. Im ersten Jahr müssen Sie selten herauswachsen.

• Behalten: die Sprache, die Datenbank, die Domainnamen im Code. Damit ist billig zu leben und teuer aufzugeben.
• Extrahieren: einen Worker, einen zweiten Service, eine echte Warteschlange - wenn eine Aufgabe langsam, gefährlich oder einem anderen Team gehört. Nicht vorher.
• Nur den Teil neu schreiben, der die falsche Lektion gelernt hat. Checkout falsch - Checkout neu. Die ganze App ein Vibe-Labyrinth: zuerst ein Menschenproblem. Jemand muss das System um 2 Uhr erklären können.

Fazit: wählen Sie den Stack, der das erste Nein überlebt

Ich würde ein MVP unglamourös bauen: eine Aufgabe, eine Datenbank, ein Deploy, Tools, die ich allein betreiben kann, und ein Datum, an dem wir weiter oder stoppen. Die „beste“ Technologie ist die, die uns von dieser Entscheidung nicht ablenkt. Next.js, TypeScript, Postgres, Managed Auth und ein Payment-Provider sind keine Persönlichkeit. Sie sind ein Weg, die knappen Wochen ins Produkt zu stecken statt in die Plattform.

Wenn Sie eine Idee, eine Deadline und Angst vor dem „falschen“ Stack haben - schreiben Sie über den Kontaktbereich. Wir können die eine Aufgabe umreißen, Nicht-Ziele benennen und einen Ausschnitt ausliefern, den Sie echten Menschen zeigen können, ohne zuerst eine Fake-Plattform zu bauen.