Was gehört wirklich ins MVP? Die 4-8-24 Methode für App-Entwicklung

Das Feature-Creep-Monster

Kennst du das? Du startest mit einer simplen App-Idee. "Eine App, die X macht." Klar, fokussiert, machbar.

Drei Meetings später: "Aber wir brauchen auch Y! Und was ist mit Z? Und die Konkurrenz hat Feature W..."

Plötzlich ist dein MVP ein 6-Monats-Projekt. Willkommen beim Feature-Creep-Monster.

Ich habe es dutzende Male erlebt, bei Kundenprojekten und bei meinen eigenen Ideen. Die Lösung ist nicht, "nein" zu sagen (obwohl das hilft). Die Lösung ist ein System, das dich zwingt, fokussiert zu bleiben.

Die 4-8-24 Methode

Diese Methode habe ich ursprünglich für Prototypen und Proof-of-Concepts entwickelt. Mittlerweile nutze ich sie für fast jedes neue Projekt. Sie funktioniert so:

Phase 1: Konzept beweisen (4 Stunden)

In den ersten vier Stunden geht es um eine einzige Frage: Funktioniert das Konzept?

Die einzige Person, die du überzeugen musst, bist du selbst. Am Ende dieser Phase solltest du wissen:

• Ist die Kernidee technisch umsetzbar?
• Fühlt sich das Konzept richtig an?
• Bin ich excited genug, um weiterzumachen?

Was du nicht brauchst:

• Schönes Design
• Sauberen Code
• Funktionierende APIs (Mock-Daten reichen)
• Irgendetwas, das du jemandem zeigen könntest

Wenn du nach vier Stunden nicht überzeugt bist, dass das Projekt sich lohnt: Stopp. Versuch eine andere Idee oder einen anderen Ansatz. Lieber jetzt vier Stunden "verlieren" als vier Monate.

Phase 2: Zeigbares MVP (8 Stunden)

Jetzt baust du etwas, das du echten Menschen zeigen kannst. Der Fokus liegt auf drei Dingen:

1. Die Kernfeatures, die du realistisch in dieser Zeit schaffen kannst
2. Eine polierte UI, die Lust macht, die App zu benutzen
3. Gerade genug Funktionalität, um eine Demo zu zeigen

Hier kommt der wichtigste Trick: Dinge müssen nur funktionieren wirken.

Das nennt sich "Wizard of Oz"-Methode. Die App sieht aus wie Magie, aber hinter den Kulissen ziehst du die Fäden. Mock-Daten, hardgecodete Responses, manuelle Prozesse, alles erlaubt.

Diese Version sollte dir noch peinlich sein. Das ist ein gutes Zeichen. Es bedeutet, du gehst früh genug zu Nutzern.

Phase 3: Launch-Ready (24 Stunden)

Die letzten 24 Stunden verteilst du auf etwa drei Tage (8 Stunden pro Tag). Jetzt wird's ernst:

• Polishing: Die 80%, die du schon hast, auf 95% bringen
• Store-Vorbereitung: Screenshots, Beschreibung, App-Icon
• Launch-Strategie: Wo postest du zuerst? Wen informierst du?
• Die letzten 20% Features, die den Unterschied machen

Am Ende dieser Phase hast du eine App, die du Nutzern in die Hand drücken und allein lassen kannst. Nicht perfekt, aber funktional.

Die Mathe dahinter

Lass mich dir zeigen, warum diese Methode funktioniert:

Je später du Feedback bekommst, desto teurer sind Änderungen. Bei einem 6-Monats-Projekt kann eine falsche Grundannahme bedeuten, dass du von vorne anfangen musst. Bei der 4-8-24 Methode kostet dich das maximal 36 Stunden.

Was gehört ins MVP, was nicht?

Hier ist meine Checkliste:

✅ Muss ins MVP

• Die eine Kernfunktion, für die User die App öffnen
• Funktionierendes Onboarding (simpel, aber nicht kaputt)
• Grundlegende Navigation (User müssen finden, was sie suchen)
• Eine Monetarisierungsoption (auch wenn du sie erstmal nicht aktivierst)

❌ Gehört (noch) nicht ins MVP

• Social Features (Sharing, Leaderboards, Kommentare)
• Account-System (wenn es ohne geht)
• Analytics-Dashboard
• Push-Notifications
• Mehrere Zahlungsoptionen
• Dark Mode (ja, wirklich)
• "Nice to have"-Features aller Art

🤔 Fallabhängig

• Offline-Funktionalität
• Multi-Language Support
• Fortgeschrittene Personalisierung

Die Faustregel: Wenn ein Feature nicht direkt zur Kernfunktion beiträgt, kommt es in Version 1.1.

Die "peinlich genug"-Regel

Reid Hoffman hat das perfekt formuliert:

"If you're not embarrassed by the first version of your product, you've launched too late."

Ich wende das konkret an:

Wenn ich mir mein MVP anschaue und denke "Das ist zu einfach, das kann ich noch nicht zeigen", dann ist es wahrscheinlich ready.

Wenn ich denke "Das ist richtig gut, das kann ich zeigen", habe ich wahrscheinlich zu lange gewartet.

Die Peinlichkeit ist ein Feature, kein Bug. Sie bedeutet, dass du echtes Feedback bekommst, bevor du zu viel investiert hast.

Real Talk: Wo die Methode an Grenzen stößt

Die 4-8-24 Methode funktioniert nicht für alles:

• Komplexe B2B-Software mit Enterprise-Anforderungen braucht mehr Vorlaufzeit
• Hardware-Integration lässt sich nicht in 36 Stunden mocken
• Regulierte Branchen (Healthcare, Finance) haben Compliance-Anforderungen, die Zeit kosten
• Spiele mit komplexer Game-Loop brauchen mehr Iteration

Aber für die meisten Consumer-Apps, SaaS-Tools und Utility-Apps ist sie perfekt.

Wie ich die Methode bei Kundenprojekten einsetze

Bei Robocitrus nutze ich eine abgewandelte Version für Kundenprojekte:

Woche 1: Discovery und Konzept (entspricht Phase 1)

• Was ist das Kernproblem?
• Wer sind die User?
• Was ist die einfachste Lösung?

Woche 2-3: Klickbarer Prototyp (entspricht Phase 2)

• High-Fidelity Mockups
• Interaktiver Prototyp zum Testen
• Erste User-Tests

Woche 4-8: MVP-Development (entspricht Phase 3, skaliert)

• Echte Implementierung
• Iterationen basierend auf Feedback
• Store-Submission

Der Unterschied zu klassischen Agenturen: Nach 2-3 Wochen hast du etwas Testbares in der Hand, nicht nur Spezifikationsdokumente.

Fazit: Weniger ist mehr (zuerst)

Dein MVP muss nicht alles können. Es muss eine Sache gut genug können, dass User wiederkommen.

Alles andere ist Scope Creep, der dich Zeit, Geld und vor allem Momentum kostet.

Die 4-8-24 Methode zwingt dich, diese eine Sache zu identifizieren und darauf zu fokussieren. Nicht weil die anderen Features unwichtig sind, sondern weil du erst wissen musst, ob überhaupt jemand deine App will, bevor du sie ausbaust.

Also: Was ist die eine Funktion, die deine App haben muss? Bau die. In 36 Stunden. Dann frag deine User, was als nächstes kommt.

Du fragst dich, wie lange App-Entwicklung wirklich dauert? Die Antwort hängt stark davon ab, wie gut du dein MVP definierst.