Preisgestaltung von Softwareprojekten für EU-Kunden: Festpreis, Time-and-Materials und Retainer im Vergleich
Eine falsch kalkulierte Software-Zusammenarbeit ist einer der schnellsten Wege in eine Situation, die niemand will: Margen auf null, ein Kunde, der sich über den Tisch gezogen fühlt, oder ein Vertragsstreit, der eine ansonsten solide Arbeitsbeziehung vergiftet. Trotzdem geht die Diskussion über die Preisgestaltung von Softwareprojekten selten über "wir machen Festpreis" oder "wir bevorzugen T&M" hinaus. Die eigentliche Frage lautet: Welches Modell passt zu welcher Art von Arbeit, und was muss im Vertrag stehen, damit beide Seiten geschützt sind?
Dieser Beitrag zerlegt die drei zentralen Preismodelle in EU-Softwareprojekten, zeigt, wann welches sinnvoll ist, und benennt die Risikofolgen, über die meist erst gesprochen wird, wenn etwas schiefgeht.
Die drei Modelle auf einen Blick
Festpreis bedeutet: definierter Scope, definiertes Ergebnis, eine vereinbarte Zahl. Der Kunde kennt die Gesamtkosten vorab. Der Dienstleister trägt den Scope Creep.
Time-and-Materials (T&M) bedeutet: Der Kunde zahlt für tatsächlich geleistete Stunden, üblicherweise zu einem vereinbarten Stunden- oder Tagessatz. Der Scope kann sich bewegen, der Kunde trägt die Kosten der Änderungen.
Retainer bedeutet: Der Kunde zahlt eine regelmäßige, wiederkehrende Pauschale, meist monatlich, für ein definiertes Maß an Verfügbarkeit. Geleistete Arbeit wird gegen dieses Kontingent verrechnet.
Jedes Modell verschiebt das Risiko in eine andere Richtung. Zu verstehen, wer welches Risiko trägt, ist nützlicher als jede pauschale Empfehlung, welches Modell "besser" sei.
Festpreis: Wann er funktioniert und wann er nach hinten losgeht
Festpreisverträge funktionieren gut, wenn die Anforderungen wirklich stabil sind. Wenn Du einem Dienstleister ein Spezifikationsdokument übergeben, Dich zurückziehen und ein System erwarten kannst, das dazu passt, dann ist Festpreis sauber und planbar.
In der Praxis beschreibt dieses Szenario eine Minderheit von Softwareprojekten. Anforderungen verschieben sich. Stakeholder ändern ihre Meinung, sobald sie den ersten Build sehen. Technische Randbedingungen tauchen auf, die beim Scoping nicht sichtbar waren. Jede dieser Änderungen landet entweder beim Dienstleister, der die Kosten schluckt und seine Marge verliert, oder sie löst einen Change-Request-Prozess aus, der das Projekt ausbremst.
Die EU-Besonderheit: Gerade im deutschen und österreichischen Vertragsrecht schafft der Werkvertrag klare Pflichten rund um die Lieferung eines konkreten Ergebnisses. Eine Festpreis-Zusammenarbeit, die fälschlich als Werkvertrag eingeordnet wird, oder korrekt eingeordnet, aber schlecht spezifiziert ist, kann Dienstleister auch nach der Abnahme noch Gewährleistungsansprüchen aussetzen. Wer Festpreisarbeit für deutsche oder österreichische Kunden kalkuliert, sollte die Vertragsklauseln zu Abnahme und Mängelhaftung sehr genau prüfen.
Wann Festpreis sinnvoll ist:
- Der Scope ist vollständig dokumentiert und beide Seiten sind sich einig, dass er eingefroren ist
- Das Projekt ist kurz genug (unter 8 bis 10 Wochen), sodass Anforderungsdrift unwahrscheinlich ist
- Das Ergebnis ist gut verstanden und vergleichbar mit früheren Arbeiten, das Schätzrisiko ist also gering
- Der Kunde braucht Budgetsicherheit für interne Freigabeprozesse
Wann er nach hinten losgeht:
- Die Anforderungen sind vage definiert nach dem Motto "das klären wir unterwegs"
- Der Kunde will während des Projekts noch Designentscheidungen treffen
- Der Technologie-Stack enthält relevante Unbekannte
- Das Projekt läuft lange genug, dass sich die Geschäftsprioritäten vor der Auslieferung ändern
Das klassische Fehlermuster ist ein Festpreisvertrag auf unscharfem Scope, der in eine zähe Verhandlung darüber mündet, was "drin" war und was ein Change Request ist. Beide Seiten verlieren.
Time-and-Materials: Flexibilität hat ihren Preis
T&M beseitigt das Problem des eingefrorenen Scopes. Der Kunde kann die Richtung ändern, der Dienstleister rechnet die tatsächlich geleistete Arbeit ab, und es gibt keinen Anreiz, Schätzungen aufzublasen oder Probleme zu verschweigen, um Change Orders zu vermeiden. Für komplexe, sich entwickelnde Softwareprojekte, etwa individuelle Softwareentwicklung, Plattform-Builds oder jede Greenfield-Arbeit, bei der die Produktform noch gefunden wird, ist T&M oft das ehrlichere Modell.
Das Risiko verschiebt sich vollständig zum Kunden. Eine offene T&M-Zusammenarbeit ohne Budgetleitplanken kann deutlich über das Ziel hinausschießen. Kunden, die noch nie ein T&M-Projekt gesteuert haben, unterschätzen oft, wie schnell sich Stunden summieren, besonders in frühen Phasen, in denen Architekturentscheidungen mehrfach neu bewertet werden.
T&M-Risiko für Kunden steuern:
Gute T&M-Projekte haben Budgetobergrenzen pro Sprint oder Phase, regelmäßige Soll-Ist-Abgleiche und einen klaren Eskalationsweg, bevor eine Phase überzogen wird. Es ist nicht die Pflicht des Dienstleisters, das durchzusetzen, aber ein Dienstleister, der Kostensignale nicht proaktiv anspricht, dient dem Kunden schlecht.
Die EU-Steuer- und Rechnungsebene: T&M-Rechnungen über EU-Grenzen hinweg haben umsatzsteuerliche Folgen, denen auch Festpreisrechnungen nicht entkommen. Der monatliche Rhythmus der T&M-Abrechnung macht sie nur operativ sichtbarer. Für B2B-Leistungen zwischen EU-Mitgliedstaaten greift das Reverse-Charge-Verfahren, aber der Verwaltungsaufwand ist real, gerade wenn aus Deutschland oder den Niederlanden nach Frankreich oder Spanien fakturiert wird. Plane das in Deinen Abrechnungsrhythmus ein und lege die steuerliche Behandlung im Vertrag ausdrücklich fest.
Wann T&M sinnvoll ist:
- Das Projekt hat komplexe oder sich entwickelnde Anforderungen
- Der Kunde will laufend bei Priorisierung und Richtung mitentscheiden
- Zwischen Dienstleister und Kunde besteht ein etabliertes Vertrauensverhältnis
- Die Arbeit erstreckt sich über einen langen Zeitraum (sechs Monate oder mehr)
- Tempo ist wichtiger als Kostensicherheit
Retainer: Das Modell, das die Beziehung verändert
Ein Retainer ist kein Projektmodell, sondern ein Beziehungsmodell. Der Kunde kauft kein Ergebnis, er kauft Kapazität und Verfügbarkeit. Dieser Unterschied ist entscheidend dafür, wie Du Arbeit und Vertrag strukturierst.
Retainer funktionieren am besten bei laufenden Entwicklungspartnerschaften: ein Team, das die Webanwendung eines Kunden dauerhaft betreut, ein Berater, der in einem Produktteam eingebettet ist, oder eine Legacy-Code-Optimierung, bei der die Codebasis über längere Zeit Aufmerksamkeit braucht statt einer einmaligen Reparatur.
Für Kunden liegt der Reiz in Planbarkeit und bevorzugtem Zugriff. Sie wissen, dass der Berater oder das Team jeden Monat für sie verfügbar ist. Für Dienstleister liegt der Reiz in stabilen Umsätzen. Monatlich wiederkehrende Einnahmen lassen sich leichter planen als Projekt-für-Projekt-Geschäft.
Das häufigste Fehlermuster: Retainer scheitern, wenn unklar ist, was "enthalten" ist. Wenn ein Kunde mit einem 20-Stunden-Retainer anfängt, ihn wie 40 Stunden zu behandeln, weil er Wartung von Bugfixes bis zur Neuentwicklung versteht, verschlechtert sich die Beziehung schnell. Der Vertrag muss genau definieren, was der Retainer abdeckt, wie mit ungenutzten Stunden umgegangen wird (Übertrag oder Verfall) und was ein Gespräch über Zusatzleistungen auslöst.
Retainer-Strukturen, die sich lohnen:
- Kapazitäts-Retainer: X Stunden pro Monat, verfügbar für alles, was der Kunde braucht, ungenutzte Stunden verfallen. Einfach und sauber.
- Meilenstein-Retainer: Monatliche Pauschale, gekoppelt an konkrete laufende Leistungen (zum Beispiel monatliche Performance-Reports, regelmäßige Deployments, Rufbereitschaft mit definierten SLAs). Höherer Steuerungsaufwand, dafür klarere Verantwortlichkeit.
- Hybrid: Grund-Retainer für Verfügbarkeit und Support, dazu T&M-Abrechnung für Entwicklungsarbeit oberhalb einer Schwelle.
Wann ein Retainer sinnvoll ist:
- Der Kunde hat kontinuierlichen Bedarf statt eines abgegrenzten Projekts
- Der Kunde schätzt Verfügbarkeit und Reaktionsfähigkeit höher als reinen Output
- Der Dienstleister will planbare Umsätze und ist bereit, Kapazität sorgfältig zu steuern
- Die Beziehung ist gefestigt genug, dass beide Seiten einander bei den Stunden vertrauen
Risikoprofile im direkten Vergleich
| Festpreis | Time-and-Materials | Retainer | |
|---|---|---|---|
| Wer trägt das Scope-Risiko | Dienstleister | Kunde | Geteilt |
| Kostenplanbarkeit für den Kunden | Hoch | Niedrig | Mittel |
| Umsatzplanbarkeit für den Dienstleister | Mittel | Niedrig | Hoch |
| Passend für | Kurze, klar definierte Projekte | Komplexe, sich entwickelnde Arbeit | Laufende Partnerschaften |
| Vertragskomplexität | Mittel (Change-Order-Prozess) | Niedrig (Satz + Stunden) | Mittel (Scope-Definition) |
| Exponierung im EU-Vertragsrecht | Höher (Werkvertrag in DE/AT) | Niedriger | Niedriger |
Praktische Hinweise für EU-Projekte
Ein paar Punkte, die bei der Kalkulation für EU-Kunden immer wieder auftauchen:
Zahlungsbedingungen sauber regeln. Gewerbliche EU-Kunden, gerade größere in Frankreich, Spanien und Italien, arbeiten standardmäßig oft mit 60 oder sogar 90 Tagen Zahlungsziel. Wer an netto 30 gewöhnt ist, riskiert bei einem T&M-Projekt mit einem großen französischen Konzern eine ernsthafte Liquiditätslücke. Verhandle Zahlungsziele ausdrücklich und ziehe kürzere Abrechnungszyklen in Betracht (bei T&M zweiwöchentlich), um das Risiko zu senken.
Das anwendbare Recht ist wichtiger, als Du denkst. Ein Vertrag zwischen einem deutschen Dienstleister und einem spanischen Kunden, der deutsches Recht und deutschen Gerichtsstand festlegt, ist etwas wert. Einer ohne Rechtswahl lädt zum Streit darüber ein, welche Jurisdiktion gilt. Für grenzüberschreitende EU-Projekte ist das einen Absatz im Vertrag wert.
Change Orders immer schriftlich. In jedem Modell erzeugen mündliche Absprachen über Scope-Änderungen Streit. Eine einfache E-Mail-Bestätigung, von beiden Seiten schriftlich quittiert, ist das Minimum. Beim Festpreis ist eine formale, beidseitig unterschriebene Change Order die Reibung wert.
Discovery-Phasen senken das Festpreisrisiko. Wenn ein Kunde für ein komplexes Projekt auf Festpreis besteht, senkt eine bezahlte Discovery-Phase (T&M oder ein kleiner Festpreisauftrag) zur Klärung der Anforderungen vor dem Hauptvertrag das Risiko auf beiden Seiten deutlich. Sie baut außerdem Vertrauen auf, bevor das größere Projekt startet.
Das richtige Modell wählen
Es gibt keine allgemeingültig richtige Antwort. Das passende Modell hängt davon ab, wie klar der Scope definiert ist, wer mehr finanzielles Risiko tragen kann, wie lang und komplex die Arbeit ist und wie gereift die Beziehung zwischen Dienstleister und Kunde ist.
Für ein kurzes, klar spezifiziertes Projekt mit einem Kunden, der ein festes Budget braucht: Festpreis. Für einen komplexen Plattform-Build, bei dem sich die Anforderungen entwickeln: T&M mit Budgettransparenz auf Sprint-Ebene. Für eine laufende Entwicklungspartnerschaft: Retainer mit sorgfältiger Scope-Definition.
Wenn Du mit einem Dienstleister oder Berater arbeitest und nicht sicher bist, welches Modell zu Deiner Situation passt: Das Gespräch über die Preisgestaltung ist auch ein Signal dafür, wie gut der Dienstleister die Natur der Arbeit versteht. Wer für vage spezifizierte Projekte auf Festpreis besteht, ist entweder sehr selbstbewusst oder trägt seinen Anteil am Risikodenken nicht mit.
Wenn Du Preismodelle für ein anstehendes Softwareprojekt bewertest oder eine bestehende Zusammenarbeit neu verhandelst, die nicht rund läuft, ist hello@wolf-tech.io ein guter Startpunkt für dieses Gespräch. Wolf-Tech arbeitet mit EU-Kunden an individueller Softwareentwicklung, Webanwendungsentwicklung und Tech-Stack-Strategie und hilft dabei, das Zusammenarbeitsmodell neben der technischen Arbeit zu strukturieren.