Festpreis oder Zeithonorar bei Modernisierungsprojekten?

Festpreis oder Zeithonorar bei Ihrem Softwareprojekt? Bei der Modernisierung von Legacy-PHP entscheidet die Wahl über Risiko, Kosten und Ehrlichkeit. Was wirklich zu welcher Situation passt.

Die Frage kommt fast immer im ersten Gespräch: "Machen Sie das zum Festpreis oder auf Stundenbasis?" Hinter dieser Frage steckt selten reine Neugier. Sie steckt voller Angst vor der Kostenexplosion, vor dem Projekt, das nie fertig wird, vor der Rechnung, die am Ende doppelt so hoch ausfällt wie das Angebot. Diese Angst ist berechtigt. Aber die Antwort ist nicht so einfach, wie beide Modelle es versprechen.

Denn bei einem Modernisierungsprojekt reden wir nicht über eine neue Landingpage mit klarem Umfang. Wir reden über ein System, das seit Jahren oder Jahrzehnten läuft, dessen Fachlogik funktioniert, dessen Code drumherum aber niemand mehr vollständig versteht. Genau das macht die Wahl zwischen Festpreis und Zeithonorar beim Softwareprojekt zu einer strategischen Entscheidung, nicht zu einer Formsache.

Was ist der Unterschied zwischen Festpreis und Zeithonorar beim Softwareprojekt?

Beim Festpreis vereinbaren Sie einen definierten Umfang zu einem definierten Preis. Beim Zeithonorar (Time and Material) zahlen Sie die tatsächlich geleistete Arbeit nach Stunden- oder Tagessatz. Der entscheidende Unterschied liegt nicht im Preisschild, sondern darin, wer das Risiko unbekannter Komplexität trägt.

Beim Festpreis trägt es der Dienstleister. Beim Zeithonorar tragen Sie es als Auftraggeber. Und bei einem alten PHP-System ist die unbekannte Komplexität nicht die Ausnahme, sondern die Regel. Niemand kann seriös vorhersagen, was hinter einer 4000-Zeilen-Datei mit gemischtem HTML, SQL und Geschäftslogik wartet, bevor er sie geöffnet hat.

Warum der Festpreis bei Legacy-Modernisierung oft teuer wird

Ein Festpreis klingt nach Sicherheit. In der Realität führt er bei unklarem Umfang zu einem von zwei Ergebnissen, und beide sind schlecht für Sie.

Erstes Ergebnis: Der Dienstleister kalkuliert den Risikoaufschlag ein. Wer einen Festpreis auf ein unbekanntes System gibt, muss sich absichern. Er rechnet den schlimmsten Fall ein. Sie zahlen also für Risiken, die vielleicht nie eintreten. Bei einem gut kalkulierten Festpreisangebot für ein Legacy-Projekt zahlen Sie in der Regel einen deutlichen Aufpreis gegenüber dem, was die Arbeit tatsächlich gekostet hätte.

Zweites Ergebnis: Der Dienstleister hat zu knapp kalkuliert. Dann beginnt das eigentliche Problem. Sobald die kalkulierte Zeit aufgebraucht ist, entsteht ein Interessenkonflikt. Jede zusätzliche Stunde kostet den Dienstleister Geld. Die Folge kennt jeder, der schon einmal in so einem Projekt saß: Es wird über Change Requests gestritten. Was ist im Umfang, was nicht? War die kaputte Zeichenkodierung in der Datenbank Teil des Auftrags oder nicht? Die Migration wird schnell durchgezogen statt sauber gemacht. Qualität wird zur Verhandlungsmasse.

Ein Festpreis diszipliniert den Umfang. Er diszipliniert nicht die Qualität. Bei Modernisierung ist die Qualität aber genau der Punkt, um den es geht.

Wann Zeithonorar beim Softwareprojekt die ehrlichere Wahl ist

Zeithonorar hat einen schlechten Ruf, weil es nach offenem Scheck klingt. Das ist es nicht, wenn es richtig aufgesetzt ist. Der Vorteil: Der Dienstleister hat keinen Anreiz, an der falschen Stelle zu sparen. Er repariert die kaputte Zeichenkodierung, weil es das Richtige ist, nicht weil er darüber verhandelt hat.

Zeithonorar ist die passende Wahl, wenn:

  • der Umfang zu Beginn nicht seriös bestimmbar ist, etwa bei einer Bestandsaufnahme oder beim schrittweisen Ablösen alter Module,
  • Sie eine laufende Zusammenarbeit über Monate planen und nicht ein einmaliges Paket,
  • Prioritäten sich während des Projekts verschieben dürfen, ohne dass jedes Mal neu verhandelt wird,
  • Ihnen Codequalität und saubere Migration wichtiger sind als ein fixes Enddatum.

Damit Zeithonorar nicht ausufert, gehören Leitplanken dazu: ein Wochen- oder Monatsbudget als Deckel, kurze Abrechnungsintervalle, nachvollziehbare Zeiterfassung und regelmäßige Zwischenstände. So sehen Sie nach zwei Wochen, ob die Richtung stimmt, statt nach drei Monaten eine Überraschung zu erleben.

Der pragmatische Mittelweg: erst analysieren, dann kalkulieren

In der Praxis ist die beste Antwort auf die Festpreis-oder-Zeithonorar-Frage beim Softwareprojekt selten ein reines Modell, sondern eine Kombination. Der Ablauf, der bei Modernisierungsprojekten am zuverlässigsten funktioniert, sieht so aus:

  1. Analyse-Phase zum Festpreis. Ein klar begrenzter Auftrag: das System sichten, Abhängigkeiten kartieren, Risiken benennen, einen Modernisierungsplan schreiben. Das ist überschaubar und lässt sich fest kalkulieren, weil das Ergebnis ein Dokument ist, kein Code.
  2. Umsetzung in Paketen. Nach der Analyse ist der Umfang für die ersten Schritte bekannt. Einzelne, klar abgegrenzte Pakete lassen sich dann durchaus zum Festpreis anbieten, etwa "Upgrade von PHP 7.4 auf 8.3" oder "Ablösung der alten Authentifizierung".
  3. Laufende Arbeit im Zeithonorar. Für alles, was sich schlecht abgrenzen lässt, das kontinuierliche Refactoring und die Weiterentwicklung, ist Zeithonorar mit Budgetdeckel der ehrlichere Rahmen.

Dieser Weg dreht das Risiko um. Statt am Anfang blind einen Preis auf ein unbekanntes System zu geben, kaufen Sie sich zuerst für kleines Geld Klarheit. Danach entscheiden Sie mit offenen Karten, was zum Festpreis geht und was nicht.

Die Frage hinter der Frage: neu bauen oder modernisieren?

Oft steckt hinter der Preisfrage eine größere Entscheidung. Manch ein Anbieter wird Ihnen bei einem alten System zur Neuentwicklung raten, gern verbunden mit einem großen Festpreis. Das klingt sauber, ist aber meist die teuerste und riskanteste Option.

Ein System, das seit Jahren im Einsatz ist, ist kein Müll. Es ist der Beweis, dass die Fachlogik funktioniert. Über die Jahre sind unzählige Sonderfälle eingeflossen, die niemand mehr dokumentiert hat, die aber Ihr Geschäft am Laufen halten. Eine Neuentwicklung wirft diese Logik weg und baut sie unter hohem Risiko neu nach. Das Problem ist fast nie die Fachlogik. Das Problem ist der Code drumherum: fehlende Tests, veraltete Abhängigkeiten, Sicherheitslücken, unlesbare Struktur. Und dieser Code lässt sich schrittweise verbessern, ohne das Funktionierende zu opfern.

Wer Ihnen zur teuren Neuentwicklung rät, ohne das bestehende System wirklich verstanden zu haben, verkauft Ihnen sein Standardprodukt, nicht Ihre Lösung. Diese Haltung sollte auch in die Preisfrage einfließen.

Praxis-Tipp: So treffen Sie die richtige Entscheidung

Wenn Sie vor der Wahl stehen, drehen Sie die Reihenfolge um. Lehnen Sie jeden großen Festpreis ab, der ohne gründliche Sichtung Ihres Systems zustande kommt, denn er ist entweder mit Risikoaufschlag überteuert oder wird später zum Streitfall. Bestehen Sie stattdessen auf einer bezahlten Analyse-Phase mit festem Preis und festem Ergebnis. Erst danach lässt sich seriös sagen, welches Modell für die Umsetzung passt. Das ist unbequemer als ein glattes Angebot mit einer Zahl darauf, aber es ist die einzige Variante, bei der Sie am Ende nicht für die Unsicherheit eines anderen bezahlen.

Genau bei dieser Abwägung, von der ehrlichen Systemsichtung bis zur passenden Vertragsform, unterstützt LegacyWerk Sie, ohne Ihnen vorschnell zur teuersten Lösung zu raten.

Der pragmatische Weg zur Modernisierung 1. Analyse Festpreis 2. Pakete Festpreis je Paket 3. Weiterentwicklung Zeithonorar + Deckel Erst Klarheit kaufen, dann Preismodell wählen. Risiko unbekannt Risiko kalkulierbar

Ist Ihre PHP-Anwendung noch zu retten?

Im kostenlosen Kurz-Check schauen wir mit Ihnen auf Ihr System und sagen Ihnen ehrlich, was möglich ist, unverbindlich und ohne Verkaufsdruck.

Kurz-Check vereinbaren