FALLSTUDIE · EINZELHANDEL & E-COMMERCE
Eine dreiseitige Plattform für Änderungen, produktionsreif in sechs Wochen
Ein Gründer aus den VAE kam ein Jahr nach Beginn der Entwicklung zu uns – ohne etwas vorweisen zu können, das er einem Nutzer hätte präsentieren können. Das Produkt musste drei Gruppen bedienen, die jeweils unterschiedliche Bedürfnisse hatten: Kunden, Schneider und Einzelhändler. Sechs Wochen später war es in Produktion und ging mit echten Nutzern live.
Dubai, VAE
Einzelhandel & E-Commerce
Benutzerdefinierte App
iPhone & Android, eine gemeinsame Codebasis
Kundenstatus
Gründer mit einem ins Stocken geratenen Projekt
Nach zwölf Monaten Entwicklungszeit an anderer Stelle gab es noch keine Version, die stabil genug gewesen wäre, um einen echten Kunden zu gewinnen.
Engagement
Sechswöchiger MVP-Build
Geplant als sechs wöchentliche Lieferungen, von der ersten Strategiesitzung bis zur Bereitstellung.
6 Wochen
Startschuss für ein produktionsreifes MVP
Von der ersten Strategiesitzung bis hin zu einem stabilen Build, mit dem echte Nutzer gewonnen werden konnten.
12 Monate
Zuvor ausgegeben, ohne testbares Ergebnis
Wie es um das Projekt stand, als es uns erreichte – Kernabläufe unvollendet, keine stabile Version.
3 Benutzertypen
Kunden, Schneider und Einzelhändler, eine Plattform
Drei Gruppen von Abläufen und Berechtigungen, die alle miteinander übereinstimmen müssen.
Der Kunde
Ein Gründer aus den VAE baut für das Schneiderhandwerk für Bekleidungsänderungen — kein Modelabel, sondern die Ebene darunter: die Schneider und Einzelhändler, die die Arbeit nach dem Verkauf eines Kleidungsstücks übernehmen.
Die Idee war eine einzige Plattform, auf der ein Kunde eine Änderung buchen, ein Schneider die Arbeit verwalten und ein Einzelhändler den Service unter eigenem Namen anbieten kann. Drei Gruppen, ein Produkt und ein Markt, der immer noch weitgehend über Telefonanrufe und Papierbelege läuft.
Die Situation
Die Vorgabe war nicht kompliziert zu beschreiben. Sie war jedoch aus drei verschiedenen Gründen schwierig umzusetzen.
Drei Benutzer, ein Produkt
Kunden wollen Einfachheit – buchen, nachverfolgen, wissen, was es kostet. Schneider wollen Struktur – eine übersichtliche Warteschlange und einen Zeitplan, den sie verwalten können. Einzelhändler wollen etwas, das so zuverlässig ist, dass sie es mit ihrer eigenen Marke versehen können. Jedes dieser Bedürfnisse erfordert andere Bildschirme, und ein Produkt, das zwei davon gut bedient und das dritte schlecht, funktioniert überhaupt nicht.
Ein Jahr vergangen, und nichts zu testen
Der Gründer kam nach etwa zwölf Monaten Entwicklung an anderer Stelle hinzu. Kernprozesse waren unvollständig, die Architektur hatte keine klare Struktur und es gab keine stabile Version, die man einem echten Kunden hätte präsentieren können. Die Zeit war abgelaufen und das Produkt existierte immer noch nicht – eine Ausgangslage, die die nächste Entscheidung eher riskant als vielversprechend erscheinen lässt.
Produktionsreif, kein Prototyp
Ein anklickbarer Prototyp hätte nicht geholfen. Was gebraucht wurde, war etwas Reales, auf das echte Nutzer geholt werden konnten, das den ersten Datenverkehr bewältigen und seine Kernprozesse ausführen konnte, ohne zusammenzubrechen – und das wurde in sechs Wochen benötigt, nicht in sechs Monaten. Diese Einschränkung prägte jede darauffolgende Entscheidung.
Wie wir an die Sache herangegangen sind
Sechs Wochen sind keine Frage von schnellerem Arbeiten. Es ist eine Frage der Entscheidung, noch vor dem Schreiben von Code festzulegen, was nicht in der ersten Version enthalten sein wird – und diese Entscheidung dann nicht mehr zu hinterfragen.
1
Wir haben die erste Zeit mit Recherche verbracht, nicht mit dem Aufbauen
Noch vor der ersten Zeile Code haben wir uns durch das gearbeitet, was bereits vorhanden war: Dienste, die jene Teile des Produkts abdecken, die nicht dessen eigentlichen Kernwert ausmachen; Integrationen, die die Entwicklungszeit verkürzen statt verlängern; und Tools, die sich nahtlos in die Haupt-Workflows einfügen, anstatt sie zu blockieren.
Alles, was ein bewährter Dienst bereits gelöst hatte, haben wir genutzt. Dadurch blieb die Entwicklungszeit für den Teil übrig, den kein anderer liefern kann – die Art und Weise, wie dieses spezielle, dreiseitige Produkt tatsächlich funktioniert.
2
Wir reduzieren jedes Feature auf seinen wesentlichen Zweck
Komplexität ist der übliche Grund, warum Produkte zu spät auf den Markt kommen. Daher wurde jede Funktion denselben drei Fragen unterzogen: Dient sie direkt dem, was das MVP beweisen muss, kann der Ablauf einfacher sein als dieser und wird sie für die ersten echten Kunden benötigt?
Die meisten Dinge haben das nicht überstanden, und das Produkt war dadurch besser – eine kleinere Oberfläche, klarere Abläufe und Bildschirme, die ein Erstnutzer verstehen kann, ohne angelernt werden zu müssen.
3
Wir haben auf unserem eigenen Delivery-Framework aufgebaut
Die repetitiven Teile eines Builds – Einrichtung der Umgebung, Standards, Prüfungen, Bereitstellung – laufen auf einem Framework, das unser Team projektübergreifend verfeinert hat. Es erledigt die Arbeit, die sonst die erste Woche in Anspruch nehmen würde und nichts hervorbringt, was ein Benutzer sehen kann.
Die sechs Wochen wurden dann als sechs wöchentliche Lieferergebnisse geplant, sodass zu keinem Zeitpunkt die Frage bestand, was als Nächstes gebaut werden soll, oder eine Woche endete, ohne dass etwas fertiggestellt wurde.
Was wir gebaut haben
Sechs Wochen, geplant als sechs Ergebnisse.
WOCHE 1
Strategie, Forschung und Architektur
Erarbeitung der Vision des Gründers und dessen, was das MVP beweisen musste
Bereinigung des Scopes auf eine schlanke Feature-Liste
Mapping der User Journeys für alle drei Seiten
Auswahl der Drittanbietersysteme
WOCHEN 2–3
Die Kernflüsse
Benutzer-Onboarding für jede der drei Rollen
Vom Kunden zum Schneider – Anfrage, Angebot, Annahme
Vom Schneider zum Einzelhändler – die Arbeit hinter dem eigenen Angebot des Einzelhändlers
End-to-End-Buchung und Änderungsverfolgung
WOCHEN 4–5
Schnittstellen- und Funktionstests
Layouts, Schaltflächen und Navigation wurden an die realen Abläufe angepasst
Ladeverhalten von Seiten
Fehlerbehandlung für Fälle, auf die ein echter Benutzer stoßen wird
WOCHE 6
Testen und Deployment
Qualitätssicherung über alle drei Rollen hinweg
Tests auf echten Geräten
Stabilitätsprüfungen unter Anfangslast
Bereitstellung und Vorbereitung auf das Onboarding echter Nutzer
„Produktionsreif“: kein Mockup, keine frühe Alpha, keine halbfertige Idee. Eine stabile Plattform, die echte Nutzer an Bord holen, ersten Datenverkehr bewältigen, ihre Kernprozesse ordnungsgemäß ausführen und die nächste Arbeitsphase tragen kann, ohne neu geschrieben werden zu müssen.
Die Recherchewoche hat uns die anderen fünf erkauft. Jede Funktion, die an einen bewährten Drittanbieter übergeben wurde, war eine Funktion, die wir nicht bauen, nicht debuggen und nicht warten mussten – so waren sechs Wochen möglich, ohne Abstriche bei der Qualität zu machen.
Messung per Kamera: ein geführter Körperscan als Alternative zur manuellen Eingabe. Das Gesicht wird unkenntlich gemacht.
Die Kundin oder der Kunde zeigt die gewünschte Passform auf die einfachste Art und Weise: anhand von Fotos eines abgesteckten Kleidungsstücks, eines Kleidungsstücks, das bereits perfekt passt, oder anhand von Maßen.
Die Ergebnisse
Ein produktionsreifes MVP in sechs Wochen
Nachdem zwölf Monate an anderer Stelle keine Version hervorgebracht hatten, die getestet werden konnte.
Echte Benutzer könnten an Bord geholt werden
Kein Demokonto und kein Staging-Link – die Plattform war bereit, echte Kunden aufzunehmen.
Alle drei Seiten durchgehend von Ende zu Ende verlaufend
Abläufe für Kunden, Schneider und Händler arbeiten zusammen, anstatt drei separate Hälften einer Idee zu sein.
Ein Fundament, kein Wegwerfprodukt
So gebaut, dass die nächste Phase darauf aufbaut, anstatt sie zu ersetzen – was genau den Unterschied zwischen einem MVP und einem Prototyp ausmacht.
Etwas, das man Investoren präsentieren kann
Ein funktionierendes Produkt im Raum verändert dieses Gespräch mehr als jede Präsentation.
Der Gründer besitzt den Code
Code, IP und Infrastruktur, in vollem Umfang. Kein Lock-in und nichts, was später verhandelt werden muss.
Die App sieht fantastisch aus. Ich schätze Ihre Arbeit und wie schnell Sie sie erledigt haben. Ich freue mich darauf, an einem anderen Teil zu arbeiten.
Gründer der Änderungsschneiderei-Plattform in den VAE
Wenn Sie etwas Ähnliches bauen
Sehr wenig von dem, was dieses Projekt so schwierig gemacht hat, ist spezifisch für Änderungen. Wenn einer dieser Punkte auf Ihre Situation zutrifft, handelt es sich um dasselbe Problem, nur mit anderen Benutzeroberflächen.
Ein Build, der bei jemand anderem ins Stocken geraten ist
Monate vorbei, keine stabile Version und die Entscheidung steht an, ob man es reparieren oder richtig neu anfangen soll.
Ein Marktplatz mit mehr als zwei Seiten
Jedes Produkt, bei dem eine dritte Rolle – ein Betreiber, ein Vermittler, ein Franchiseunternehmen, eine Klinik – zwischen Angebot und Nachfrage steht.
Ein Dienstleistungsunternehmen, das sich von Telefonanrufen und Papier verabschiedet
Buchung, Angebotserstellung, Sendungsverfolgung und Übergabe in einer Branche, die seit jeher auf Nachrichten basiert.
Eine erste Version, die echt sein muss
Etwas, worauf Nutzer gesetzt werden können und was Investoren eröffnen können – zu einem Datum, das Sie bereits zugesagt haben.
Fragen, die uns gestellt werden
Bevor Sie so etwas bauen
Was kostet der laufende Betrieb nach der Fertigstellung?
Die laufenden Kosten setzen sich aus vier Bereichen zusammen: Hosting- und Datenbankauslastung, den Drittanbieterdiensten, von denen das Produkt abhängt, den Gebühren für App-Stores und Compliance sowie der Geschwindigkeit, mit der Sie neue Funktionen veröffentlichen. Die Nutzung bewährter Drittanbieterdienste für nicht-essenzielle Funktionen – wie wir es hier getan haben – reduziert den Aufwand für Entwicklung und Wartung. Wir kalkulieren alle vier Bereiche gemeinsam mit Ihnen vor der Entwicklung, nicht erst danach.
Können Sie ein Projekt übernehmen, das eine andere Agentur begonnen hat?
Ja, und das ist einer der häufigsten Gründe, warum Gründer zu uns kommen. Wir ermitteln zunächst, was es wert ist, behalten zu werden, und was schneller neu gebaut werden kann, und vereinbaren dann einen überschaubaren Rahmen. In diesem Fall war der schnellste Weg ein sauberer Neuaufbau mit einem schlanken Funktionsumfang, anstatt eine unvollständige Architektur zu reparieren.
Wie kann ein MVP in sechs Wochen produktionsreif sein?
Nicht indem man schneller arbeitet. Sondern indem man noch vor dem Schreiben der ersten Zeile Code entscheidet, was nicht in der ersten Version enthalten sein wird – und indem man für alles, was nicht den eigentlichen Kernwert des Produkts ausmacht, auf bewährte Drittanbieter-Dienste setzt. Die sechs Wochen hier wurden als sechs wöchentliche Meilensteine geplant, sodass zu keinem Zeitpunkt die Frage im Raum stand, was als Nächstes zu entwickeln ist.
Was bedeutet "produktionsbereit" eigentlich?
Das bedeutet, dass echte Nutzer an Bord geholt werden können. Kein anklickbarer Mockup und keine frühe Alpha-Version – sondern ein stabiler Build, der den ersten Traffic bewältigt, seine Kernprozesse durchgängig ausführt und die nächste Arbeitsphase tragen kann, ohne neu geschrieben werden zu müssen.
Was passiert nach dem Launch?
Ein MVP ist der Anfang der Erkenntnisentwicklung, nicht das Ende des Projekts. Die meisten Kunden setzen die Zusammenarbeit im Rahmen einer monatlichen Partnerschaft fort, bei der neue Funktionen in einem festen Zyklus veröffentlicht werden – jeder Sprint wird vor Beginn genau definiert und abgestimmt, geprägt von den Erkenntnissen aus der realen Nutzung.
Bauen Sie etwas Ähnliches?
Schreib uns auf WhatsApp – wir sagen dir, ob wir das richtige Team dafür sind und was die erste Phase beinhalten müsste.
Mehr von unserer Arbeit
Andere Builds in diesem Bereich
Fallstudie · Wellness & Healthtech
Ein GCC-Wellness-Marktplatz, in acht Wochen in beiden App-Stores live
Fallstudie · Wellness & Healthtech
