Veröffentlicht am 12. Apr. 2026·15 Min. Lesezeit
Festpreis oder monatlicher Retainer: Was passt besser zu Softwareprojekten?
Preisgestaltung in der Software ist nicht so einfach, wie viele erwarten. Festpreis, monatlicher Retainer, Stundensatz, Hybrid. Jedes Modell passt zu einer anderen Art Projekt. Das falsche Modell schafft mehr Risiko, als es verhindert.
Stefan Hilaj
CEO & Gründer
Wenn Unternehmen ein Softwareprojekt starten, geht es meist als Erstes um den Preis.
"Was wird das kosten?"
Das ist eine berechtigte Frage. Jedes Unternehmen braucht ein Budget. Jedes Projekt braucht finanzielle Kontrolle. Niemand startet gern eine Entwicklung, ohne die Investition zu kennen.
Aber in der Software ist Preisgestaltung nicht so einfach, wie viele erwarten.
- Manche Projekte funktionieren gut mit einem Festpreis.
- Manche Projekte brauchen einen monatlichen Retainer.
- Manche Projekte laufen besser auf Stundenbasis.
- Manche brauchen ein hybrides Modell.
Das Problem: Viele Unternehmen wählen das falsche Preismodell, weil sie Risiko senken wollen. Aber das falsche Modell kann Risiko sogar erhöhen.
Die eigentliche Frage lautet also nicht nur: "Was kostet es?" Die bessere Frage lautet: "Welches Preismodell gibt diesem Projekt die besten Erfolgschancen?"
Warum diese Entscheidung zählt
Softwareprojekte sind nicht immer vorhersehbar.
Eine einfache Website mit klarer Struktur lässt sich recht genau schätzen. Aber ein individuelles CRM, eine SaaS-Plattform, eine Mobile App, ein internes Tool, eine KI-Automatisierung, ein Marktplatz oder eine komplexe Integration sind etwas anderes. Da gibt es mehr Unbekannte.
- Anforderungen ändern sich.
- Nutzende geben Feedback.
- Technische Grenzen tauchen auf.
- Neue Ideen kommen dazu.
- Integrationen verhalten sich anders als erwartet.
- Geschäftliche Prioritäten verschieben sich.
- Manche Funktionen erweisen sich als komplexer, als sie zunächst aussahen.
Das heißt nicht, dass Softwareentwicklung chaotisch sein muss. Es heißt, dass das Preismodell zur Realität des Projekts passen sollte.
Ist das Projekt klar und stabil, kann ein Festpreis gut funktionieren. Wird sich das Projekt entwickeln, ist ein Retainer oder ein flexibles Modell meist gesünder.
Was ist ein Festpreisprojekt?
Bei einem Festpreisprojekt werden Umfang, Zeitplan und Preis vor Entwicklungsbeginn vereinbart.
Zum Beispiel: Ein Unternehmen braucht eine Website mit 8 Seiten, einem Kontaktformular, einem Blog, einem CMS und einem SEO-Grundsetup. Die Agentur schätzt den Aufwand, definiert den Leistungsumfang, nennt einen Festpreis und liefert auf dieser Basis.
Dieses Modell kann gut sein, wenn der Umfang klar ist:
- Der Kunde weiß, was er bekommt.
- Die Agentur weiß, was sie liefern muss.
- Das Budget ist vorab vereinbart.
- Das Projekt hat klare Grenzen.
Für einfache, klar definierte Projekte kann der Festpreis die richtige Wahl sein. Aber er funktioniert nur gut, wenn alle den Umfang klar verstehen. Das ist der entscheidende Punkt.
Wann der Festpreis am besten passt
Der Festpreis passt am besten, wenn die Unsicherheit gering ist.
Zum Beispiel:
- Eine Marketing-Website mit klarer Sitemap.
- Eine Landingpage.
- Ein kleines Redesign.
- Ein einfaches E-Commerce-Setup.
- Ein klar definiertes Featurepaket.
- Eine technische Migration mit bekannten Anforderungen.
- Ein kurzes Projekt mit begrenzter Komplexität.
In diesen Fällen gibt der Festpreis Struktur. Der Kunde kann ein klares Budget freigeben. Das Team kann die Arbeit planen. Das Projekt kommt ohne ständige Budgetdiskussionen voran.
Aber auch bei Festpreisprojekten muss der Umfang sauber dokumentiert sein:
- Welche Seiten sind enthalten?
- Wie viele Designrunden?
- Welche Integrationen sind enthalten?
- Wer liefert die Inhalte?
- Was ist nicht enthalten?
- Was passiert, wenn sich der Umfang ändert?
Das Problem mit dem Festpreis
Der Festpreis klingt für Kunden sicher. Aber er kann falsche Anreize setzen, wenn das Projekt nicht klar definiert ist.
- Unterschätzt die Agentur den Aufwand, versucht sie womöglich, schneller fertig zu werden, um ihre Marge zu schützen.
- Entdeckt der Kunde während der Entwicklung neue Bedarfe, wird jede Änderung zur Verhandlung.
- Ist der Umfang unklar, legen beide Seiten die Vereinbarung womöglich unterschiedlich aus.
- Ist das Projekt komplex, beruht der Festpreis vielleicht auf Annahmen, die sich später als falsch erweisen.
Dann fangen die Probleme an.
Der Kunde sagt: "Wir dachten, das wäre enthalten." Die Agentur sagt: "Das war nicht Teil des Umfangs." Der Kunde sagt: "Diese Änderung ist klein." Die Agentur sagt: "Sie betrifft Struktur, Zeitplan und Budget."
Niemand hat zwingend unrecht. Das Preismodell ist für dieses Projekt schlicht nicht flexibel genug.
Ein Festpreis kann in der falschen Situation teuer werden. Nicht, weil sich der Preis ändert, sondern weil das Projekt langsamer, starrer und anstrengender wird.
Was ist ein monatlicher Retainer?
Bei einem monatlichen Retainer reserviert der Kunde jeden Monat eine bestimmte Menge Zeit oder Kapazität. Statt eines Festpreises für das gesamte Projekt zahlt er monatlich für laufende Entwicklung, Design, Support oder Wachstumsarbeit.
Zum Beispiel: Ein Unternehmen bezahlt 60 Stunden pro Monat, um seine digitale Plattform weiterzuentwickeln. Diese Stunden können für neue Funktionen, Fehlerbehebungen, Designverbesserungen, Integrationen, Support, technische Beratung, Reporting oder laufende Optimierung genutzt werden.
Dieses Modell ist nützlich, wenn das Projekt keine einmalige Lieferung ist. Es passt besser zu Produkten und Systemen, die laufende Verbesserung brauchen.
Wann der monatliche Retainer am besten passt
Ein monatlicher Retainer passt am besten, wenn die Arbeit laufend ist oder sich entwickelt.
Zum Beispiel:
- Ein SaaS-Produkt.
- Ein individuelles CRM.
- Ein Kundenportal.
- Eine interne Geschäftsplattform.
- Eine Mobile App, die laufend aktualisiert wird.
- Ein Onlineshop mit regelmäßigen Verbesserungen.
- Eine Partnerschaft aus Marketing und Entwicklung.
- Eine Plattform mit häufigem Kundenfeedback.
- Ein Produkt, das nach dem Launch Support braucht.
- Ein Unternehmen, das einen langfristigen digitalen Partner sucht.
In diesen Fällen bleibt der Umfang nicht eingefroren. Und das ist normal.
- Sie launchen Version eins und verbessern dann auf Basis von Feedback.
- Sie stellen fest, dass eine Funktion wichtiger ist als eine andere.
- Sie müssen dringende Probleme beheben.
- Sie müssen auf geschäftliche Prioritäten reagieren.
- Sie müssen später Integrationen ergänzen.
Ein monatlicher Retainer gibt Flexibilität. Das Team kann sich jeden Monat auf das Wichtigste konzentrieren, statt an einen Umfang gebunden zu sein, der geschrieben wurde, bevor alle das Produkt richtig verstanden hatten.
Die Vorteile eines monatlichen Retainers
Der größte Vorteil eines Retainers ist Flexibilität. Sie können Prioritäten anpassen, wenn sich das Geschäft ändert.
- Taucht etwas Dringendes auf, kann das Team es übernehmen.
- Wird eine Funktion unwichtiger, kann sie verschoben werden.
- Zeigt Nutzerfeedback eine bessere Richtung, kann sich die Roadmap ändern.
- Ist Wartung nötig, kann sie enthalten sein.
- Ergibt sich eine neue Chance, kann das Team schneller reagieren.
Ein Retainer schafft außerdem Kontinuität. Das Team versteht Ihr Produkt mit der Zeit besser.
- Es kennt die Codebasis.
- Es kennt Ihr Geschäft.
- Es kennt Ihre Nutzenden.
- Es kennt Ihre Prioritäten.
- Es kennt die Geschichte hinter den Entscheidungen.
Das macht die Arbeit schneller und besser. Bei Festpreisprojekten liefert das Team womöglich ab und geht. Mit einem Retainer bleibt es dabei und verbessert das System weiter.
Das ist oft besser für Unternehmen, die Software als Teil ihres Geschäfts sehen und nicht als einmalige Ausgabe.
Das Risiko eines monatlichen Retainers
Ein Retainer ist nicht automatisch besser. Er braucht Struktur.
Ohne klare Planung wird ein Retainer schwammig. Der Kunde zahlt jeden Monat, sieht aber womöglich zu wenig Fortschritt. Die Agentur arbeitet an zu vielen Kleinigkeiten ohne klare Richtung. Prioritäten wechseln zu oft. Es gibt kein klares Reporting.
Ein Retainer braucht ordentliches Management. Es sollte geben:
- Einen klaren Monatsfokus.
- Ein Backlog mit Prioritäten.
- Sprintplanung.
- Aufgabenverfolgung.
- Budgettransparenz.
- Regelmäßige Updates.
- Berichte über erledigte Arbeit.
- Klare Kommunikation darüber, was als Nächstes kommt.
Festpreis vs. Retainer: der einfache Unterschied
Der Festpreis ist am besten, wenn das Ziel klar ist. Der monatliche Retainer ist am besten, wenn sich das Produkt entwickeln wird.
Der Festpreis sagt: "Das ist der vereinbarte Umfang. Das ist der vereinbarte Preis. Das werden wir liefern."
Der Retainer sagt: "Wir arbeiten laufend mit Ihnen, priorisieren, was am wichtigsten ist, und verbessern das Produkt Monat für Monat."
Keines der Modelle ist immer richtig. Das richtige hängt vom Projekttyp ab. Ein Festpreis gibt Sicherheit, wenn die Arbeit klar definiert ist. Ein Retainer gibt Flexibilität, wenn die Arbeit laufend ist.
Der Fehler ist, einen Festpreis für ein Projekt voller Unbekannter zu wählen. Der andere Fehler ist ein Retainer ohne klare Planung und Berichte.
Und was ist mit Stundenabrechnung?
Stundenarbeit ist eine weitere Option. Sie passt meist am besten zu kleinen Aufgaben, Support, Wartung, Fehlerbehebungen, Beratung oder Arbeit, die sich schlecht in einen festen Umfang packen lässt.
Zum Beispiel:
- Einen Fehler beheben.
- Eine Codebasis prüfen.
- Kleine Verbesserungen vornehmen.
- Eine Integration ergänzen.
- Dringenden Support leisten.
- Zur Architektur beraten.
- Die Performance verbessern.
- Änderungen an einem bestehenden System vornehmen.
Stundenarbeit ist flexibel, kann sich aber unberechenbar anfühlen, wenn es keine Schätzung gibt. Deshalb sollte auch sie klare Erwartungen haben. Vor dem Start sollte das Team die erwartete Spanne, mögliche Risiken und den Zeitpunkt nennen, zu dem es sich meldet, falls es länger dauert.
Das Hybridmodell ist oft die beste Option
Bei vielen Softwareprojekten ist das beste Modell weder Festpreis noch Retainer. Es ist ein Hybrid. Das heißt, für verschiedene Phasen verschiedene Preismodelle zu nutzen.
Zum Beispiel:
- Discovery-Phase: Festpreis.
- MVP-Entwicklung: fester Umfang oder geschätzte Spanne.
- Laufende Verbesserungen: monatlicher Retainer.
- Dringender Support: Stundenbasis.
- Große neue Funktionen: separat geschätzt.
Das ist oft der realistischste Ansatz. Am Anfang brauchen Sie vielleicht Discovery, um den Umfang zu klären. Dann bauen Sie eine erste Version. Nach dem Launch gehen Sie in einen Retainer für Verbesserungen, Support, Analytics und Wachstum über.
Das gibt dem Kunden Struktur am Anfang und Flexibilität nach dem Launch. Und es senkt das Risiko für beide Seiten.
Der Kunde verpflichtet sich nicht blind zu einem riesigen unbekannten Projekt. Der Entwicklungspartner verspricht keinen Festpreis für etwas, das noch nicht vollständig definiert ist.
Wie Sie das richtige Modell wählen
Bevor Sie ein Preismodell wählen, stellen Sie diese Fragen:
- Ist der Umfang sehr klar?
- Werden sich die Anforderungen während des Projekts ändern?
- Ist das eine einmalige Lieferung oder ein laufendes Produkt?
- Kennen wir bereits alle Integrationen?
- Werden Nutzende nach dem Launch Feedback geben?
- Brauchen wir laufenden Support?
- Ist Tempo wichtiger als fester Umfang?
- Ist Budgetsicherheit wichtiger als Flexibilität?
- Brauchen wir einen langfristigen Partner oder nur eine Lieferung?
- Ist der Umfang klar und stabil, kann ein Festpreis funktionieren.
- Wird sich das Projekt entwickeln, ist ein Retainer meist besser.
- Hat das Projekt viele Unbekannte, starten Sie mit Discovery.
- Ist das Projekt schon live und braucht laufende Verbesserungen, nutzen Sie Retainer oder Stundenbasis.
Worauf Kunden achten sollten
Egal welches Preismodell Sie wählen: Es gibt Warnzeichen.
Seien Sie vorsichtig, wenn ein Entwicklungspartner:
- Einen Festpreis nennt, ohne viele Fragen zu stellen.
- Nicht erklären kann, was enthalten und was ausgeschlossen ist.
- Gesprächen über Umfangsänderungen ausweicht.
- Für komplexe Arbeit keine Discovery-Phase anbietet.
- Für Retainer-Arbeit kein klares Reporting hat.
- Nicht erklären kann, wie Stunden erfasst werden.
- Den Fortschritt nicht regelmäßig zeigt.
- Nicht über Tests oder Support spricht.
- Zu viel zu schnell verspricht.
- Software wie eine einfache Checkliste behandelt.
Ein guter Partner nennt Ihnen nicht nur einen Preis. Er hilft Ihnen zu verstehen, wie das Projekt am besten strukturiert wird. Das gehört zum Wert dazu.
Wie wir bei Tetbit über Preise denken
Bei Tetbit glauben wir nicht, dass ein Preismodell zu jedem Projekt passt.
- Manche Projekte gehören zum Festpreis.
- Manche in monatliche Retainer.
- Manche sollten mit Discovery beginnen.
- Manche sollten nach Stunden abgerechnet werden.
- Manche brauchen ein Hybridmodell.
Wichtig ist, das Modell zu wählen, das das Projekt, den Kunden und die Qualität des Endprodukts schützt.
- Für klar umrissene Websites, Landingpages und definierte Lieferungen kann ein Festpreis sinnvoll sein.
- Für langfristige Softwareplattformen, CRMs, interne Tools, KI-Systeme und laufende Produktentwicklung funktionieren Retainer meist besser.
- Für bestehende Systeme, technische Verbesserungen und Supportarbeit sind Stunden- oder Monatspakete oft praktischer.
Wir glauben außerdem, dass Preisgestaltung transparent sein sollte. Kunden sollten verstehen, wofür sie zahlen, wie Arbeit geplant wird, wie Fortschritt berichtet wird und was passiert, wenn sich Prioritäten ändern.
Das beste Preismodell ist das, das zur Realität passt
Es gibt kein perfektes Preismodell. Es gibt nur das richtige für das Projekt, das vor Ihnen liegt.
- Der Festpreis gibt Klarheit, wenn der Umfang klar ist.
- Monatliche Retainer geben Flexibilität, wenn sich das Produkt weiterentwickelt.
- Stundenarbeit gibt Tempo bei kleineren oder unvorhersehbaren Aufgaben.
- Hybridmodelle geben Struktur und Flexibilität zugleich.
Der Fehler ist, jedes Projekt in dasselbe Modell zu pressen. Softwareentwicklung heißt nicht nur, Code zu schreiben. Es heißt, Entscheidungen zu treffen, Risiken zu steuern, sich an Veränderungen anzupassen und etwas zu bauen, das Wert schafft. Ihr Preismodell sollte das stützen. Nicht dagegen arbeiten.
Bevor Sie also fragen "Was kostet das?", fragen Sie: "Was für ein Projekt bauen wir hier eigentlich?" Die Antwort verrät Ihnen meist, welches Preismodell am meisten Sinn ergibt.
