Das passende Preismodell für Softwareprojekte wählen

Zeitabrechnung und Festpreis verteilen Unsicherheit bei Softwareprojekten unterschiedlich. Keines der Modelle garantiert geringere Gesamtkosten, höhere Qualität oder ein erfolgreiches Produkt. Entscheidend ist, welcher Vertrag und welche Lieferkontrollen zum aktuellen Scope, zu den Abhängigkeiten, zur Evidenz und zur Fähigkeit passen, die Richtung zu ändern.

Jedes Projekt ist anders. Wavect nutzt Zeitabrechnung, Festpreis und gestufte Vereinbarungen, je nachdem, was verantwortungsvoll abgrenzbar ist. Ein gestufter agiler Festpreis kann sinnvoll sein, wenn frühe Evidenz die Unsicherheit reduzieren soll, bevor begrenzte Deliverables bepreist werden.

Vergleiche vor der Wahl die jeweiligen Trade-offs und halte die kommerziellen Kontrollen im Vertrag fest. Das ist eine Engineering- und Delivery-Perspektive, keine Rechtsberatung.

Abrechnung nach Zeit

Der Anbieter rechnet gemessene Zeit zu vereinbarten Sätzen ab, häufig mit Budget, Kontingent oder Freigabeschwelle. Ziele und Prioritäten können klar sein, auch wenn der genaue Backlog anpassbar bleibt.

• Der Kunde bezahlt den tatsächlichen Aufwand. Deshalb sind Prognosequalität, Zeitnachweise, Rate Card und Freigaberegeln wichtig.
• Ohne Obergrenze oder Stop-Regel besteht weniger Budgetsicherheit. Rollierende Prognosen und klare Entscheidungspunkte reduzieren Überraschungen.
• Der Backlog bleibt anpassbarer, doch Änderungen können weiterhin Zeitplan, Kosten, Qualität und Abhängigkeiten beeinflussen.

Festpreis

Für ein definiertes Deliverable oder einen abgegrenzten Scope wird ein fixer Betrag vereinbart. Der Vertrag sollte Annahmen, Mitwirkungspflichten des Kunden, Abnahmekriterien, Ausschlüsse, Zahlungsmeilensteine und das Schätz- und Freigabeverfahren für Änderungen festhalten.

• Preisplanbarkeit hängt von der definierten Grenze ab. Anbieter können Unsicherheit einpreisen, den Scope begrenzen, einen Risikopuffer teilen oder Change Requests nutzen. Keine Reaktion ist automatisch.
• Klare Ergebnisse und Abnahmetests erzeugen Scoping-Aufwand. Nicht jedes Implementierungsdetail muss eingefroren werden, wenn der Vertrag kontrolliertes Lernen und Ändern ermöglicht.
• Eine Fehlschätzung erzeugt wirtschaftlichen Druck, doch Qualität muss nicht sinken. Definition of Done, Tests, Sicherheitsanforderungen, Abnahmenachweise, Eskalation und Scope-Entscheidungen sollten explizit bleiben.

Bei österreichischen Verträgen ist die von den Parteien verwendete Bezeichnung nicht die gesamte Analyse. § 1151 ABGB unterscheidet die Dienstleistung für eine gewisse Zeit von der entgeltlichen Herstellung eines Werks. Der aktuelle WKO-Leitfaden beschreibt den Werkvertrag als Verpflichtung zu einem ausreichend konkreten Ergebnis (RIS, ABGB § 1151) (WKO-Leitfaden zum Werkvertrag). Lass die tatsächliche Verteilung von Erfolg, Mitwirkung, Abnahme, Änderung, Zahlung, Gewährleistung und Beendigung von qualifizierter Rechtsberatung prüfen.

"Opfere den Plan nicht einer vermeintlichen Geschwindigkeit."

Agiler Festpreis

Agile Delivery beseitigt Planung und kommerzielle Governance nicht. Das Agile Manifesto begrüßt sich ändernde Anforderungen und häufige Lieferung. Der Scrum Guide ordnet komplexe Arbeit um Transparenz, Inspektion und Anpassung (Prinzipien des Agilen Manifests) (offizieller Scrum Guide). Keine der Quellen schreibt ein Preismodell vor.

Ein Planungsmuster für größere Projekte der individuellen Softwareentwicklung nutzt drei kommerzielle Phasen. Das ist ein beispielhaftes Wavect-Liefermuster, keine universelle Definition des agilen Festpreises.

Portabilität ist ebenfalls wichtig. Definiere für jede Phase Repository-Zugriff, Dokumentation, Umgebungen, Zugangsdaten, IP-Bedingungen und einen nutzbaren Übergabezustand. Das kann einen Anbieterwechsel erleichtern, verspricht aber keine Fortsetzung ohne Onboarding oder Nacharbeit.

1. Discovery-Phase

Discovery sollte Unsicherheiten reduzieren, die Produktwert, Machbarkeit, Lieferrisiko und Preis beeinflussen. Dauer und Ergebnisse hängen vom Projekt ab. Ziele können Betriebskosten senken, einen Investment Case prüfen oder ein marktfähiges Produkt veröffentlichen sein.

Vereinbare das Discovery-Deliverable vor Beginn. Es kann Entscheidungen, Annahmen, Risiken, User Journeys, Architekturoptionen, einen priorisierten Backlog, Schätzungen und nächste Optionen umfassen. Ein kurzes Konzept kann nützlich sein, doch die Seitenzahl belegt weder Vollständigkeit noch Portabilität.

Discovery-Evidenz ist nicht automatisch ein vollständiges Pflichtenheft oder Festpreisversprechen. Halte fest, was validiert wurde, was unsicher bleibt und wer als Nächstes entscheidet.

2. Testphase

Die Testphase implementiert genug vom riskantesten Pfad, um Annahmen durch Evidenz zu ersetzen.

Ein Zeitbudget oder begrenztes Kontingent kann Flexibilität erhalten, während das Team Komplexität, Abhängigkeiten, Nutzerfeedback und Lieferdurchsatz misst. Definiere Obergrenze, Stop-Regel und Freigabebefugnis vor dem Start.

Nutze einen Review-Rhythmus, der zu Risiko und Lieferzyklus passt. Berichte fertige Inkremente, verbleibende Unsicherheit, Budgetverbrauch, Prognose, Qualitätsnachweise und nötige Entscheidungen.

Prüfe am vereinbarten Entscheidungspunkt Produktstand und Backlog. Setze die Zeitabrechnung fort, stoppe, grenze neu ab oder überführe ausreichend begrenzte Ergebnisse in eine Finalisierungsphase.

Das Deliverable ist nicht zwingend ein MVP. Definiere den Exit-Zustand vertraglich, einschließlich Code, Tests, Dokumentation, Deployment-Artefakten, bekannten Fehlern, Lizenzen, Zugangsdaten und Abnahmenachweisen.

3. Finalisierungsphase

Wenn die verbleibenden Ergebnisse ausreichend begrenzt sind, lassen sie sich als Epics, User Stories, Abnahmeszenarien oder andere testbare Deliverables definieren und separat bepreisen.

Ein Festpreis kann für diese Grenze mehr Budgetsicherheit bieten, wenn Prioritäten, Ziele, Abhängigkeiten, Annahmen und Change Control verstanden sind.

Unsicherheiten bleiben bestehen. Benenne sie, weise Verantwortliche zu und definiere, was geschieht, wenn eine Annahme nicht hält.

Siehe auch: Unser Service Fractional CTO Österreich erklärt, wie wir technische Führungsmandate abgrenzen. Bestätige für das konkrete Mandat aktuelles Angebot, Verfügbarkeit, Kostenfaktoren, Befugnisse und Vertragsbedingungen.