Freelance Entwickler Festpreis Projekt: So strukturierst du das Engagement richtig

Kurzantwort: Ein Freelance-Entwickler-Festpreis-Projekt bezeichnet die Beauftragung eines selbstständigen Entwicklers zu einem vorab vereinbarten Gesamtpreis für einen definierten Leistungsumfang. Es funktioniert, wenn Scope, Abnahmekriterien und Zahlungsmeilensteine vor Projektstart schriftlich fixiert sind. Ohne klare Anforderungsdokumentation wird aus einem Festpreis schnell ein gleitender Aufwand – für beide Seiten.

Schlüsselbegriffe:

| Begriff | Kurzdefinition | |---|---| | Festpreis-Modell | Vereinbarter Gesamtpreis für einen definierten Scope; Änderungen erfordern einen Change Request | | Scope Creep | Schleichende Erweiterung des Leistungsumfangs ohne formale Anpassung von Preis oder Zeitplan | | Meilensteinzahlung | Teilzahlung, die an ein konkretes Lieferobjekt geknüpft ist, nicht an ein Datum | | Abnahmeprotokoll | Schriftliche Bestätigung, dass ein Lieferobjekt die vereinbarten Kriterien erfüllt | | Change Request | Formaler Prozess zur Bewertung und Beauftragung von Scope-Änderungen nach Projektstart | | Werkvertrag | Vertragstyp, bei dem ein Ergebnis geschuldet wird – typisch für Festpreisprojekte; Abgrenzung zum Dienstvertrag, bei dem Arbeitsleistung geschuldet wird. Welcher Typ zutrifft, solltest du mit einem Rechtsanwalt klären. |

Festpreis oder Stundensatz – wann welches Modell passt

Wann Festpreis funktioniert

Festpreis-Softwareentwicklung funktioniert, wenn der Scope vor Projektstart vollständig beschreibbar ist: bekannte Technologie, klare Nutzerflows, keine offenen Architekturentscheidungen. Ein konkretes Beispiel: ein Buchungsformular mit Stripe-Anbindung und E-Mail-Bestätigung. Alle Schritte sind vorhersehbar, der Entwicklungsaufwand schätzbar.

• Geeignete Projekte haben folgende Merkmale:
• Die Feature-Liste ist abgeschlossen, nicht „wir schauen, was sich ergibt"
• Die verwendete Technologie ist dem Entwickler vertraut – kein Lernprojekt auf Kundenkosten
• Abnahmekriterien lassen sich vorab formulieren
• Der Auftraggeber kann Entscheidungen zeitnah treffen

Wann Stundensatz oder Retainer besser passt

Ein Stundensatz ist die richtige Wahl, wenn das Projektziel noch nicht klar ist – etwa bei explorativen KI-Features, bei denen das Ergebnis vom Experimentieren abhängt, oder wenn laufende Pflege und Weiterentwicklung gefragt sind. Ein Retainer (feste Stundenkontingente pro Monat) eignet sich für Teams, die kontinuierlich Entwicklungskapazität brauchen, ohne jedes Mal ein neues Angebot einzuholen.

Wer ein Festpreis-Angebot für ein schlecht definiertes Projekt verlangt, zwingt den Entwickler zu Pufferkalkulationen – das Angebot wird teurer, nicht günstiger.

Hybridmodell: Festpreis-Phasen mit offenem Folgeauftrag

Ein pragmatischer Mittelweg: Die erste Phase (Discovery, Konzept, technisches Setup) wird zum Festpreis beauftragt. Auf dieser Basis entsteht ein präziserer Scope für die Umsetzung, die dann ebenfalls zum Festpreis oder per Stundensatz erfolgt. Dieses Modell passt, wenn der Auftraggeber noch keine vollständige Anforderungsdokumentation hat, aber Budgetsicherheit für den Start braucht.

Scope-Definition: Die Grundlage jedes Festpreisangebots

Was ein Entwickler braucht, um ein belastbares Angebot zu erstellen

Ein Festpreisangebot ist nur so belastbar wie das Anforderungsdokument dahinter. Kein Entwickler braucht eine perfekte Spezifikation – aber genug Klarheit, um Annahmen zu minimieren.

Schwache Anforderungsbeschreibung: > „Wir brauchen eine App, mit der Nutzer ihre Daten tracken können."

Belastbare Anforderungsbeschreibung: > „Nutzer sollen täglich einen Wert (Zahl zwischen 1–100) eintragen. Die App zeigt einen Verlaufsgraph der letzten 30 Tage. Daten werden pro Nutzer gespeichert, Login per E-Mail. Export als CSV. Mobile-optimiert, kein nativer App-Store-Release."

User Stories helfen, Funktionen aus Nutzerperspektive zu beschreiben: *„Als eingeloggter Nutzer möchte ich meine Einträge der letzten 30 Tage als Graph sehen, damit ich Muster erkenne."* Das ist kein Pflichtenheft im klassischen Sinne, aber es erzwingt Konkretheit.

Typische Scope-Lücken und wie man sie schließt

Scope Creep entsteht meistens nicht durch böse Absicht, sondern durch Lücken im ursprünglichen Scope. Häufige Beispiele:

• Rollen und Berechtigungen: „Admin soll alles sehen" – aber wer ist Admin, und was genau sieht er?
• E-Mail-Benachrichtigungen: Oft vergessen, bis jemand fragt: „Kriegen Nutzer eigentlich eine Bestätigungsmail?"
• Fehlerzustände: Was passiert, wenn eine API nicht antwortet? Wer definiert den Fallback?
• Mobiloptimierung: Ist „responsive" im Scope? Für welche Bildschirmgrößen?

Diese Lücken schließt man am effektivsten, indem man den Scope nicht nur als Feature-Liste, sondern als Flussdiagramm oder Klickdummy beschreibt. (Meilensteinstruktur und konkrete Abnahmekriterien)

Change Requests: Wie Änderungen nach Projektstart gehandhabt werden

Jede Anforderung, die nach Projektstart hinzukommt oder sich ändert, ist ein Change Request. Ein fairer Prozess: Der Entwickler bewertet den Aufwand schriftlich, der Auftraggeber genehmigt ihn schriftlich – bevor die Arbeit beginnt. (strukturierter Rhythmus mit Abnahme je Meilenstein) Ohne diesen Prozess entstehen Missverständnisse darüber, was im ursprünglichen Preis enthalten war.

Checkliste: Was vor dem Festpreis-Angebot geklärt sein muss

Diese Checkliste ist ein Arbeitswerkzeug. Geh sie mit deinem Entwickler durch, bevor ein Angebot erstellt wird.

Scope und Funktionsumfang

| # | Punkt | Warum relevant | |---|---|---| | 1 | Funktionsumfang schriftlich beschrieben (User Stories oder Feature-Liste) | Ohne schriftlichen Scope gibt es keine gemeinsame Referenz bei Meinungsverschiedenheiten | | 2 | Abgrenzung: Was ist explizit nicht im Scope | Verhindert stille Annahmen auf beiden Seiten | | 3 | Priorisierung der Features (Must-have / Nice-to-have) | Ermöglicht saubere Scope-Reduktion, wenn das Budget nicht reicht | | 4 | Mobiloptimierung, Browser-Kompatibilität und Barrierefreiheit geklärt | Diese Punkte werden häufig nachträglich eingefordert |

Technische Voraussetzungen und Zugänge

| # | Punkt | Warum relevant | |---|---|---| | 5 | Tech-Stack und Hosting-Umgebung definiert | Technologiewechsel nach Projektstart verursachen erheblichen Mehraufwand | | 6 | Drittanbieter-APIs und deren Verfügbarkeit geprüft | API-Limits, Kosten und Dokumentationsqualität beeinflussen den Entwicklungsaufwand | | 7 | Zugänge (Hosting, CMS, bestehende Systeme) rechtzeitig bereitgestellt | Fehlende Zugänge sind einer der häufigsten Gründe für Projektverzögerungen | | 8 | Testumgebung vorhanden oder im Scope enthalten | Produktionstests ohne Staging-Umgebung erhöhen das Fehlerrisiko erheblich |

Zahlungsstruktur und Abnahme

| # | Punkt | Warum relevant | |---|---|---| | 9 | Zahlungsplan mit konkreten Auslösern (Lieferobjekt, nicht nur Datum) | Datumsbasierte Zahlungen setzen den falschen Anreiz; Lieferobjekte schaffen Klarheit | | 10 | Abnahmekriterien je Meilenstein schriftlich definiert | Ohne Kriterien ist Abnahme Verhandlungssache | | 11 | Change-Request-Prozess vereinbart (Aufwandsbewertung + schriftliche Freigabe) | Verhindert Scope Creep ohne Preisanpassung | | 12 | Ansprechpartner auf Auftraggeberseite benannt (mit Entscheidungskompetenz) | Entscheidungsstaus blockieren den Entwicklungsfortschritt |

Übergabe und Dokumentation

| # | Punkt | Warum relevant | |---|---|---| | 13 | Übergabe-Dokumentation im Scope enthalten | Code ohne Dokumentation ist für Nachfolger schwer wartbar | | 14 | Repository-Zugang und Deployment-Prozess dokumentiert | Auftraggeber sollte unabhängig vom Entwickler deployen können | | 15 | DSGVO-relevante Komponenten identifiziert und Verantwortlichkeiten geklärt | Wer für die Datenschutz-Umsetzung verantwortlich ist, sollte vor Projektstart feststehen – bei Fragen zur rechtlichen Einordnung einen Datenschutzbeauftragten hinzuziehen |

Zahlungsstruktur und Meilensteine: So schützen sich beide Seiten

Typische Meilensteinstruktur für Web-App-Projekte

Eine faire Zahlungsstruktur verteilt das Risiko. Eine gängige Struktur für Web-App-Projekte sieht so aus – die Prozentangaben sind illustrativ und keine Branchenstandards:

• Anzahlung bei Vertragsunterzeichnung: sichert die Kapazität des Entwicklers
• Zwischenzahlung nach Abnahme eines definierten Meilensteins (z. B. lauffähiger Prototyp mit Kernfunktionen)
• Schlusszahlung nach finaler Abnahme und Übergabe aller Deliverables

Der Auslöser für jede Zahlung sollte ein Lieferobjekt sein, nicht ein Datum. Beispiel: „Zahlung 2 wird fällig, wenn Nutzer-Login, Dateneingabe und Verlaufsgraph in der Staging-Umgebung funktionieren und vom Auftraggeber abgenommen wurden."

Was ein Abnahmeprotokoll enthalten sollte

• Ein Abnahmeprotokoll schützt beide Seiten. Es sollte enthalten:
• Datum der Abnahme
• Liste der abgenommenen Funktionen mit Verweis auf die ursprüngliche Anforderung
• Festgestellte Mängel und vereinbarte Nachbesserungsfrist
• Schriftliche Bestätigung des Auftraggebers

Umgang mit Nachbesserungen

Nachbesserungen bei Bugs, die im vereinbarten Scope vorhanden waren, sind in der Regel Teil des Festpreises. Neue Anforderungen sind Change Requests. Die genaue Abgrenzung – und Fragen zur gesetzlichen Gewährleistung – sollten im Vertrag geregelt sein. Für die rechtliche Einordnung (Werkvertrag vs. Dienstvertrag, Gewährleistungsfristen) empfiehlt sich anwaltliche Beratung.

Worauf du bei der Entwicklerauswahl achten solltest

Signale für realistische Projektschätzung

Ein erfahrener Freelancer stellt Rückfragen, bevor er ein Angebot abgibt. Wer ein Festpreisangebot innerhalb von 24 Stunden ohne Rückfragen liefert, hat entweder sehr viel Puffer einkalkuliert oder den Scope nicht verstanden. Beides ist ein Signal.

Beim Portfolio: Achte nicht nur auf visuelle Qualität, sondern auf Projektbeschreibungen, die Entscheidungen erklären – warum wurde dieser Stack gewählt, welche Trade-offs gab es?

Fragen für das Erstgespräch

• „Was passiert, wenn sich der Scope nach Projektstart ändert?"
• „Wie gehst du mit Anforderungen um, die du für technisch riskant hältst?"
• „Kannst du mir ein Beispiel für ein Projekt nennen, das nicht wie geplant gelaufen ist – und wie du damit umgegangen bist?"
• „Was brauchst du von mir, um ein realistisches Angebot zu erstellen?"

Red Flags bei Festpreisangeboten

• Kein schriftlicher Scope im Angebot referenziert
• Keine Meilensteine, nur Gesamtpreis und Enddatum
• Keine Regelung für Change Requests
• Angebot enthält keine Abnahmekriterien
• Entwickler kann nicht erklären, wie er den Preis kalkuliert hat

FAQ

Was ist der Unterschied zwischen Festpreis und Stundensatz bei einem Freelance-Entwickler? Beim Festpreis wird ein Gesamtpreis für einen definierten Scope vereinbart – Änderungen erfordern einen Change Request. Beim Stundensatz wird tatsächlich geleistete Arbeitszeit abgerechnet. Festpreis gibt Budgetsicherheit, setzt aber einen klar beschriebenen Scope voraus. Stundensatz ist flexibler, erfordert aber aktives Aufwands-Monitoring auf Auftraggeberseite.

Wie viel Anzahlung ist bei einem Festpreis-Projekt üblich? Einen verbindlichen Branchenstandard gibt es nicht. Anzahlungen sichern die Kapazität des Entwicklers und signalisieren Ernsthaftigkeit auf Auftraggeberseite. Was konkret vereinbart wird, sollte schriftlich im Vertrag festgehalten sein. Für die rechtliche Ausgestaltung empfiehlt sich anwaltliche Beratung.

Was passiert, wenn sich der Scope während des Projekts ändert? Scope-Änderungen laufen über einen Change-Request-Prozess: Der Entwickler bewertet den Mehraufwand schriftlich, der Auftraggeber genehmigt ihn schriftlich – bevor die Arbeit beginnt. Ohne diesen Prozess entstehen Unklarheiten darüber, was im ursprünglichen Preis enthalten war und wer für Mehraufwand aufkommt.

Wie erkenne ich, ob ein Festpreisangebot realistisch kalkuliert ist? Ein realistisches Angebot referenziert einen konkreten Scope, enthält Meilensteine mit Lieferobjekten und benennt explizit, was nicht enthalten ist. Der Entwickler sollte auf Nachfrage erklären können, wie er den Preis kalkuliert hat. Angebote ohne Scope-Referenz oder ohne Regelung für Änderungen sind schwer zu bewerten.

Brauche ich einen Vertrag für ein Festpreis-Projekt mit einem Freelancer? Ein schriftlicher Vertrag ist bei jedem Festpreisprojekt sinnvoll – er schützt beide Seiten. Er sollte Scope, Meilensteine, Zahlungsplan, Change-Request-Prozess und Abnahmekriterien enthalten. Ob ein Werkvertrag oder Dienstvertrag vorliegt und welche gesetzlichen Regelungen gelten, hängt von der konkreten Ausgestaltung ab. Für die rechtliche Einordnung einen Rechtsanwalt hinzuziehen.