Discovery-Phase in der Softwareentwicklung: Ein Guide für 2026

Elena Marchetti Head of Product, SaaS, YuSMP Group · Scopt und liefert Software für US- und EU-Produktteams und hat mehr Projekte durch eine gute Discovery gerettet gesehen als durch irgendein Framework

Was ist die Discovery-Phase in der Softwareentwicklung?

Die Discovery-Phase in der Softwareentwicklung ist die erste, strukturierte Phase eines Projekts, durchgeführt bevor Produktionscode geschrieben wird, in der das Team eine grobe Idee in einen klar definierten und geschätzten Plan verwandelt. Hier einigen sich alle darauf, was gebaut wird, für wen, warum und ungefähr zu welchen Kosten — durch Recherche, Anforderungserhebung und technische Analyse statt durch Annahmen. Der Kernbegriff, nach dem Menschen suchen, die Discovery-Phase in der Softwareentwicklung, beschreibt genau das: die bewusste Arbeit, Vermutungen durch Evidenz zu ersetzen, bevor die Entwicklung beginnt.

Stellen Sie sich Discovery als den Unterschied zwischen dem Bauplan eines Architekten und dem einfachen Loslegen mit dem Mauern vor. Während der Discovery-Phase in der Softwareentwicklung untersuchen Business-Analysten, ein Solution Architect, ein Product Designer und ein Delivery Lead das Problem aus drei Blickwinkeln zugleich — Geschäftsziele, Nutzerbedürfnisse und technische Machbarkeit — und erstellen Dokumente, aus denen ein Team tatsächlich bauen kann. Diese Klarheit im Vorfeld ist der Grund, warum jede ernsthafte Zusammenarbeit im Bereich Custom Software Development mit Discovery beginnt statt mit einem kopflosen Sprint: Der Scope, den Sie hier definieren, bestimmt still Budget, Zeitplan und Qualität von allem, was folgt.

Entscheidend ist, dass Discovery keine offene Beratung ist. Eine gute Discovery-Phase eines Softwareprojekts ist zeitlich begrenzt, hat einen festen Satz benannter Deliverables und endet mit einer Go/No-Go-Entscheidung: mit einem realistischen Plan in den Bau gehen, die Richtung ändern oder aufhören, bevor das echte Geld ausgegeben wird. Sie senkt das Risiko gerade deshalb, weil sie im Verhältnis zu dem Bau, den sie schützt, günstig ist.

Warum die Discovery-Phase wichtig ist

Die Discovery-Phase ist wichtig, weil die teuersten Softwarefehler gemacht werden, bevor eine Zeile Code geschrieben ist — in den Entscheidungen darüber, was gebaut wird und wie. Discovery zu überspringen entfernt diese Arbeit nicht; es verschiebt sie nur in den Bau, wo eine Meinungsänderung ein Vielfaches kostet. Ein Missverständnis auf einem Whiteboard zu beheben kostet einen Nachmittag; es nach drei Monaten Entwicklung zu beheben kostet eine Neu-Architektur.

Die Zahlen bestätigen das. Branchenumfragen finden immer wieder, dass ein großer Anteil der Softwareprojekte Budget oder Zeitplan überschreitet — nach verschiedenen Schätzungen rund 45 % laufen über Budget — und die langlaufende CHAOS-Forschung der Standish Group zeigt seit Jahren, dass nur etwa ein Drittel der Projekte pünktlich, im Budget und im Scope fertig wird. Die gemeinsame Grundursache ist nicht schlechtes Engineering, sondern unklare Anforderungen und ein sich verschiebender Scope — genau das, was Discovery verhindern soll. Für Gründer gibt es ein zweites Risiko: CB Insights' bekannte Analyse zum Scheitern von Startups setzt „kein Marktbedarf“ an die Spitze der Liste — grob 35 % der gescheiterten Startups — ein Risiko, das Discovery früh aufdeckt, indem sie das Problem vor der Lösung validiert.

Über die Risikosenkung hinaus richtet Discovery alle auf eine Vision aus. Sie schließt die Lücke zwischen dem, was ein Kunde sich vorstellt, und dem, was ein Entwickler hört, sodass es eine einzige, schriftliche Quelle der Wahrheit gibt statt fünf leicht unterschiedlicher mentaler Modelle. Diese Abstimmung ist das, was die spätere Schätzung vertrauenswürdig macht — ein auf validierten Anforderungen gebauter Plan ist eine Prognose, während eine auf einem zweizeiligen Briefing gebaute Schätzung ein Wunsch ist. Wenn Sie sehen wollen, wie diese Schätzung tatsächlich erstellt wird, führt unser Guide zur Schätzung von Softwareprojekten durch die Mechanik, die Discovery speist.

Was während der Discovery-Phase passiert

Während der Discovery-Phase arbeitet das Team das Problem auf drei parallelen Spuren durch — Geschäft, Nutzer und Technik — und wandelt jede in konkrete Artefakte um. Der Punkt ist, die größten Unbekannten zuerst anzugehen, nicht alles zu dokumentieren: Discovery dient dem Entrisiken, also geht die tiefste Arbeit dorthin, wo das Projekt am wenigsten verstanden ist.

• Stakeholder-Workshops und Zielsetzung. Strukturierte Sitzungen mit den Menschen, denen das Ergebnis gehört, um Geschäftsziele, Erfolgsmetriken und Rahmenbedingungen festzunageln — das „Warum“, an dem jede spätere Entscheidung gemessen wird.
• Anforderungserhebung und Priorisierung. Ziele in eine priorisierte Liste funktionaler und nicht-funktionaler Anforderungen verwandeln, meist als User Stories, damit der Scope explizit und rankbar ist statt eine Wunschliste.
• Markt- und Nutzerforschung. Wettbewerber, die Zielnutzer und ihre echten Jobs-to-be-done untersuchen, damit das Produkt ein validiertes Problem löst statt eines angenommenen.
• UX und Prototyping. User Flows, Low-Fidelity-Wireframes und oft ein klickbarer Prototyp, der die Idee greifbar und testbar macht, bevor sie teuer zu ändern ist.
• Technische Analyse und Architektur. Ein Solution Architect entwirft eine High-Level-Architektur, wählt einen Tech-Stack und markiert Integrationen, Daten- und Compliance-Rahmenbedingungen, die Kosten und Zeitplan prägen.
• Risikobewertung und Planung. Benennen, was schiefgehen könnte — technisch, kommerziell oder regulatorisch — mit Gegenmaßnahmen, dann alles in eine Roadmap und eine Schätzung packen.

Diese Spuren speisen sich gegenseitig: Ein Ergebnis der Nutzerforschung kann eine Anforderung ändern, was die Architektur ändert, was die Schätzung ändert. Sie zusammen laufen zu lassen statt in einer starren Linie ist das, was Discovery zu einem Plan konvergieren lässt, der hält, wenn der Bau beginnt.

Zentrale Deliverables der Discovery-Phase

Die Discovery-Phase endet in greifbaren Deliverables, nicht in einem Gespräch — einem definierten Paket von Dokumenten, das ein Kunde zu jedem Team bringen und ein vergleichbares, fundiertes Angebot erhalten kann. Produziert eine Discovery nur ein Foliendeck und gute Stimmung, ist sie gescheitert; der Wert liegt in Artefakten, die den Bau begrenzen und leiten. Die Tabelle unten listet auf, was eine vollständige Discovery übergibt.

Diese Artefakte sind bewusst portabel. Weil Discovery als Dokumente statt als Versprechen geliefert wird, ist ein Kunde nie gebunden — der Plan kann zu konkurrierenden Teams für Angebote gehen, was selbst ein Zeichen einer ehrlichen Discovery ist. Discovery ist der Anfang der weiteren Bau-Sequenz; für den gesamten Bogen von der Idee bis zum Launch siehe unseren Guide zum Prozess der individuellen Softwareentwicklung, von dem Discovery Stufe eins ist.

Wie lange dauert die Discovery-Phase?

Eine Discovery-Phase dauert in der Regel zwei bis acht Wochen, skaliert nach Größe und Risiko des Projekts — nicht danach, wie viel dokumentiert werden kann. Die richtige Dauer ist die kürzeste, die die größten Unbekannten beseitigt; eine Discovery, die sich hinzieht, vermeidet meist eine Entscheidung, statt sie zu schärfen. Die groben Bänder unten gelten für die meisten Projekte.

Zwei Dinge schieben ein Projekt die Skala hinauf: die Zahl der Menschen, die sich einig werden müssen, und die Zahl der Unbekannten in der Technik. Ein Single-Founder-MVP mit einer klaren Idee sitzt am kurzen Ende; eine regulierte Enterprise-Plattform, die drei Legacy-Systeme berührt, sitzt am langen Ende. Wenn die Machbarkeit selbst zweifelhaft ist, kann Discovery einen kleinen Proof of Concept ausgliedern, um eine riskante Annahme zu testen, bevor der Schätzung vertraut wird.

Wie viel kostet eine Discovery-Phase?

Eine Software-Discovery-Phase kostet typischerweise etwa 5 bis 10 Prozent des gesamten Entwicklungsbudgets. Konkret bedeutet das für ein Projekt im Bereich von 50.000 bis 200.000 $ meist grob 5.000 bis 15.000 $, je nach Teamgröße, Anzahl der beteiligten Spezialisten und wie viel Prototyping und Recherche der Scope verlangt. Sie wird am besten als Festpreis-Sprint mit benannten Deliverables gekauft, sodass Sie genau wissen, wofür Sie zahlen, statt offene Beratungsstunden zu mieten.

Dieser Preis spiegelt ein Spezialistenteam wider, das ein paar Wochen arbeitet. Als Referenzpunkt für 2026: UK-Agentur-Tagessätze liegen grob bei 450–700 £ für einen Business-Analysten, 600–900 £ für einen Solution Architect und 500–750 £ für einen Product Designer; US- und EU-Sätze variieren, liegen aber in einem vergleichbaren Band. Eine zwei- bis vierwöchige Discovery landet daher für die meisten mittelgroßen Projekte im unteren bis mittleren fünfstelligen Bereich — ein kleiner Bruchteil des Baus, den sie entrisikt.

Der ehrliche Weg, die Kosten einzuordnen, ist als Versicherung, die sich meist auszahlt. Ein klarer Scope verhindert die Change Requests, das Rework und die Neu-Architektur mitten im Bau, die routinemäßig weit mehr als 10 % zu einem Projekt hinzufügen, sodass Discovery typischerweise mehrfach wieder hereingeholt wird. Und wenn Discovery offenbart, dass die Idee nicht wert ist, gebaut zu werden, hat sie Ihnen das gesamte Baubudget gespart — was das günstigste mögliche Ergebnis ist, kein Misserfolg. Für ein vollständigeres Kostenbild des Baus, der folgt, siehe unsere Aufschlüsselung der Kosten der individuellen Softwareentwicklung.

Der Discovery-Prozess, Schritt für Schritt

Der Discovery-Prozess läuft als kurze, geordnete Sequenz, die in einer Entscheidung endet, und obwohl Teams die Bezeichnungen variieren, ist die Form konsistent: abstimmen, recherchieren, definieren, gestalten, dann planen. Jeder Schritt produziert ein Artefakt, auf dem der nächste aufbaut, sodass nichts doppelt getan wird und die Schätzung am Ende auf echter Arbeit ruht.

1. Kick-off und Abstimmung. Workshops mit Stakeholdern, um Ziele, Rahmenbedingungen, Erfolgsmetriken und die Grenzen des Scopes zu erfassen. Output: eine abgestimmte Problemstellung.
2. Recherche und Analyse. Wettbewerber-, Markt- und Nutzerforschung plus eine Sichtung vorhandener Systeme oder Daten. Output: Erkenntnisse, die die Idee validieren oder umformen.
3. Anforderungsdefinition. Ziele in ein priorisiertes Backlog funktionaler und nicht-funktionaler Anforderungen übersetzen. Output: die Anforderungsspezifikation.
4. UX- und technisches Design. User Flows, Wireframes oder ein klickbarer Prototyp und eine High-Level-Architektur mit einem Stack- und Integrationsplan. Output: ein testbares Design und ein Architekturentwurf.
5. Schätzung, Risiko und Roadmap. Kosten- und Zeitschätzung, ein Risikoregister mit Gegenmaßnahmen und eine phasierte Delivery-Roadmap. Output: ein kalkulierter Plan und ein klares Go/No-Go.

Der letzte Schritt ist der ganze Sinn: Discovery schließt mit einer Empfehlung, nicht mit einem Achselzucken. Ein gut geführter Prozess übergibt Ihnen einen Plan, der konkret genug ist, um daraus zu bauen, und ehrlich genug, um sich davon abzuwenden. Von hier fließt die Arbeit in die volle Delivery — unser Guide zur Softwareprodukt-Entwicklung deckt ab, wie dieser Plan zu einem ausgelieferten Produkt wird.

Wann brauchen Sie eine Discovery-Phase?

Sie brauchen eine dedizierte Discovery-Phase immer dann, wenn das Risiko, das Falsche zu bauen, hoch ist — und eine leichtere Version immer dann, wenn es das nicht ist, aber Sie überspringen Discovery fast nie ganz. Die Frage ist nicht, ob Discovery, sondern wie viel. Ein kleines, gut verstandenes Feature braucht einen Tag davon; eine neue Plattform braucht Wochen. Die Signale unten sagen Ihnen, an welchem Ende Sie sind.

• Der Scope ist unklar oder umstritten. Mehrere Stakeholder stellen sich verschiedene Produkte vor — Discovery erzwingt eine gemeinsame Definition, bevor Geld ausgegeben wird.
• Das Projekt ist groß oder lang. Je größer der Bau, desto mehr verstärkt sich eine falsche Annahme, und desto mehr sparen ein paar Wochen Planung.
• Es gibt komplexe Integrationen oder Compliance-Regeln. Legacy-Systeme, Drittanbieter-APIs, HIPAA, DSGVO oder PCI machen aus „wie schwer kann das sein“ eine echte Forschungsfrage.
• Ein festes Budget oder eine Deadline steht auf dem Spiel. Sie können sich glaubwürdig auf keine Zahl festlegen ohne die Analyse, die Discovery liefert.
• Es ist eine brandneue Produktidee. Discovery validiert das Problem und formt den MVP-Scope, bevor Sie einen Bau auf eine ungetestete Annahme setzen.

Trifft nichts davon zu — eine winzige Änderung an einem System, das Sie gut kennen — ist eine formale Discovery übertrieben, und ein kurzes Scoping-Gespräch genügt. Discovery ist ein Regler, kein Schalter; Sie drehen ihn im Verhältnis zu den Unbekannten und dem Geld auf dem Spiel auf. Wo die offene Frage lautet, welches Minimum zuerst zu bauen ist, passt sie natürlich zu den Entscheidungen in unserem Guide zu MVP vs. Prototyp vs. Proof of Concept.

Häufige Fehler in der Discovery-Phase

Die meisten gescheiterten Discoveries scheitern auf eine von wenigen vorhersehbaren Weisen, und alle stammen daraus, zu vergessen, dass Discovery existiert, um eine Entscheidung zu ermöglichen, nicht um gründlich zu wirken. Vermeiden Sie diese, und eine Discovery verdient ihr Geld.

• Sie offen laufen lassen. Discovery ohne Zeitbegrenzung wird zur Analyse-Paralyse. Legen Sie im Vorfeld eine Dauer und ein Entscheidungsdatum fest.
• Keine konkreten Deliverables produzieren. Eine Discovery, die in einem Deck endet und keine Anforderungen, keinen Prototyp oder keine Schätzung hat, hat ihre eigentliche Aufgabe übersprungen.
• Die technische Spur überspringen. Anforderungen und Design ohne einen Solution Architect bedeuten, dass die Schätzung Fiktion ist und der Neubau kommt.
• Den Scope vergolden. Der Versuch, jedes künftige Feature zu spezifizieren, treibt die Kosten hoch und verzögert den Bau. Definieren Sie das MVP scharf und verschieben Sie den Rest.
• Discovery als Sales-Pitch behandeln. Wenn das Ziel ist, einen vorab entschiedenen Bau zu rechtfertigen, hört Discovery auf, Risiko aufzudecken. Eine echte Discovery darf empfehlen: „Bauen Sie das nicht.“

Das gesündeste Zeichen einer guten Discovery ist, dass sie wirklich bereit ist, zu einem „Nein“ zu gelangen — ein Team, das nur je zu „ja, und es kostet genau, was wir angeboten haben“ kommt, verkauft, es entdeckt nicht.

FAQ

Was ist eine Discovery-Phase in der Softwareentwicklung?

Eine Discovery-Phase in der Softwareentwicklung ist die strukturierte erste Phase eines Projekts, bevor Produktionscode geschrieben wird, in der das Team Ziele klärt, Anforderungen erhebt und priorisiert, Nutzer und Markt untersucht, die Lösungsarchitektur entwirft und Risiken identifiziert. Sie verwandelt eine vage Idee in einen definierten, geschätzten Plan. Das Ergebnis ist ein Satz konkreter Deliverables — eine Anforderungsspezifikation, User Flows, ein klickbarer Prototyp, ein Architekturentwurf, ein Risikoregister und eine kalkulierte Roadmap — die beiden Seiten erlauben, sich mit realistischem Scope, Budget und Zeitplan zum Bau zu verpflichten.

Wie lange dauert die Discovery-Phase?

Die Discovery-Phase dauert in der Regel zwei bis acht Wochen, skaliert nach Größe und Komplexität des Projekts. Ein einfaches Produkt oder MVP lässt sich in etwa ein bis zwei Wochen scopen; eine Anwendung mittlerer Komplexität braucht typischerweise zwei bis vier Wochen; und ein großes oder stark integriertes Enterprise-System läuft vier bis acht Wochen oder mehr. Die richtige Länge ist die kürzeste, die die größten Unbekannten beseitigt — Discovery soll den Bau entrisiken, nicht zu einem offenen Forschungsprojekt werden.

Wie viel kostet eine Discovery-Phase?

Eine Software-Discovery-Phase kostet typischerweise etwa 5 bis 10 Prozent des gesamten Entwicklungsbudgets. Für ein Projekt im Bereich von 50.000 bis 200.000 $ bedeutet das meist grob 5.000 bis 15.000 $, je nach Teamgröße und Anzahl der beteiligten Spezialisten. Sie wird am besten als Festpreis-Sprint mit benannten Deliverables durchgeführt statt als offene Beratungsstunden, und die Kosten sind leicht wieder hereingeholt, weil ein klarer Scope weit teureres Rework und Change Requests später im Bau verhindert.

Was sind die Deliverables der Discovery-Phase?

Die zentralen Deliverables einer Discovery-Phase sind eine Software-Anforderungsspezifikation (funktionale und nicht-funktionale Anforderungen), eine priorisierte Feature-Liste oder ein Produkt-Backlog, User Flows und UX-Maps, Low-Fidelity-Wireframes oder ein klickbarer Prototyp, eine High-Level-Systemarchitektur, ein Risikoregister mit Gegenmaßnahmen und eine Delivery-Roadmap mit einer realistischen Kosten- und Zeitschätzung. Zusammen erlauben diese Dokumente einem Kunden, den Plan zu jedem Entwicklungsteam zu bringen und ein vergleichbares, fundiertes Angebot statt einer Schätzung ins Blaue zu erhalten.

Brauchen Sie immer eine Discovery-Phase?

Sie brauchen nicht immer eine vollständige Discovery-Phase, aber Sie brauchen fast immer irgendeine Form von Discovery. Eine kurze, schlanke Version genügt für ein kleines, gut verstandenes Feature mit stabilem Scope. Eine dedizierte Discovery-Phase zahlt sich aus, wenn das Projekt groß ist, die Anforderungen unklar sind, mehrere Stakeholder abgestimmt werden müssen, es komplexe Integrationen oder Compliance-Regeln gibt oder ein festes Budget auf dem Spiel steht. Je größer das Risiko, das Falsche zu bauen, desto mehr ist eine Discovery-Phase wert.

Was ist der Unterschied zwischen einer Discovery-Phase und einem Proof of Concept?

Eine Discovery-Phase beantwortet, ob wir das bauen sollten und wie — sie definiert Scope, Anforderungen, Architektur, Kosten und Risiko über das gesamte Produkt. Ein Proof of Concept beantwortet eine engere Frage: ob ein bestimmter riskanter Teil überhaupt gebaut werden kann. Discovery ist das Planen und Entrisiken des Projekts; ein Proof of Concept ist ein kleines technisches Experiment, das eine einzige Machbarkeitsfrage validiert. Bei komplexen Projekten arbeiten die beiden zusammen — Discovery identifiziert die riskante Annahme, und ein Proof of Concept testet sie, bevor die volle Entwicklung beginnt.

Zuletzt aktualisiert am 20. August 2026. Angaben zu Kosten, Dauer und Sätzen spiegeln breit berichtete Branchenquellen aus 2026 wider (einschließlich der Standish-CHAOS- und CB-Insights-Forschung) und sind als richtungsweisende Orientierung zu verstehen, nicht als feste Angebote. Die richtige Discovery hängt von Größe, Komplexität und Risiko Ihres Projekts ab.