Paid Discovery: Ein konkretes Entscheidungs-Framework
So starten Sie die Entwicklung Ihrer Software, ohne sich auf ein großes Budget festzulegen.
Teil 1: Was ist eine bezahlte Discovery-Phase?
Sie haben eine Produktidee oder möchten einen Geschäftsprozess verbessern. Sie wissen aber noch nicht genau, welche Funktionen die Software enthalten soll.
Und natürlich müssen Sie ein festes Budget festlegen. Jeder liebt feste Budgets.
Hier kommt der Kompromiss: Um das Budget schätzen zu können, verlangt eine Agentur möglicherweise detaillierte Spezifikationen. Deren Ausarbeitung erfordert jedoch Entscheidungen, für die Sie vielleicht noch nicht bereit sind.
Die Alternative ist, die Entwicklung auf Aufwandsbasis (Time & Materials) zu beginnen. Das gibt Ihnen Flexibilität, lässt aber auch das Budget offen.
Eine bezahlte Discovery-Phase bietet einen anderen Ausgangspunkt.
Es handelt sich um ein kurzes, fokussiertes Projekt, das die wichtigsten Fragen beantworten soll, bevor Sie in die eigentliche Entwicklung investieren.
Die Frage könnte lauten: Was sollten Sie zuerst bauen? Verstehen die Nutzer die Idee? Ist das Produkt technisch machbar? Welche Funktionen bringen dem Kunden den größen Nutzen?
Teil 2: Was ist die richtige Frage?
Beginnen Sie mit der größten Unsicherheit
Der erste Schritt hängt davon ab, was Sie noch herausfinden müssen.
Wenn Sie unsicher sind, ob die Nutzer das Produkt verstehen:
Erstellen Sie eine anklickbare Demo. Testen Sie den primären Benutzerfluss, ohne die eigentliche Software im Hintergrund zu bauen.
Wenn Sie sich unschlüssig sind, ob die Technologie funktioniert:
Bauen Sie einen technischen Prototyp. Testen Sie die Integration, die Hardwareverbindung, den Algorithmus oder ein anderes kritisches technisches Element.
Wenn Sie bereits einen funktionalen Prototyp haben:
Überprüfen Sie dessen Architektur, Sicherheit, Datenmodell und Wartbarkeit. Entscheiden Sie, was beibehalten werden kann und was neu aufgebaut werden muss, bevor es zu einem echten Produkt wird.
Wenn das Produkt klar ist, aber der Gesamtumfang zu groß:
Definieren Sie die kleinstmögliche nutzbare Version (MVP). Schätzen Sie diese Phase ab, anstatt zu versuchen, die Kosten für das gesamte Produkt vorherzusagen.
Teil 3: Die Ergebnisse
Was sollte eine bezahlte Discovery-Phase liefern?
Die Discovery-Phase sollte nicht mit einer Reihe von Meetings und einer Präsentation voller allgemeiner Empfehlungen enden.
Je nach Fragestellung sollten Sie etwas Konkretes erhalten:
Einen klickbaren und testbaren User Flow, den Sie potenziellen Kunden zeigen können
Einen Nachweis der technischen Machbarkeit, der beweist, dass die Idee umsetzbar ist
Eine solide Architektur, die tatsächlich als Grundlage für die Schätzung und Entwicklung dienen kann
Einen klar definierten oder reduzierten Projektumfang und eine Schätzung für die nächste Phase
Eine klare Antwort auf die zu Beginn der Discovery definierte Frage
Der letzte Punkt ist entscheidend.
Manchmal ist die richtige Entscheidung nach dieser Phase weiterzumachen.
Manchmal ist es, die Richtung zu ändern.
Manchmal ist es aufzuhören.
Dies frühzeitig herauszufinden, kann mehr Geld sparen, als direkt mit der Entwicklung zu beginnen.
Teil 4: Ein praktisches Beispiel
Ein Cybersecurity-Startup kam mit einem durch Vibe Coding erstellten Prototyp zu uns. Die Gründer verfügten über technische Erfahrung, fundiertes Fachwissen und Zugang zu potenziellen Kunden. Sie hatten den Prototyp bereits genutzt, um mehrere User Flows und Funktionen zu validieren.
Die technische Machbarkeit des Produkts war jedoch noch unklar. Bevor der Prototyp einem größeren Kreis potenzieller Kunden präsentiert werden sollte, wollte der Kunde wissen, ob sich die Idee in ein echtes Produkt umsetzen lässt.
Wir prüften den Prototyp, definierten den minimalen Funktionsumfang und entwarfen eine passende Architektur.
Am Ende der Discovery-Phase konnten wir bestätigen, dass das Produkt im definierten Rahmen technisch machbar ist. Der Kunde erhielt außerdem eine vorgeschlagene Architektur und eine klare technische Basis für den nächsten Schritt. Anschließend konnte er den Prototyp nutzen, um weiteres Marktfeedback einzuholen und herauszufinden, welche Funktionen am wichtigsten sind, bevor in die volle Entwicklung investiert wird.
