TL;DR — ein Satz pro Modell
Die drei Software-Engagement-Modelle unterscheiden sich vor allem in einer Dimension: wer das Scope-Risiko trägt und wie viel Flexibilität Sie im Gegenzug behalten.
- Festpreis: Der Anbieter trägt das Überschreitungsrisiko, Sie erhalten eine Kostenobergrenze — geben aber Flexibilität ab und zahlen eine Risikoprämie, die im Angebot eingepreist ist.
- Time & Materials (T&M): Sie zahlen für tatsächliche Stunden zu einem vereinbarten Satz, der Scope kann sich frei weiterentwickeln — aber Sie tragen das Risiko steigender Kosten, wenn sich die Anforderungen ausweiten.
- Dedicated Team: Ein stabiles Team, das zu einer planbaren monatlichen Rate abgerechnet wird. Sie steuern den Backlog, der Anbieter übernimmt Besetzung und Bindung; am besten geeignet für langfristige Produktarbeit, bei der Wissensakkumulation wichtig ist.
Keines der drei Modelle ist universell überlegen. Die richtige Wahl hängt davon ab, wie klar Ihre Anforderungen definiert sind, wie schnell sie sich voraussichtlich ändern, wie lange das Engagement laufen wird und wie viel interne Kapazität Sie haben, um die Arbeit zu steuern. Die folgenden Abschnitte erläutern jedes Modell ausführlich; ein Entscheidungsrahmen und eine Vergleichstabelle helfen Ihnen bei der Wahl.
Für einen breiteren Kontext zur Preisgestaltung lesen Sie unseren Leitfaden zu den Kosten individueller Softwareentwicklung 2026 und die Seite zu Preisgestaltung und Engagement-Modellen.
Festpreis: definierter Scope, Anbieterrisiko
Bei einem Festpreisvertrag verpflichtet sich der Anbieter, einen definierten Leistungsumfang zu einem festgelegten Gesamtpreis zu liefern. Wenn die Lieferung länger dauert als geplant oder die Umsetzung komplexer ist als geschätzt, trägt der Anbieter die Mehrkosten. Aus Kundensicht liegt der Reiz klar auf der Hand: Sie kennen das Budget, bevor Sie unterschreiben.
Wie Festpreis in der Praxis funktioniert
Festpreisverträge erfordern erhebliche Spezifikationsarbeit im Vorfeld. Vor der Angebotserstellung möchte ein seriöser Anbieter detaillierte Anforderungen, User Stories, Wireframes oder zumindest ein ausführliches Produktbriefing. Je unklarer die Spezifikation, desto größer der Puffer, den der Anbieter einkalkuliert, um sein Risiko abzudecken. Eine gründliche Discovery-Phase (4–6 Wochen) reduziert das Angebot in der Regel stärker, als sie kostet, weil sie die Unsicherheit des Anbieters durch reale Informationen ersetzt.
Die meisten Festpreisverträge enthalten eine Change-Order-Klausel: Arbeiten außerhalb des vereinbarten Scopes werden separat angeboten und dem Vertrag hinzugefügt. In der Praxis entstehen selbst bei gut spezifizierten Projekten 10–25 % Mehrkosten durch Change Orders, da Stakeholder beim Kontakt mit der arbeitenden Software ihre Vorstellungen verfeinern. Der angebotene Preis ist ein Mindestpreis für einen festen Scope, keine Kostenobergrenze für ein sich veränderndes Produkt.
Wann Festpreis sinnvoll ist
- Kurze, klar definierte Projekte (8–16 Wochen), bei denen sich die Anforderungen während der Lieferung voraussichtlich nicht wesentlich ändern.
- Regulierte Beschaffungsumgebungen (öffentliche Hand, Enterprise-IT-Beschaffung), in denen vor der Vertragsfreigabe eine feste Budgetverpflichtung erforderlich ist.
- Konkrete Liefergegenstände: ein überarbeiteter Checkout-Flow, eine Datenmigration, eine Integration mit einer einzelnen Drittanbieter-API.
- Situationen, in denen der Kunde nur begrenzte Kapazität hat, das Tagesgeschäft der Lieferung zu steuern, und es vorzieht, den Erfolg von Anfang an zu definieren.
Ehrliche Nachteile des Festpreismodells
Festpreisverträge haben drei strukturelle Schwächen, die Käufer häufig unterschätzen:
- Aufpolsterung: Anbieter kalkulieren Unsicherheit in das Angebot ein. Bei einem unklaren Scope kann die Risikoprämie 20–40 % des Basisaufwands betragen. Sie zahlen für ein Risiko, das möglicherweise nie eintritt.
- Change-Order-Reibung: Jede Scope-Änderung wird zur Verhandlung. Bei einem sich weiterentwickelnden Produkt verlangsamt das die Iteration und schafft eine adversarielle Dynamik zwischen Kunde und Anbieter.
- Hemmt die Iteration: Festpreis belohnt die Lieferung genau dessen, was spezifiziert wurde, nicht das, was sich als wertvollstes erweist. Anbieter haben kaum Anreiz, bessere Ansätze mitten in der Lieferung anzusprechen, wenn die Spezifikation bereits vertraglich festgeschrieben ist.
Time & Materials: für tatsächlichen Aufwand bezahlen
Bei einem Time-and-Materials-Vertrag zahlen Sie für tatsächlich geleistete Stunden zu einem vereinbarten Satz (oder einem nach Rolle differenzierten Satzgefüge) zuzüglich direkter Ausgaben wie Cloud-Infrastruktur oder lizenziertem Tooling. Der Scope ist bei Vertragsunterzeichnung nicht festgeschrieben. Sie und der Anbieter können Arbeiten jederzeit im Verlauf des Engagements hinzufügen, entfernen oder neu priorisieren.
Wie T&M in der Praxis funktioniert
T&M läuft typischerweise in Sprints (ein oder zwei Wochen), wobei der Anbieter Stunden gegen Aufgaben in einem gemeinsamen Projektmanagement-Tool erfasst. Am Ende jedes Sprints erhalten Sie eine Rechnung für geleistete Stunden, die gegen den Sprint-Backlog geprüft werden. Ein guter T&M-Anbieter stellt detaillierte Zeitprotokolle und ein Burn-Rate-Dashboard bereit, sodass Sie immer wissen, wohin das Budget fließt. Ein Anbieter, der bei einem T&M-Engagement transparente Berichterstattung verweigert, ist ein Anbieter, den man meiden sollte.
T&M ergänzt sich natürlich mit agiler Lieferung: Der Backlog entwickelt sich jeden Sprint weiter, Prioritäten verschieben sich in Reaktion auf echtes Nutzerfeedback, und Sie zahlen nur für das, was tatsächlich gebaut wird. Lesen Sie unseren Leitfaden zur Softwareprojektschätzung, um zu erfahren, wie Sie ein Budgetmodell erstellen, selbst wenn der Scope offen ist.
Wann T&M sinnvoll ist
- Produkte in früher Discovery- oder MVP-Phase, bei denen Anforderungen mit dem Testen von Prototypen verfeinert werden.
- Laufende Feature-Entwicklung, bei der der Backlog kontinuierlich aus Nutzerfeedback und Geschäftsprioritäten gespeist wird.
- Projekte mit erheblicher Drittanbieter-Integrationskomplexität, bei denen der tatsächliche Aufwand erst nach der Erkundung bekannt sein kann.
- Situationen, in denen Sie intern die Product-Ownership-Kapazität haben, einen Backlog aktiv zu priorisieren und zu steuern.
Ehrliche Nachteile von T&M
T&M verlagert das Scope-Risiko auf den Kunden. Wenn sich die Anforderungen ausweiten, steigt die Rechnung. Ohne disziplinierte Backlog-Priorisierung auf Kundenseite können T&M-Engagements das Budget überschreiten. Das Modell erfordert Vertrauen: Sie verlassen sich darauf, dass die Zeitprotokolle des Anbieters korrekt sind. Es erfordert auch interne Managementkapazität — jemand auf Ihrer Seite muss den Backlog verantworten, Sprint-Reviews durchführen und Priorisierungsentscheidungen treffen. Für Kunden ohne Product Manager oder technischen Lead wird T&M ohne Struktur schnell teuer.
Dedicated Team: ein monatlich abgerechnetes festes Team
Im Dedicated-Team-Modell stellt der Anbieter ein stabiles, namentlich bekanntes Team zusammen — typischerweise 3–8 Entwickler, ein PM und QA — die ausschließlich an Ihrem Produkt arbeiten. Sie zahlen eine monatliche Pauschale, die Gehälter, Benefits, Management und Infrastruktur abdeckt. Der Anbieter übernimmt Besetzung, Bindung, HR und Teamkontinuität. Sie steuern die Arbeit: Sie besitzen den Backlog, leiten (oder nehmen teil an) den Standups und setzen die Prioritäten.
Wie ein Dedicated Team in der Praxis funktioniert
Das Onboarding eines Dedicated Teams dauert zwei bis vier Wochen: Teamauswahl, Umgebungszugang, Codebase-Einführung und Tooling-Setup. Danach arbeitet das Team an Ihrem Produkt, als wäre es eine erweiterte interne Engineering-Abteilung. Die monatliche Abrechnung ist planbar — der Satz ändert sich nur, wenn sich die Teamgröße ändert. Wissen akkumuliert sich im Team über die Zeit: Die Entwickler lernen Ihre Domäne, Ihre Codebasis und Ihre Nutzer kennen, was die Liefergeschwindigkeit mit zunehmender Dauer des Engagements steigert.
Dedicated Teams sind das Engagement-Modell, das dem größten Teil dessen zugrunde liegt, was die Branche „Software-Outsourcing" nennt. Einen Vergleich mit Staff Augmentation finden Sie in unserem Artikel zu Staff Augmentation vs. Managed Services. Für einen vollständigen Vergleich der Ressourcierungsmodelle beschreiben die Serviceseiten Dedicated Development Teams und Staff Augmentation, wie jedes Modell bei YuSMP funktioniert.
Wann ein Dedicated Team sinnvoll ist
- Langfristige Produktarbeit (6+ Monate), bei der Wissensretention und Liefergeschwindigkeit sich über die Zeit aufbauen.
- Produkte, bei denen die Kontinuität der Teamzusammensetzung wichtig ist: Dieselben Entwickler, die das Feature gebaut haben, sind diejenigen, die es pflegen und weiterentwickeln.
- Unternehmen, die Engineering-Kapazität skalieren, ohne die Kosten und den Zeitaufwand von Direkteinstellungen (Recruiting, Benefits, Büro, Recht).
- Produktweiterentwicklung nach dem Launch: Nach einem MVP- oder v1-Launch handhabt ein Dedicated Team den kontinuierlichen Verbesserungszyklus effizienter als wiederholte Festpreisverträge.
Ehrliche Nachteile von Dedicated Teams
Ein Dedicated Team ist eine monatliche Verpflichtung. Anders als bei T&M, wo Sie für einen Monat den Sprint-Scope reduzieren können, hat ein Dedicated Team unabhängig davon, ob Sie genug Arbeit haben, Personalkosten. Wenn Ihre Produkt-Roadmap Lücken oder Unsicherheiten aufweist, können Sie sich dabei ertappen, für ein unterausgelastetes Team zu zahlen. Die Reduzierung (Personalabbau) ist auch langsamer als das Pausieren eines T&M-Sprints — Teammitglieder brauchen Übergangszeit und vertragliche Kündigungsfristen. Dedicated Teams sind nicht das richtige Modell für ein Einzel-Lieferprojekt mit einem definierten Enddatum.
Vergleichstabelle: alle drei Modelle
| Dimension | Festpreis | Time & Materials | Dedicated Team |
|---|---|---|---|
| Scope-Risikoträger | Anbieter trägt Überschreitungsrisiko für vereinbarten Scope | Kunde trägt Risiko der Scope-Ausweitung | Kunde steuert Backlog; Anbieter trägt Personalrisiko |
| Flexibilität | Gering — Änderungen erfordern einen formellen Change Order | Hoch — Prioritäten können jeden Sprint wechseln | Hoch — Backlog vollständig vom Kunden kontrolliert |
| Abrechnung | Meilensteinbasiert oder Gesamtzahlung bei Lieferung | Pro Sprint (wöchentlich oder zweiwöchentlich), tatsächliche Stunden | Monatliche Pauschale, planbare Laufrate |
| Bester Projekttyp | Kurz, klar definiert, stabile Anforderungen | Sich entwickelndes Produkt, Discovery, MVP-Iteration | Langfristiges Produkt, laufende Roadmap |
| Transparenzbedarf | Gering während Lieferung (ergebnisbasiert) | Hoch — erfordert detaillierte Zeitprotokolle und Burn-Tracking | Mittel — Sprint-Velocity und Teamauslastung |
| Anlaufgeschwindigkeit | Langsam (Spec-first) — 4–8 Wochen bis Vertragsabschluss | Schnell — Start innerhalb 1–2 Wochen möglich | Mittel — 2–4 Wochen Onboarding |
| Wissensretention | Gering — Anbieterteam löst sich nach Lieferung auf | Mittel — abhängig von Teamkontinuität | Hoch — dasselbe Team akkumuliert Domänenwissen |
Wie Sie wählen: ein Entscheidungsrahmen
Das richtige Engagement-Modell ergibt sich aus vier Fragen zu Ihrem Projekt. Arbeiten Sie diese der Reihe nach durch:
1. Wie klar können Sie den Scope heute definieren?
Wenn Sie User Stories, Wireframes und Akzeptanzkriterien formulieren können, die sich bis zum Launch voraussichtlich nicht wesentlich ändern werden, ist Festpreis eine tragfähige Option. Wenn Sie das nicht können — weil das Produkt noch in der Discovery-Phase ist, weil Ihre Nutzer die Kernannahmen noch nicht validiert haben oder weil der technische Ansatz unsicher ist — wird Festpreis teure Change Orders und adversarielle Spezifikationsverhandlungen erzeugen. Wählen Sie stattdessen T&M oder einen phasenweisen Ansatz.
2. Wie schnell werden sich die Anforderungen während der Lieferung ändern?
Produkte mit schnellen Iterationszyklen, User-Testing-Schleifen oder kompetitiven Märkten überleben selten intakt von der Spezifikation bis zum Launch. Festpreis bestraft Veränderungen. Wenn Sie erwarten, während der Lieferung mindestens einmal zu pivoten oder umzupriorisieren, gibt Ihnen T&M oder ein Dedicated Team die Flexibilität dazu, ohne den Vertrag nachzuverhandeln.
3. Wie lange wird das Engagement voraussichtlich laufen?
Für Projekte unter vier Monaten sind Festpreis oder T&M in der Regel die praktischste Wahl — ein Dedicated Team braucht zwei bis vier Wochen Onboarding und ist für dauerhaften Durchsatz optimiert, nicht für kurze Sprints. Für Projekte über sechs Monate wird ein Dedicated Team typischerweise kosteneffektiver: Sie eliminieren den Overhead wiederholter Vertragsverhandlungen, das Team akkumuliert Domänenwissen, das die Lieferung beschleunigt, und die monatliche Laufrate ist für die Finanzplanung planbar.
4. Wie viel interne Managementkapazität haben Sie?
T&M und Dedicated Teams erfordern einen aktiven Product Owner auf Ihrer Seite: jemanden, der an Standups teilnimmt, Backlog-Einträge schreibt und priorisiert, Sprint-Demos reviewt und Entscheidungen trifft. Wenn Sie diese Kapazität nicht intern haben, driftet T&M ohne Struktur und Dedicated Teams erbringen keine optimale Leistung. Festpreis lagert mehr des täglichen Managements an den Anbieter aus — auf Kosten von Flexibilität und Change-Order-Reibung. Seien Sie ehrlich hinsichtlich Ihrer internen Kapazität, bevor Sie wählen.
Hybride in der Praxis
In der Praxis kombinieren die kosteneffektivsten Engagements oft alle drei Modelle über einen Produktlebenszyklus. Hier ist das Muster, das wir am häufigsten bei US- und EU-Kunden beobachten:
Phase 1: Festpreis-Discovery (4–6 Wochen)
Eine eng begrenzte Discovery-Phase — Anforderungsworkshops, technisches Architekturdesign, UX-Wireframes, Risikoidentifikation — ist ein ideales Festpreis-Engagement. Der Liefergegenstand ist eine definierte Spezifikation und eine glaubwürdige Schätzung für die Build-Phase. Die Kosten sind planbar ($15.000–$30.000 sind typisch), und das Ergebnis eliminiert den größten Teil der Unsicherheit, die andernfalls ein T&M- oder Festpreis-Build-Angebot aufblähen würde.
Phase 2: T&M-Build (3–9 Monate)
Mit einer soliden Spezifikation aus der Discovery gibt Ihnen T&M für die Build-Phase die Flexibilität, sich anzupassen, während die arbeitende Software Anforderungen offenbart, die auf dem Papier undurchsichtig waren. Priorisierung auf Sprint-Ebene hält das Team fokussiert auf die wertvollste Arbeit. Wenn der Scope nach der Discovery wirklich stabil ist, ist auch ein Festpreis-Build praktikabel — aber T&M hat in der Regel niedrigere Gesamtkosten, weil es die Risikoprämie des Anbieters eliminiert.
Phase 3: Dedicated Team für laufende Weiterentwicklung (6+ Monate)
Nach dem Launch tritt die meisten Produkte in einen kontinuierlichen Verbesserungszyklus ein: Nutzerfeedback treibt Feature-Ergänzungen, Performance-Optimierung, Integrationserweiterungen und Compliance-Updates voran. Ein Dedicated Team bewältigt diese Arbeit effizienter als eine Reihe von Festpreisverträgen, weil das Team die Codebasis und die Domäne bereits kennt. Die monatliche Abrechnung ist planbar, die Velocity ist konstant und Sie vermeiden die Anlaufkosten des erneuten Onboardings eines neuen Anbieterteams alle drei Monate.
Dieser phasenweise Ansatz — Festpreis-Discovery, T&M-Build, Dedicated Team für laufende Arbeit — ist nicht theoretisch. Er steckt hinter mehreren unserer mehrjährigen Kundenengagements, darunter die JoyJet Social Platform und der ANT PropTech Marketplace. Auf der Serviceseite Individuelle Softwareentwicklung erfahren Sie, wie wir diese Engagements in der Praxis strukturieren.
FAQ
Was ist der Unterschied zwischen Time & Materials und Festpreis?
Bei einem Festpreisvertrag nennt der Anbieter einen Gesamtpreis für einen definierten Scope und trägt das Überschreitungsrisiko. Bei einem Time-and-Materials-Vertrag zahlen Sie für tatsächlich geleistete Stunden zu einem vereinbarten Satz, sodass sich der Scope frei weiterentwickeln kann, Sie aber das Risiko steigender Kosten tragen. Festpreis eignet sich für klar definierte, kurze Projekte. T&M eignet sich für explorative oder iterative Arbeiten, bei denen sich Anforderungen voraussichtlich ändern werden. Informationen zu Projektkosten finden Sie in unserem Leitfaden zu den Kosten individueller Softwareentwicklung.
Wann sollte ich das Dedicated-Team-Modell nutzen?
Das Dedicated-Team-Modell ist sinnvoll, wenn Sie laufende, langfristige Produktarbeit haben — typischerweise sechs Monate oder länger — und ein stabiles, fest eingeplantes Team wünschen, das über die Zeit Domänenwissen aufbaut. Sie zahlen eine planbare monatliche Rate und steuern den Backlog direkt. Es ist weniger geeignet für Einmalprojekte mit einem klar definierten Abschlussdatum, bei denen Festpreis oder T&M besser passen. Details finden Sie auf unserer Serviceseite Dedicated Development Teams.
Bedeutet Festpreis, dass ich nicht mehr als das Angebot zahle?
Nicht immer. Festpreisverträge enthalten ein Scope-Dokument und eine Change-Order-Klausel. Wenn Sie Arbeiten außerhalb des vereinbarten Scopes beauftragen, erstellt der Anbieter einen Change Order mit Zusatzkosten. Bei den meisten Festpreisprojekten entstehen 10–25 % Mehrkosten durch Change Orders, da sich Anforderungen unweigerlich weiterentwickeln, sobald die Entwicklung begonnen hat. Der Angebotspreis ist ein Mindestpreis für den vereinbarten Scope, keine Kostenobergrenze für ein sich veränderndes Produkt.
Ist Time & Materials teurer als Festpreis?
T&M ist nicht grundsätzlich teurer — es hängt von der Scope-Definition ab. Für ein präzise spezifiziertes Projekt kann Festpreis günstiger sein, weil der Anbieter effizient planen kann. Für ein Projekt mit sich ändernden Anforderungen ist T&M in der Regel günstiger: Festpreisanbieter polstern Angebote auf, um Scope-Unsicherheiten abzufedern, und diese Risikoprämie ist echtes Geld, das Sie zahlen, unabhängig davon, ob das Risiko eintritt.
Kann ich das Engagement-Modell mitten im Projekt wechseln?
Ja, und viele erfolgreiche Projekte tun genau das. Ein gängiges Hybrid: Festpreis-Discovery, gefolgt von einer T&M-Build-Phase, gefolgt von einem Dedicated Team für die laufende Produktweiterentwicklung. Ein Modellwechsel erfordert eine Nachverhandlung des Vertrags, ist aber völlig normal und häufig der kosteneffektivste Ansatz über den Produktlebenszyklus. Details finden Sie im Abschnitt Hybride in der Praxis oben.
Zuletzt aktualisiert am 9. Juni 2026. Beschreibungen der Engagement-Modelle spiegeln die gängige Branchenpraxis und die Kundenerfahrung von YuSMP Group bei der Softwareentwicklung für US- und EU-Unternehmen wider. Vertragsbedingungen variieren je nach Anbieter; betrachten Sie diesen Artikel als Rahmen, nicht als Rechtsberatung.
