Wie lange dauert ein MVP, und welches Team braucht es?

Das sind fünf Produkte, die wir zwischen 2021 und 2023 gebaut haben, mit der Zeit und dem Team, wie jede Fallstudie sie festhält. Auf sie greifen wir zurück, wenn ein Gründungsteam fragt, wie lange es bei ihm dauern wird, und die ehrliche Antwort beginnt damit, um welche Art von Produkt es sich handelt.

Fünf Builds im Vergleich

Produkt	Was es ist	Zeit	Team	Was es länger oder kürzer gemacht hat
SWANS	Buchungsplattform für Beauty-Talente, nur auf Einladung	2 Monate, vom Briefing zum startbereiten MVP	2 Full-Stack-Engineers	Kürzer: ein Buchungsablauf, Stripe für die Zahlung, Airtable als Datenbank, sodass niemand eine Datenschicht von Grund auf bauen musste
Flur	Creator-Plattform nach dem Vorbild von Patreon, auf NFTs	8 Wochen bis live, in Iterationen von 3 und 5 Wochen	2 Entwickler, 1 Delivery Manager	Kürzer: die Regel, dass keine Iteration länger als ein paar Wochen dauert. Die zweite baute nach dem Launch neu, wie Claims funktionierten
AnyoneGroup	Zweiseitiger Marktplatz für Gruppenrabatte	6 Monate, vom klickbaren Prototyp zum Launch	Ein CTO und 3 Entwickler	Länger: Käufer- und Verkäuferseite und ein Admin-Bereich, Abbuchung nur, wenn eine Gruppe voll wird, KYC für Verkäufer, Shopify-Import, Steuern, Versand und Rechnungsstellung
CachePay	Payment-Gateway von Krypto zu Fiat	6 Monate, Okt. 2022 bis Apr. 2023	3 Entwickler, 1 Delivery Manager	Länger: Seiten für Verbraucher, Händler und Admin, KYC für Händler, Liquidität und Verwahrung über B2C2 und Fireblocks, ein WooCommerce-Plugin
OccamStrata	Strata-Verwaltung auf Airtable	3 Monate	1 Automation Engineer	Ein internes System auf einer Plattform. Die Zeit ging in das Datenmodell, eine Migration aus einem veralteten CRM und eine Synchronisierung in beide Richtungen

Was die Tabelle zeigt

Die Teamgröße folgt eher der Zahl der Seiten als der Länge der Feature-Liste. Zwei Personen haben SWANS in zwei Monaten ausgeliefert, weil das Produkt einen Hauptweg hatte: Eine Kundin findet eine Künstlerin, prüft die Verfügbarkeit, bucht und bezahlt. AnyoneGroup hatte eine Käufer- und eine Verkäuferseite und einen Admin-Bereich, CachePay Seiten für Verbraucher, Händler und Admin, und jede davon ist ein eigenes Dashboard, mit eigenen Berechtigungen und einer eigenen Vorstellung davon, was eine Bestellung ist. Dafür brauchte es die sechs Monate und die dritte und vierte Person.

Geld und die Systeme anderer bremsen. SWANS nahm Zahlungen mit Stripe von der Buchung bis zum Checkout entgegen und blieb bei zwei Monaten. Bei AnyoneGroup wurden Zahlungen autorisiert, wenn ein Käufer beitrat, und erst eingezogen, wenn die Gruppe ihr Minimum bis zur Frist erreichte, mit Onboarding und KYC für Verkäufer dahinter. Die Händler von CachePay bekamen für Krypto-Verkäufe Fiat ausgezahlt, über zwei Drittanbieter, und wir saßen bis zum Launch in den technischen Calls mit diesen Anbietern. Ihre Zeitpläne waren nicht unsere.

Ein Prototyp allein macht einen Build nicht kurz. AnyoneGroup begann mit einem klickbaren Prototyp und schriftlichen Beschreibungen, was alles tun sollte, und brauchte trotzdem sechs Monate, weil ein Prototyp klärt, welche Screens es gibt, aber nicht, wie sich die Zahlung bei einer vollen Gruppe, Steuern über Rechtsräume hinweg oder die Freigabe von Verkäufern verhalten. Was ein mit Nutzern getesteter Prototyp leistet: Er verlegt das Lernen vor den Build. Flur zeigt, was Lernen nach dem Launch kostet: Die erste Iteration ließ jeden ein Sammlerstück claimen, Fan oder nicht, und die zweite Iteration, fünf Wochen, ersetzte den Claim-Mechanismus durch Spenden. Ein Test mit Nutzern hätte das vielleicht gefunden; den anderen Grund, die API-Preise von Twitter, hätte kein Prototyp gefunden.

Wie die fünf zum Sprint und zu den zwei Builds passen

Jedes Projekt, das wir heute beginnen, startet mit einem zweiwöchigen Produkt-Sprint: Konzept, ein Design-Sprint, ein klickbarer, mit Nutzern getesteter Prototyp und die Architektur. Am Ende stehen ein vereinbarter Umfang und ein Festpreisangebot. Dann einer von zwei Builds. Ein schneller Build von unter zwei Monaten, wenn der Sprint das Was und das Wie klärt. Ein explorativer Build von zwei bis vier Monaten, wenn das Produkt noch entdeckt werden muss: ein neuer Markt, eine mehrseitige Plattform, Zahlungen oder Regulierung.

Im Rückblick durch diesen Prozess gelesen:

• SWANS ist ein schneller Build. Ein klares Briefing, ein Ablauf, zwei Monate.
• Flur sind zwei kurze Builds hintereinander, und der zweite tat, was ein explorativer Build mit Absicht tut: Er beantwortete eine offene Frage mit dem, was echte Nutzer taten.
• OccamStrata liegt zwischen beiden. Die Arbeitssitzungen mit den Beteiligten und das Schema, das gezeichnet wurde, bevor irgendein Werkzeug angefasst wurde, erledigten die Arbeit eines Sprints; die Migration und die Synchronisierung machten es länger als einen schnellen Build.
• AnyoneGroup und CachePay sind explorative Builds: mehrseitig, mit Zahlungen und Compliance. Mit sechs Monaten liefen beide über die vier hinaus, die ein explorativer Build heute vorsieht. Zur Aufgabe eines Sprints gehört, das vor dem Build herauszufinden, indem der Umfang auf das gekürzt wird, was der Launch braucht, wie es die Gründer von CachePay mit uns durch strikte Priorisierung taten, oder indem klar gesagt wird, dass der Build länger dauern wird.

Was die Zeit bestimmt

Die Fragen, die bei uns die Dauer bestimmt haben:

• Wie viele Seiten? Jede weitere Partei (Käufer, Verkäufer, Händler, Admin) bringt ein eigenes Dashboard, eigene Berechtigungen und ein eigenes Onboarding mit.
• Tut das Geld etwas Ungewöhnliches? Eine Kartenzahlung annehmen geht schnell. Unter einer Bedingung belasten, Auszahlungen aufteilen oder in einer anderen Währung abrechnen nicht.
• Gibt es Compliance? KYC, Steuern und Rechnungsstellung bringen jeweils einen Anbieter, eine Prüfung und Sonderfälle mit.
• Von wessen Systemen hängen Sie ab? Shopify bei AnyoneGroup, das 5.000 Produkte hereinbrachte; WooCommerce bei CachePay; das alte CRM bei OccamStrata. Jedes hat eigene Grenzen und einen eigenen Zeitplan.
• Gibt es bestehende Daten? Datensätze aus einem System zu holen, das noch läuft, ist Arbeit, die ein neues Produkt nicht hat.
• Hat ein Nutzer es gesehen? Ein vor dem Build getesteter Prototyp beantwortet Fragen, die sonst nach dem Launch eine Iteration kosten würden.

Was unsere Projekte verkürzt hat, war das Gegenteil: ein Hauptablauf, ein für die Frist gewählter Stack (Airtable bei SWANS und OccamStrata) und ein Umfang, gekürzt auf das, was der Launch braucht.

Welches Team es braucht

Bei diesen fünf haben ein bis vier Personen jedes Produkt gebaut: ein Automation Engineer für ein internes System auf einer Plattform, zwei Full-Stack-Engineers für ein Produkt mit einem Ablauf, drei Entwickler und jemand, der die Entscheidungen verantwortet, ein CTO oder ein Delivery Manager, wenn es mehrere Seiten gibt und Geld fließt. Unsere Teams sind heute klein, jedes arbeitet mit Agenten, Design sitzt im selben Team wie die Entwicklung, und Sie arbeiten direkt mit dem Gründer, der selbst baut.

Was es kostet

Builds beginnen bei $25k. Zwei Aufträge von jeweils etwa einem Jahr lagen laut den Clutch-Bewertungen ihrer Kunden bei $50k bis $200k. Das Angebot für den Build kommt am Ende des zweiwöchigen Sprints, aus dem vereinbarten Umfang statt aus einer Schätzung ins Blaue, und wenn der Sprint zeigt, dass der schnellste Weg der falsche ist, erfahren Sie das, bevor der Build beginnt. Wie jedes Angebot bepreist ist, steht auf der Preisseite.