MVP entwickeln lassen: worauf es bei der Partnerwahl ankommt

MVP entwickeln lassen

MVP entwickeln lassen ist keine Modefrage. Die meisten Gründerinnen haben weder Zeit noch Lust, jeden Stack selbst zu stemmen, während sie gleichzeitig verkaufen, Geld einsammeln und Leute einstellen. Die Spezifikation abgeben und drei Monate später staunen reicht nicht. Es funktioniert, wenn beide Seiten dieselbe Entscheidung sehen, die das Produkt beantworten soll, und wenn du den Code mitnehmen kannst.

Dieser Text geht um die Partnerwahl: woran erkennst du, ob jemand liefern kann, was du fürs Lernen am Markt brauchst? Den Vergleich der Modelle (Agentur, Studio, Accelerator) findest du in Venture Studio vs. Agentur. Ablauf und typische Zeiträume stehen unter MVP-Entwicklung Schweiz. Wenn du dieselbe Schleife in Zürich vertraglich willst, steht das Angebot auf der Seite zur MVP-Validierung.

1. Zuerst das Ziel aufschreiben

Bevor du Angebote einholst, halte drei Zeilen schriftlich fest:

• Welche Entscheidung soll das MVP tragen? Preis, ein Product-Market-Signal, etwas, das eine Investorin ausprobieren kann, oder ein internes Stopp.
• Welche Kennzahl willst du in den ersten 4 bis 8 Wochen nach dem Launch als ausreichend gelten lassen?
• Was gehört ausdrücklich nicht in die erste Version? Eine Liste, über die man streiten kann.

Ein Beispiel, das du vor den Offerten aufschreibst. Du lädst 15 Personen aus der Zielgruppe ein. Die Entscheidung lautet: schaffen davon mindestens acht den Kernpfad in Woche sechs, ohne dass du daneben sitzt? Wenn ja, finanzierst du den nächsten Schnitt. Wenn nein, hörst du auf oder änderst das Angebot. Ein Partner, der nur «baut die Plattform» hört, ergänzt Bildschirme. Ein Partner, der die Linie acht von fünfzehn hört, streicht Bildschirme, bis dieser Pfad beobachtbar ist.

Ohne diese drei Zeilen optimiert jedes Angebot den Umfang. Du riskierst, das Falsche zu bauen. Die Anbieter können dabei beschäftigt wirken, ohne dass die Entscheidung klarer wird.

2. Discovery vor dem Fixpreis

Seriöse Partner verlangen meist eine Discovery-Phase oder ein bezahltes Scoping, bevor sie einen Fixpreis unterschreiben. Wer blind CHF 40’000 zusagt, kauft später entweder Überstunden oder einen Rahmen, in den das Lernziel nicht mehr passt. Die Zahl zeigt die Form einer häufigen Offerte. Sie ist keine Preisliste.

Frag im ersten Gespräch: Wenn Nutzerfeedback reinkommt, wie wird der Umfang angepasst, wer gibt frei, und was passiert mit dem Preis? Du willst einen aufgeschriebenen Weg für Änderungen. «Wir sind flexibel» ist keiner.

Aus der Discovery sollte ein priorisiertes Backlog kommen, die Risiken, die der Partner nicht versteckt (Zahlungen, eine unangenehme Integration, eine zweite Sprache), und ein Bild des ersten Releases, das eine fremde Person anklicken kann. Ist die Discovery gratis und zeitlich offen, ist sie meist ein Verkaufsgespräch. Bezahl die Wochen, die den Schnitt erzwingen.

3. IP, Repo und wer deployen darf

Vertraglich und technisch klären:

• Git-Repository in deiner Organisation, oder ein Übergang auf dich zum Ausstieg, mit Datum
• eine Lizenz am Code, der für dich geschrieben wurde, inklusive der Skripte, die ihn bauen und deployen
• Cloud-Accounts auf deinen Namen, oder ein Export, der mehr ist als ein Zip der Datenbank
• wer Production-Deploys freigibt, und wer in der Woche nach dem Launch die Logs lesen darf

Bleibt hier etwas offen, mietest du das Produkt. In der Woche, in der ihr euch uneinig seid, merkst du, ob jemand anders weiterbauen kann. Frag nach einem kurzen Dienstagstest: Wenn der Vertrag nächsten Dienstag endet, welche Logins hast du am Freitag noch?

4. Meilensteine, die mehr sind als «Sprint 3»

Gute Meilensteine kannst du zeigen, und sie hängen am Nutzen für Nutzerinnen. Anmeldung plus der Kernpfad. Eine kleine Admin-Ansicht, damit du die Datenbank nicht von Hand pflegst. Zahlungen, wenn bei der Entscheidung wirklich bezahlt werden muss. Logs, damit ein Ausfall sichtbar ist.

Schwache Meilensteine klingen nach Fortschritt und zeigen nichts: «Backend fertig», «Sprint 3 abgeschlossen», «API fertig». Häng jeden Meilenstein an etwas, das eine Nutzerin, oder du in ihrer Rolle, im Browser tun kann. Schreib das Datum daneben, und daneben die Liste dessen, was nicht dazugehört. Dann beschreibt das Datum den Pfad, den du aufgeschrieben hast. Ideen aus dem letzten Gespräch, die nicht auf der Liste stehen, schieben das Datum nicht.

5. Validierung gehört zum Auftrag

Wenn der Partner nur baut, was du aufschreibst, und nie eine Nutzerin davor setzt, kannst du am Ende für ein poliertes Produkt zur falschen Hypothese zahlen. Mindeststandard: wiederkehrende Reviews mit echten oder zumindest typischen Nutzerinnen, aufgeschriebene Erkenntnisse, und ein Backlog, das sich wegen dieser Notizen verschiebt.

Frag jeden Anbieter, Studio oder Agentur, wo im Kalender die Nutzersitzung sitzt, und was er aufhört zu bauen, wenn die Sitzung schlecht läuft. Wie die Wochen meist strukturiert sind, steht in wie eine MVP-Entwicklung in der Schweiz läuft. Wer den Loop absichtlich in den Auftrag legt, beschreibt das im Produktvalidierungs-Paket.

• Entscheidung, Kennzahl und die Liste, was nicht dazugehört, existieren vor der Offerte.
• Es gibt eine bezahlte Discovery oder eine explizite Regel für Änderungen. Kein Fixpreis auf ein Schulterzucken.
• Repo, Cloud und Deploy-Rechte sind deine, mit einem Dienstagstest, den du wirklich machen könntest.
• Meilensteine sind Pfade, die eine Nutzerin anklicken kann, und jemand prüft sie mit Nutzerinnen, bevor der nächste Schnitt kommt.

6. Warnzeichen

• Festpreis, obwohl der Umfang nicht verstanden ist, und kein Weg, beides zu ändern
• Kein Zugriff auf Repository oder Kennzahlen, angeblich aus Sicherheitsgründen. Sicherheit heisst Zugriffsregeln. Die Eigentümerin aus dem Repo auszusperren ist keine Sicherheitsmassnahme
• Reines Abarbeiten von Tickets, ohne Verantwortung für die Architektur
• «Wir kümmern uns um alles», ohne messbare Kriterien, ob das MVP gegriffen hat

Eines davon kann eine Verhandlung sein. Zwei sind ein Grund, weiterzusuchen.

7. Wann du zusätzlich Richtung brauchst

Manche Gründerinnen brauchen eine technische Leitung, die mit dem Umfang streitet. Manche brauchen ein Team, das einen Umfang umsetzt, dem sie schon trauen. Wenn du Produkturteil und die Umsetzung brauchst, lohnt sich wann du einen echten Tech-Partner brauchst. Danach noch einmal Venture Studio vs. Agentur. Labels wie «Agentur» oder «Studio» sind zweitrangig. Schau, ob der Partner mit dir lernen will.

Was du als Nächstes tust

Schreib die drei Zeilen aus Abschnitt 1. Nimm sie mit ins Gespräch. Oder starte beim Produktvalidierungs-Paket, wenn du diesen Loop in Zürich im Auftrag haben willst. MVP entwickeln lassen funktioniert, wenn Entscheidung, Kennzahl, der Code bei dir und die Iteration vor der Unterschrift klar sind.