Faire Festpreiskalkulation als Einzelentwickler

Ein Kunde fragt nach einem Festpreis, und der erste Reflex ist oft: schnell eine Zahl nennen, Auftrag sichern, Rest klärt sich unterwegs. Das geht selten gut aus. Wer als Einzelentwickler im Mittelstand unterwegs ist, merkt schnell: Festpreiskalkulation ist keine Kopfrechenübung, sondern ein Handwerk mit eigenen Regeln. Wer es beherrscht, gewinnt nicht nur Aufträge, sondern auch Kunden, die wiederkommen.

Das Dilemma des Festpreises

Kunden lieben Festpreise, weil sie Planungssicherheit geben. Für den Entwickler bedeutet ein Festpreis aber, das gesamte Projektrisiko allein zu tragen. Läuft ein Projekt aus dem Ruder, weil die Anforderungen unterschätzt wurden oder sich unterwegs ändern, bleibt das Risiko meist an einer Stelle hängen: bei dir.

Diese Schieflage lässt sich nicht wegdiskutieren, aber gut steuern. Eine faire Kalkulation heißt nicht, das Risiko zu ignorieren, sondern es bewusst einzupreisen und mit dem Kunden offen darüber zu sprechen.

Warum viele Einzelentwickler zu knapp kalkulieren

In der Praxis sehe ich vor allem drei Fehler:

Erstens wird der Aufwand nach Bauchgefühl geschätzt, ohne die einzelnen Aufgaben wirklich durchzugehen. Zweitens fehlt ein Puffer für Dinge, die garantiert passieren: unklare Anforderungen, Rückfragen, Testzyklen, Abstimmungsschleifen. Drittens wird der eigene Stundensatz zu niedrig angesetzt, weil man sich mit anderen Angeboten vergleicht, die vielleicht selbst schon zu knapp kalkuliert sind.

Das Ergebnis: Das Projekt wird angenommen, aber die tatsächlich investierte Zeit übersteigt am Ende deutlich das, was eingepreist war. Auf Dauer führt das zu Frust, Zeitdruck und einer Preisspirale nach unten, die der gesamten Branche schadet.

Die Bausteine einer belastbaren Kalkulation

Saubere Aufwandsschätzung

Der wichtigste Schritt passiert vor der eigentlichen Zahl: das Projekt in überschaubare Aufgabenpakete zerlegen. Statt "Backend entwickeln" lieber "Datenmodell entwerfen", "API-Endpunkte für X, Y, Z", "Validierung und Fehlerbehandlung", "Tests schreiben". Je kleinteiliger die Schätzung, desto realistischer wird die Summe am Ende, weil sich Unterschätzungen bei einzelnen Punkten nicht so leicht verstecken.

Eigene historische Daten helfen dabei enorm: Wie lange hat die letzte vergleichbare Aufgabe wirklich gedauert, nicht wie lange sie hätte dauern sollen?

Puffer für das Unplanbare

Ein Aufschlag von 15 bis 25 Prozent auf die reine Entwicklungszeit ist keine Unehrlichkeit, sondern Realismus. Er deckt Dinge ab, die in jedem Projekt auftreten: Missverständnisse bei Anforderungen, zusätzliche Abstimmungstermine, kleine Anpassungen, die sich erst beim Testen zeigen. Diesen Puffer transparent zu benennen ist besser, als ihn unsichtbar in die Stundensätze einzurechnen.

Fixkosten und Stundensatz ehrlich einrechnen

Wer als Einzelentwickler kalkuliert, muss neben der reinen Projektzeit auch die eigenen Fixkosten decken: Software-Lizenzen, Versicherungen, Weiterbildung, Zeiten ohne Auftrag. Ein Stundensatz, der nur die sichtbare Projektarbeit abbildet, reicht langfristig nicht. Es lohnt sich, den eigenen Jahresumsatzbedarf einmal grob durchzurechnen und daraus einen tragfähigen Stundensatz abzuleiten, statt sich allein am Marktdurchschnitt zu orientieren.

Change Requests von Anfang an mitdenken

Fast jedes Projekt bekommt während der Laufzeit zusätzliche Wünsche. Ein fairer Festpreis regelt von Anfang an, was im Preis enthalten ist und was nicht. Ein kurzer Passus im Angebot, der Änderungswünsche außerhalb des definierten Umfangs als separat zu vereinbarende Zusatzleistung beschreibt, schützt beide Seiten vor späteren Missverständnissen.

Abgrenzung ist die halbe Miete

Die meisten Konflikte um Festpreise entstehen nicht durch böse Absicht, sondern durch unklare Abgrenzung. Ein präzises Lastenheft oder zumindest eine klare Leistungsbeschreibung im Angebot ist die beste Versicherung gegen spätere Diskussionen. Was gehört zum Umfang, was nicht? Wie viele Testrunden, wie viele Korrekturschleifen sind eingepreist? Wer das schriftlich fixiert, muss später nicht mehr aus dem Bauch heraus argumentieren.

Mit Unsicherheit umgehen, ohne sie zu verstecken

Manche Projektteile lassen sich schwer im Vorfeld schätzen, etwa wenn eine Integration mit einer fremden Schnittstelle unbekannter Qualität ansteht. Hier hilft es, diese Unsicherheit offen zu benennen statt sie in eine vermeintlich sichere Festpreiszahl zu pressen. Eine Möglichkeit: den unsicheren Teil als separate Aufwandsschätzung nach Stunden anbieten, den Rest als Festpreis. Das nimmt Druck aus der Kalkulation und schafft beim Kunden Verständnis dafür, warum nicht alles pauschal geht.

Transparenz als Vertrauensbasis

Ein Festpreis wirkt für den Kunden oft wie eine Blackbox. Wer stattdessen die Kalkulationslogik grob offenlegt, ohne jede interne Stundenzahl zu verraten, schafft Vertrauen. Ein Satz wie "Der Preis beinhaltet X Personentage Entwicklung, Y Tage Testing und einen Puffer für Abstimmungen" macht nachvollziehbar, warum eine Zahl so ist, wie sie ist. Kunden, die verstehen, wofür sie zahlen, verhandeln seltener aggressiv über den Preis und schätzen die Zusammenarbeit stärker.

Faire Kalkulation ist der Schlüssel

Faire Festpreiskalkulation ist kein Widerspruch zu wirtschaftlichem Erfolg. Sie verlangt saubere Aufwandsschätzung, realistische Puffer, eine ehrliche Basis für den Stundensatz und klare Abgrenzung im Angebot. Wer diese Bausteine beherrscht, verkauft sich nicht unter Wert und schreckt Kunden trotzdem nicht mit überzogenen Zahlen ab. Am Ende gewinnen beide Seiten: der Kunde durch Planungssicherheit, der Entwickler durch ein Projekt, das sich wirtschaftlich trägt.