MVP in zwei Wochen bauen: Was ich bei quik connect gelernt habe

Ein MVP in zwei Wochen zu bauen gelingt nach meiner Erfahrung, wenn du dich auf eine einzige Frage konzentrierst: Welche Annahme muss wahr sein, damit dein Produkt funktioniert? Dann baust du nur das, was diese Annahme testet, mit No-Code oder KI-Werkzeugen, und bringst es so schnell wie möglich zu echten Nutzern. Ein MVP ist für mich ein Experiment mit klarem Ergebnis.

Ich habe quik connect, ein persönliches CRM als iOS-App, in zwei Wochen gebaut: Website, App und Werbegrafiken, allein mit Claude Code, im Urlaub. Am ersten Tag im App Store kamen 15 neue Nutzer, ohne einen Euro Werbung. Hier teile ich, was dabei funktioniert und was mich überrascht hat. Ein Erfahrungsbericht aus einem Projekt, kein Rezept.

Was ein MVP beweisen muss

Der Begriff MVP steht für Minimum Viable Product. Eric Ries hat ihn mit „The Lean Startup“ bekannt gemacht: bauen, messen, lernen, in möglichst kurzen Schleifen. Der wichtigste Teil davon ist für mich das Lernen. Ein MVP, aus dem du nichts lernst, war nur ein kleines Produkt.

Ein MVP ist fertig, sobald es eine Frage beantworten kann. Wie viele Funktionen es hat, spielt dafür keine Rolle.

Die Frage hinter einem MVP ist meistens eine dieser drei:

• Wert: Erleben Nutzer den Kernnutzen so stark, dass sie wiederkommen?
• Zahlungsbereitschaft: Zahlen Menschen für diesen Nutzen, und wie viel?
• Erreichbarkeit: Findest du die Zielgruppe über einen Kanal, der bezahlbar ist?

Wähle eine davon als Hauptfrage. Alles, was sie nicht beantwortet, ist für die nächsten zwei Wochen Ablenkung.

Die riskanteste Annahme finden

Schreib alle Annahmen auf, die wahr sein müssen, damit dein Geschäft funktioniert. Markiere dann die, bei der du am unsichersten bist und die alles zum Einsturz bringt, wenn sie falsch ist. Das ist deine riskanteste Annahme, und genau die testet dein MVP.

Angenommen, du willst Physiotherapiepraxen ein Tool anbieten, das Patienten automatisch an ihre Übungen erinnert. Deine Annahmen: Praxen wollen das. Patienten machen mit. Praxen zahlen 39 € im Monat. Am unsichersten ist vermutlich, ob Patienten die Erinnerungen wirklich nutzen. Also testet dein MVP genau das, mit drei Praxen und ihren Patienten. Eine Abrechnung, ein Admin-Bereich oder eine App im Store sind dafür noch nicht nötig.

Den Scope radikal schneiden

MVPs dauern meist deshalb Monate, weil der Umfang wächst. An der Technik liegt es selten. Jede Funktion, die „schnell noch“ dazukommt, zieht Tests, Sonderfälle und Abhängigkeiten nach sich.

Ein Versprechen, eine Zielgruppe, ein Pfad

Mir hilft es, das Produkt auf drei Festlegungen zu reduzieren:

1. Ein Versprechen in einem Satz. Bei quik connect war es sinngemäß: Die App zeigt dir jeden Morgen, mit wem du in Kontakt bleiben solltest.
2. Eine Zielgruppe. Kein „alle, die ein Netzwerk haben“. Eine konkrete Person mit einem konkreten Alltag.
3. Ein Nutzungspfad. Der Weg vom ersten Öffnen bis zum Moment, in dem der Nutzer den Nutzen spürt. Diesen Moment nennt man Aha-Moment. Alles außerhalb dieses Pfads fliegt raus.

Die Muss-Später-Nie-Liste

Schreib jede Funktion, die dir einfällt, auf eine Liste und sortiere sie in drei Spalten:

Muss	Später	Nie (vorerst)
Ohne diese Funktion funktioniert der Kernpfad nicht	Macht das Produkt besser, testet aber nicht deine Annahme	Fühlt sich wichtig an, hilft aber niemandem in den ersten Wochen
Beispiel: Kontakt anlegen, tägliche Erinnerung	Beispiel: Import aus dem Adressbuch, Statistiken	Beispiel: Team-Funktion, Web-Version, Integrationen

Meine Faustregel: In die Spalte „Muss“ kommen höchstens drei bis fünf Punkte. Sind es mehr, ist das Versprechen vermutlich noch zu breit.

Manuell statt automatisch

Viele Funktionen musst du am Anfang gar nicht bauen, du kannst sie von Hand erledigen. Statt einer automatischen Auswertung schickst du jedem Nutzer selbst eine Zusammenfassung. Statt eines Bezahlsystems verschickst du eine Rechnung. Das skaliert nicht, und das ist in Ordnung. Du lernst dabei mehr über deine Nutzer, als eine Automatisierung dir verraten würde.

MVP in zwei Wochen: mein Plan

So würde ich zwei Wochen aufteilen, allein oder zu zweit:

Zeitraum	Fokus	Ergebnis
Tag 1 bis 2	Annahme, Versprechen, Muss-Liste, Skizze des Kernpfads	Ein Dokument auf einer Seite
Tag 3 bis 7	Kernpfad bauen	Ein Nutzer kann den Aha-Moment erleben
Tag 8 bis 10	Landingpage, Texte, Grafiken, Tracking	Menschen können sich anmelden, du siehst, was sie tun
Tag 11 bis 13	Die letzten 20 %: Sonderfälle, Fehler, Prüfprozesse	Das Produkt bricht nicht beim ersten echten Nutzer
Tag 14	Launch bei den ersten Nutzern	Echte Daten statt Vermutungen

Zwei Dinge fallen auf: Der Bau des Kernpfads bekommt nur fünf Tage. Und Landingpage und Tracking stehen im Plan, weil du ohne sie nach dem Launch nicht weißt, was passiert ist.

Werkzeuge: No-Code, KI oder beides

Welches Werkzeug passt, hängt davon ab, was dein Produkt tun muss.

Ansatz	Gut geeignet für	Grenzen
No-Code	Formulare, Datenbanken, interne Abläufe, Marktplätze im Kleinen	Eigene Logik und Apps im Store werden schnell umständlich
KI-Werkzeuge wie Claude Code	Echte Apps und Websites mit eigener Logik, ohne Entwicklerteam	Du musst verstehen, was gebaut wird, vor allem bei Daten und Sicherheit
Manuell (Concierge)	Services, bei denen du den Nutzen erst von Hand lieferst	Nur für wenige Nutzer machbar

Ich habe 2023 neben dem Studium zwei No-Code-Plattformen aufgebaut, die zusammen über 300 Nutzer hatten. No-Code war damals für mich der schnellste Weg, etwas Echtes in die Hände von Menschen zu bekommen. Bei quik connect bin ich einen Schritt weiter gegangen und habe die App mit Claude Code gebaut. Wie dieser Workflow aussieht, beschreibe ich in Claude Code für Gründer. Wenn dein ganzes Startup auf KI aufbaut, lohnt sich der Artikel Ein Startup mit KI gründen.

Was ich dabei gelernt habe: KI ändert das Tempo, nicht das Verstehen. Ein Feature, für das ich früher Tage gebraucht hätte, steht heute nach einem guten Prompt in Minuten. Wo du Daten speicherst, was verschlüsselt sein muss und welche Architektur hält, musst du trotzdem selbst entscheiden.

Was ich bei quik connect gelernt habe

Drei Learnings, die ich auf andere MVPs übertragen würde.

Die letzten 20 % fressen die meiste Energie

Die ersten 80 % liefen fast von allein. Das Grundgerüst stand schnell, alles fühlte sich nach Fortschritt an. Dann kamen Sonderfälle, Übersetzungen und der Prüfprozess im App Store. Für diese letzten Details brauchte ich mehr Energie als für den ganzen Rest. Deshalb stehen sie in meinem Zwei-Wochen-Plan als eigener Block.

Plattformzugang ist der größte Hebel

Die 15 Nutzer am ersten Tag kamen ohne Werbung, weil der App Store die Verteilung übernommen hat. Mit einer eigenen Website hätte ich für dieselbe Reichweite vermutlich Monate gebraucht. Wenn du dein MVP planst, frag dich, auf welcher Plattform deine Zielgruppe schon sucht. Mehr dazu steht in Distribution vor Produkt.

Einfach starten

Ich dachte, eine iOS-App zu veröffentlichen sei kompliziert. Der Prozess war gut erklärt, die Hürde lag in meinem Kopf. Wer wartet, bis er sich bereit fühlt, startet oft nie. Meine ausführlichen Notizen dazu stehen im Originalartikel Webseite, App und Werbegrafiken in 2 Wochen mit KI.

Nach den zwei Wochen: messen und entscheiden

Mit dem Launch beginnt das Experiment. Jetzt brauchst du Zahlen für deine Hauptfrage. Ich würde sie vor dem Launch festlegen, sonst redest du dir hinterher jedes Ergebnis schön.

• Aktivierung: Wie viele neue Nutzer erleben den Aha-Moment in der ersten Sitzung?
• Retention: Wie viele kommen nach einer und nach zwei Wochen wieder?
• Zahlungsbereitschaft: Wie viele nehmen ein bezahltes Angebot an, wenn du es ihnen machst?
• Qualitatives Feedback: Was sagen Nutzer, wenn du sie fragst, was ihnen fehlen würde?

Angenommen, 80 Menschen melden sich in der ersten Woche an. 48 erleben den Aha-Moment, das sind 60 %. Nach zwei Wochen nutzen noch 20 das Produkt regelmäßig, also 25 % aller Anmeldungen. Ob das gut ist, hängt von deinem vorher festgelegten Ziel ab. Wichtig ist der Verlauf: Bleibt die Gruppe der Wiederkehrer stabil, hast du ein Signal. Wie du solche Signale sauber deutest, steht in Product-Market-Fit erkennen.

Nach der Auswertung gibt es drei mögliche Entscheidungen: weiterbauen, die Annahme anpassen und erneut testen oder die Idee weglegen. Alle drei sind für mich ein Erfolg, wenn du sie auf Basis von Daten triffst.

Typische Fehler beim MVP

• Zu viel bauen. Aus meiner Sicht das häufigste Problem. Jede zusätzliche Funktion verlängert die Zeit bis zur ersten Antwort.
• Keine Hauptfrage. Wer nicht weiß, was das MVP beweisen soll, kann das Ergebnis nicht deuten.
• Kein Tracking. Ohne Messung bleibt nach dem Launch nur das Bauchgefühl.
• Nur Freunde als Tester. Freunde sind nett zu dir. Echte Nutzer sagen dir, was nicht funktioniert.
• Die letzten 20 % unterschätzen. Wer sie nicht einplant, verschiebt den Launch Woche um Woche.

Fazit

Ein MVP in zwei Wochen verlangt aus meiner Sicht vor allem Disziplin beim Weglassen. Du definierst die riskanteste Annahme, schneidest den Scope auf einen Kernpfad, nutzt No-Code oder KI für Tempo und planst die letzten 20 % ehrlich ein. Danach entscheiden Daten, wie es weitergeht. Bevor du baust, sollte die Idee selbst geprüft sein, dabei hilft dir Eine gute Startup-Idee finden.

Mein Vorschlag für deinen nächsten Schritt: Schreib heute deine riskanteste Annahme in einen Satz und erstelle deine Muss-Später-Nie-Liste mit höchstens fünf Muss-Punkten. Wie ich selbst neue Produkte baue und teste, teile ich in den Unternehmer Thoughts.