Die meisten Kundenprojekte werden nicht in der Umsetzung unprofitabel, sondern in dem Moment, in dem das Angebot geschrieben wird. Wer eine Zahl aus dem Bauch nennt und dann sechs Wochen lang gegen die eigene Schätzung anprogrammiert, hat kein Entwicklungsproblem, sondern ein Kalkulationsproblem.
Ich schreibe Angebote für Websites, Web-Apps und Automatisierungen, und ich habe mich am Anfang zuverlässig verschätzt — immer in dieselbe Richtung. Was ich inzwischen anders mache, ist weniger eine Formel als eine Reihenfolge: erst verstehen, dann zerlegen, dann bepreisen. Nie umgekehrt.
Warum sich Entwickler systematisch zu niedrig schätzen
Der Grund ist nicht Naivität, sondern ein Denkfehler: Du schätzt den Happy Path. Vor deinem inneren Auge läuft die Version des Projekts, in der die Schnittstelle dokumentiert ist, der Kunde die Texte pünktlich liefert und niemand nach dem Launch noch “nur eine Kleinigkeit” will. Diese Version tritt praktisch nie ein.
Dazu kommt, dass Entwickler nur den Code-Anteil sehen. Der ist bei einem typischen Kundenprojekt aber selten mehr als die Hälfte des Aufwands. Der Rest sind Abstimmungstermine, Rückfragen per Mail, Feedbackschleifen zu Design, Content-Pflege, Deployment, DNS-Umzug, Einweisung des Kunden, Nachbesserungen in den zwei Wochen nach dem Go-Live. Wenn du diese Positionen nicht explizit kalkulierst, bezahlst du sie aus deiner Marge.
Der dritte Faktor ist die Angst vor der eigenen Zahl. Man schreibt eine Summe hin, erschrickt selbst und rundet nach unten, bevor der Kunde überhaupt reagieren konnte. Damit verhandelst du gegen dich selbst — und zwar in der Runde, in der der Kunde noch gar nicht mitspielt.
Erst zerlegen, dann schätzen
Die einzige Methode, die bei mir zuverlässig funktioniert, ist banal: Ich schätze nie ein Projekt, sondern immer nur Einzelteile. Ein Angebot entsteht aus einer Liste von zwanzig bis vierzig Positionen, nicht aus einer Zahl.
Die Zerlegung geht so weit, bis jede Position in einem halben bis maximal zwei Tagen erledigt wäre. Alles, was du nur mit “circa eine Woche” beziffern kannst, ist noch nicht verstanden — und was du nicht verstanden hast, kannst du auch nicht bepreisen. Diese Positionen markiere ich getrennt und behandle sie als Risiko, nicht als Schätzung.
Der angenehme Nebeneffekt: Die Zerlegung ist gleichzeitig deine Leistungsbeschreibung. Was in der Liste steht, ist drin. Was nicht drinsteht, ist ein Änderungswunsch. Das erspart dir später die zermürbende Diskussion darüber, was “die Website” eigentlich umfasste.
Die Positionen, die fast alle vergessen
Wenn ich alte Kalkulationen anschaue, fehlen fast immer dieselben Punkte:
- Kommunikation. Termine, Protokolle, Rückfragen, Erinnerungen an ausstehende Zulieferungen. Bei kommunikationsintensiven Kunden ist das ein spürbarer Anteil des Gesamtaufwands.
- Content-Einpflege. Kunden unterschätzen fast immer, wie lange sie für Texte und Bilder brauchen — und du unterschätzt, wie lange das Einpflegen dauert, wenn das Material in unsortierten Mail-Anhängen ankommt.
- Rechtliche Pflichtseiten. Impressum, Datenschutzerklärung, Cookie-Banner mit funktionierender Einwilligung, Auftragsverarbeitungsverträge mit den eingesetzten Diensten. Das ist Arbeit, auch wenn kein Code entsteht.
- Deployment und Domain. Hosting einrichten, Zertifikate, DNS-Umzug beim alten Anbieter, E-Mail-Weiterleitungen, die auf keinen Fall ausfallen dürfen. Der DNS-Umzug einer bestehenden Firmenseite ist regelmäßig nervenaufreibender als der ganze Rest.
- Einweisung und Übergabe. Zeige dem Kunden, wie er Inhalte pflegt, und dokumentiere es kurz. Sonst wirst du dauerhaft zum kostenlosen Support-Kanal für Texte, die er selbst ändern könnte.
- Nachlauf. Die kleinen Korrekturen nach dem Go-Live. Nimm sie bewusst ins Angebot auf, mit klarem Umfang und klarem Ende.
Festpreis oder Stundensatz?
Beides funktioniert, aber nicht für dieselbe Art von Projekt.
Ein Festpreis ist sinnvoll, wenn der Umfang klar definierbar ist: eine Unternehmenswebsite, ein abgegrenztes Feature, eine Automatisierung mit bekannter Schnittstelle. Der Kunde bekommt Planungssicherheit, du bekommst die Chance, effizienter zu sein als kalkuliert — das ist deine Belohnung für Erfahrung. Der Preis dafür: Du trägst das Risiko, und du brauchst eine wasserdichte Leistungsbeschreibung plus ein sauberes Verfahren für Änderungswünsche.
Ein Stundensatz oder Tagessatz passt, wenn der Umfang sich erst im Verlauf klärt: laufende Weiterentwicklung, unklare Alt-Systeme, Beratung. Hier trägt der Kunde das Risiko, und deshalb will er dafür Vertrauen und Transparenz — dokumentierte Zeiten, regelmäßige Zwischenstände, keine Überraschungen auf der Rechnung.
Der pragmatische Mittelweg, den ich am häufigsten nutze: Ein bezahlter Konzept- oder Analyse-Block zuerst, klein und klar begrenzt. Danach ein Festpreis für die Umsetzung, der auf echtem Wissen statt auf Vermutungen beruht. Das ist ehrlicher als eine Festpreis-Fantasie nach einem einzigen Erstgespräch — und der Kunde erlebt schon vor dem großen Auftrag, wie du arbeitest.
Was du dagegen nicht tun solltest: einen Festpreis nennen für etwas, das du noch nie gebaut hast, bei einem System, das du noch nie gesehen hast. Das ist kein mutiges Angebot, das ist ein Lottoschein.
Risikopuffer, aber ehrlich
Ein Puffer ist keine Schlamperei-Reserve, sondern die Bepreisung von Unsicherheit. Deshalb sollte er nicht pauschal über die Gesamtsumme gelegt, sondern dort verortet werden, wo die Unsicherheit tatsächlich sitzt: bei der undokumentierten Schnittstelle, bei der Datenmigration aus dem Alt-System, bei dem Kunden, der schon in der Angebotsphase langsam antwortet.
Je unklarer eine Position, desto größer der Aufschlag auf genau diese Position. Und wenn eine Unbekannte so groß ist, dass du sie nicht seriös bepreisen kannst, gehört sie nicht in den Festpreis, sondern in einen eigenen, nach Aufwand abgerechneten Block — mit einer klaren Obergrenze, ab der ihr neu sprecht. Das ist für den Kunden nachvollziehbar, weil es ehrlich ist.
Der Preis ist nicht deine Kostenrechnung
Zum Schluss der Punkt, der am längsten gebraucht hat, bis er bei mir angekommen ist: Der Aufwand bestimmt deine Untergrenze, nicht deinen Preis. Was ein Projekt wert ist, hängt daran, was es beim Kunden bewirkt. Eine Website, über die ein Handwerksbetrieb neue Aufträge gewinnt, hat einen anderen Wert als ein optisches Update ohne wirtschaftliche Wirkung — auch wenn beide gleich viele Tage kosten.
Deshalb lohnt sich im Erstgespräch die Frage, was passieren soll, wenn das Projekt funktioniert. Die Antwort verändert oft nicht nur den Preis, sondern das ganze Angebot: Manchmal ist das, wonach der Kunde gefragt hat, gar nicht das, was ihm hilft. Wer das erkennt und begründet anders anbietet, konkurriert nicht mehr über den Preis.
Und wenn du unsicher bist, ob deine Zahl realistisch ist: Im Discord der Community sprechen einige von uns ziemlich offen über Kalkulationen, die aufgegangen sind — und über die, die es nicht taten.