--- title: "Was gehört wirklich ins MVP? Die 4-8-24 Methode für App-Entwicklung" description: "Wie du in 36 Stunden von der Idee zum launchbaren MVP kommst. Die 4-8-24 Methode für effiziente App-Entwicklung ohne Feature-Creep." canonical_url: "https://robocitrus.com/blog/was-gehoert-wirklich-ins-mvp" last_updated: "2026-07-19T00:14:31.405Z" --- ## 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:
Ohne Methode Mit 4-8-24
3-6 Monate bis v1.0 36 Stunden bis MVP
Feedback nach Monaten Feedback nach Tagen
Große Änderungen = teuer Änderungen = nächste Iteration
Emotionale Bindung ans Produkt Daten-getriebene Entscheidungen
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](/blog/wie-lange-dauert-die-app-entwicklung-wirklich)? Die Antwort hängt stark davon ab, wie gut du dein MVP definierst.