So läuft ein Build

Der Softwareentwicklungsprozess, Woche für Woche

Ein gesundes Softwareprojekt durchläuft fünf Phasen: ein erstes Gespräch zur Passung, eine Discovery-Phase, die aus der Idee einen abgegrenzten Plan macht, einen Build, der funktionierende Software in wöchentlichen Inkrementen liefert, Qualitätsarbeit, die durch den gesamten Build läuft, und eine vollständige Übergabe, nach der dir alles gehört. Dieser Leitfaden zeigt, was in jeder Phase passiert, wie lange das Ganze dauert und was du in jedem Schritt sehen können solltest. Wenn du in den ersten Wochen des Builds keine funktionierende Software anklicken kannst, stimmt etwas nicht.

Dreißig-Minuten-Call buchen

Kurze Antwort

Ein Softwareprojekt läuft vom ersten Gespräch über Discovery, liefert in wöchentlich prüfbaren Inkrementen und endet mit Dokumentation, Tests, Observability und einer vollständigen Übergabe.

Passt für

  • Gründer, die zum ersten Mal eine Softwareagentur beauftragen
  • Teams, die vergleichen, wie Agenturen tatsächlich arbeiten
  • Käufer, die Kontrollpunkte wollen, an denen sie einen Anbieter messen können
  • Alle, die nicht wissen, was zwischen Vertrag und Launch passiert

Passt nicht für

  • Teams mit einem reifen internen Lieferprozess, der bereits funktioniert
  • Käufer, die drei Monate abtauchen und ein fertiges Produkt abholen wollen
  • Projekte, in denen niemand für ein wöchentliches Review verfügbar ist
// 01

Die Optionen im Vergleich

Wie sich ein gesunder Prozess von Agentur-Theater unterscheidet, Phase für Phase.

Phase Ein gesunder Build Warnsignale
Erstes Gespräch

Fragen zu Passung und Scope, und ein klares Nein, wenn es nicht passt.

Ein Preis aus dem Stegreif für einen nicht abgegrenzten Build.

Discovery

Anforderungen, Architektur, Roadmap, riskanteste Annahme getestet.

Komplett übersprungen, oder ein bezahltes Dokument, das niemand prüft.

Vertrag

Festpreis bei fixiertem Scope, wöchentlicher Retainer, wenn er sich bewegt.

Stundenabrechnung ohne definiertes Ergebnis.

Build-Rhythmus

Funktionierende Software, die du jede Woche oder alle zwei anklicken kannst.

Status-Folien und Burndown-Charts statt Software.

Qualität

Tests, CI/CD und Monitoring wachsen mit dem Code.

QA in die letzten zwei Wochen vor dem Launch gequetscht.

Das Ende

Dokumentation, Zugangsdaten und eine vollständige Übergabe.

Wissen bleibt beim Anbieter, sodass du nicht gehen kannst.

// 02

Wo Wavect hier steht

Jeder Build bei uns folgt derselben Form, weil die Fehlermuster immer dieselben sind. Das erste Gespräch dauert dreißig Minuten und klärt, ob du überhaupt bauen solltest. Manchmal endet es damit, dass wir dir davon abraten. Danach macht die Discovery-Phase aus der Idee Anforderungen, eine Architektur, eine Roadmap und einen Test deiner riskantesten Annahme, ab EUR 3,500, verrechnet mit der Schlussrechnung.

Mit dem Scope auf dem Tisch wählst du den Vertrag, der zu deiner Sicherheit passt: einen Festpreis-Werkvertrag, wenn der Scope fixiert ist, einen wöchentlich kündbaren Retainer, wenn das Produkt sich noch bewegt. Der Build liefert in prüfbaren Inkrementen, funktionierende Software jede Woche oder alle zwei Wochen, keine Status-Folien. Tests, CI/CD und Monitoring wachsen mit dem Code, statt kurz vor dem Launch angeschraubt zu werden. Unsere QA-Checkliste zeigt, was bis dahin stehen muss.

Das Engagement endet, wenn die Übergabe vollständig ist: Code in deinen Repositories mit voller Historie, Dokumentation, eine Test-Suite und Pipeline, die du selbst ausführen kannst, und jeder Zugang zu dir rotiert. Ein Prozess ohne definierten Endzustand ist darauf ausgelegt, dich abhängig zu halten.

// 03

Kosten, Risiko und Zeitrahmen

Discovery Ab EUR 3,500Wird mit der Schlussrechnung verrechnet und ist die Grundlage jeder ehrlichen Schätzung.
Build-Rhythmus Wöchentliche InkrementeFunktionierende Software zum Prüfen jede Woche oder alle zwei Wochen, von früh im Build an.
Gesamtdauer Wochen bis MonateEin abgegrenztes MVP war in 6 Wochen live. Komplexe Produkte brauchen Monate. Niemand, der ehrlich ist, nennt ein Datum vor der Discovery.
// 04

Wo das meistens schiefgeht

  • Einen Festpreis unterschreiben, bevor jemand den Build abgegrenzt hat, und dann über jede Änderung streiten.
  • Monate der Stille, gefolgt von einer Big-Bang-Lieferung, die am Ziel vorbeigeht.
  • Fortschritt in Tickets und Folien gemessen statt in Software, die du anklicken kannst.
  • QA und Dokumentation ans Ende verschoben und gestrichen, sobald der Zeitplan rutscht.
  • Kein Product Owner auf Kundenseite, sodass Entscheidungen wochenlang liegen bleiben.
  • Kein definierter Endzustand, sodass die Übergabe nie passiert und du nicht gehen kannst.
// 05

Die Checkliste

Was du in jeder Phase eines Builds überprüfen können solltest.

  • Ein erstes Gespräch, das deinen Scope hinterfragt, statt ihn nur zu bepreisen.
  • Eine Discovery-Phase, die Anforderungen, Architektur, eine Roadmap und einen Test der riskantesten Annahme liefert.
  • Ein Vertrag, der zu deiner Sicherheit passt: Festpreis-Werkvertrag bei fixiertem Scope, sonst wöchentlich kündbarer Retainer.
  • Funktionierende Software zum Prüfen jede Woche oder alle zwei Wochen, von früh im Build an.
  • Ein Änderungsprozess, der offen bepreist und umpriorisiert, statt Scope still zu schlucken.
  • Tests, CI/CD, Monitoring und Error-Tracking entstehen während des Builds, nicht danach.
  • Eine Übergabe mit Code, Historie, Dokumentation, Zugangsdaten und Infrastruktur-Zugriff.
// 06

Wie das in unserer Arbeit aussieht

Derselbe Prozess auf echten Zeitachsen: Discovery, wöchentliche Inkremente, vollständige Übergabe.

PromptID

Live
6 Wochen Von 0 zu Produktion

AI-native Assessment-Plattform, von 0 auf Produktion in 6 Wochen unter komprimiertem Marktdruck.

NestJS NextJS LangChain
AI 2026

LivLive

Live
+1.000 Gleichzeitige Nutzer

AR-RWA-Plattform: 2 Mio. $+ über das Produkt eingenommen, 1.000+ gleichzeitige Nutzer, sechs Wochen flat.

Solidity Typescript React
BLOCKCHAIN 2025

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 75+ Produkte ausgeliefert.

// 07

Wann das passt, und wann nicht

// 01

Wann Wavect passt

  • Du willst Kontrollpunkte, die du überprüfen kannst, keine Versprechen, denen du vertrauen musst.
  • Jemand auf deiner Seite kann jede Woche oder alle zwei Wochen funktionierende Software prüfen.
  • Du willst am Ende Code, Doku und Infrastruktur besitzen.
  • Du willst früh ein ehrliches Nein statt spät ein chaotisches Ja.
// 02

Wann wir nicht passen

  • Du willst eine Spezifikation übergeben und erst zum Launch wieder auftauchen.
  • Niemand auf deiner Seite kann Woche für Woche Produktentscheidungen treffen.
  • Dein Einkauf verlangt Stundenabrechnung und Timesheets.
  • Du misst Fortschritt in gebuchten Stunden, nicht in ausgelieferter Software.

Ein Prozess, den du Woche für Woche überprüfen kannst, ist der Unterschied zwischen einem Partner und einer Blackbox, die du finanzierst.

// 08

Passende Leistungen & Lektüre

// 09

Häufige Fragen

In der Praxis fünf: ein erstes Gespräch zur Passung, eine Discovery-Phase, die Scope, Architektur und Roadmap liefert, ein Build, der funktionierende Software in wöchentlichen Inkrementen ausliefert, Qualitätsarbeit wie Tests, CI/CD und Monitoring, die durch den gesamten Build läuft, und eine Übergabe, die Code, Dokumentation und Zugänge an dich überträgt. Die Namen variieren je nach Anbieter. Die Kontrollpunkte sollten es nicht.
Ein abgegrenztes MVP dauert Wochen. Wir haben Produkte in sechs Wochen von null in Produktion gebracht, und dieses Tempo braucht einen engen Scope und einen entscheidungsfreudigen Product Owner. Produkte mit vielen Integrationen oder Compliance brauchen Monate. Jedes Datum vor der Discovery ist eine Vermutung, also fixier zuerst den Scope und miss den Anbieter dann an dem Datum, das daraus folgt.
Waterfall plant das ganze Projekt vorab und baut es in einem Durchgang. Agile baut in kurzen Zyklen und passt sich an, mit Scrum als gängigstem Framework. In der Praxis mischt ein gesundes Projekt beides: Discovery ist eine kleine Planungsphase vor dem Code, danach läuft die Lieferung agil in wöchentlichen Inkrementen. Das Etikett zählt weniger als die Frage, ob du über den gesamten SDLC hinweg regelmäßig funktionierende Software siehst.
Sie werden sich ändern, und ein gesunder Prozess plant das ein. Kleine Änderungen werden üblicherweise im laufenden Inkrement aufgefangen. Größere bekommen eine Auswirkungsanalyse, einen bepreisten Change Request und eine offene Umpriorisierung mit dir. Das Warnsignal ist ein Anbieter, bei dem jede Änderung entweder ein Streit oder eine stille Budgetüberschreitung ist.
Discovery ist der intensive Teil, weil deine Antworten den Scope definieren. Danach plan ein wöchentliches Review funktionierender Software ein und Erreichbarkeit für Entscheidungen dazwischen. Was ein Build nicht überlebt, ist ein fehlender Product Owner auf deiner Seite, denn jede offene Entscheidung bremst die Arbeit.
Zuletzt geprüft: vonKevin Riedl wiki ↗
Dreißig-Minuten-Call buchen