4.6.2026

Web App Entwicklung zum Festpreis: Modell, Voraussetzungen und Risiken

Festpreis-Modell für Web Apps erklärt: Scope-Definition, Unterschiede zu Time-and-Material, Hybridmodelle und worauf du vor Vertragsschluss prüfen solltest.

Web App Entwicklung zum Festpreis: So funktioniert das Modell und was du vorher klären musst

Kurzantwort: Web App Entwicklung zum Festpreis bezeichnet ein Projektmodell, bei dem Scope, Technologie und Lieferumfang vor Projektstart schriftlich fixiert werden – der Preis ändert sich danach nur, wenn der Scope sich ändert. Das Modell eignet sich für Projekte mit klar definierten Anforderungen und ist besonders sinnvoll, wenn Budget- und Planungssicherheit wichtiger sind als maximale Flexibilität während der Entwicklung.

Zentrale Konzepte: Festpreismodell (fixer Preis gegen definierten Scope), Scope of Work (schriftliche Funktionsliste mit Akzeptanzkriterien), MVP (Minimum Viable Product – kleinste lieferbare Produktversion), Change Request (formaler Prozess für Scope-Änderungen nach Vertragsschluss), Time-and-Material (Abrechnung nach tatsächlichem Aufwand).

Festpreis vs. Time-and-Material: Welches Modell passt zu welchem Projekt?

Was Festpreis wirklich bedeutet – und was nicht

Ein Festpreisvertrag in der Softwareentwicklung bedeutet: Der Entwickler liefert einen definierten Funktionsumfang zu einem vorab vereinbarten Preis. Was sich nicht ändert, ist der Preis – solange sich der Scope nicht ändert. Das klingt einfach, funktioniert aber nur, wenn beide Seiten den Scope vor Projektstart präzise dokumentiert haben.

Festpreis bedeutet nicht, dass der Entwickler unbegrenzte Änderungswünsche umsetzt. Risiken verschwinden nicht – sie verlagern sich: Der Entwickler trägt das Risiko der Aufwandsschätzung, der Auftraggeber das Risiko einer zu engen Scope-Definition.

Wann Time-and-Material die sinnvollere Wahl ist

Time-and-Material (T&M) bedeutet Abrechnung nach tatsächlichem Aufwand, meist in Stunden oder Tagen. T&M eignet sich für Vorhaben, bei denen:

• Anforderungen sich während der Entwicklung voraussichtlich stark verändern,
• explorative Phasen nötig sind (z. B. KI-Feature-Prototypen),
• ein laufendes Produkt kontinuierlich weiterentwickelt wird.

Ein seriöser Entwickler spricht diesen Trade-off offen an. Wer ein T&M-Projekt als Festpreis verkauft, ohne den Scope zu fixieren, schiebt das Konfliktpotenzial nur nach hinten.

Hybridmodelle: Festpreis-MVP mit optionalem Erweiterungsbudget

Praktisch bewährt hat sich ein Hybridansatz: Der MVP wird zum Festpreis entwickelt – mit klar definiertem Funktionsumfang. Für spätere Erweiterungen wird ein separates T&M-Budget oder ein zweiter Festpreisvertrag vereinbart. So entsteht Planungssicherheit für die erste Version, ohne spätere Flexibilität zu blockieren.

Voraussetzungen für ein seriöses Festpreisangebot

Funktionsumfang: Was muss vor dem Angebot feststehen?

Ein belastbares Festpreisangebot setzt voraus, dass der Entwickler weiß, was er liefern soll. Häufige Lücke: Der Auftraggeber beschreibt ein Ziel ("Nutzer sollen sich registrieren können"), aber nicht die Logik dahinter – welche Felder, E-Mail-Bestätigung, Passwort-Reset, Social Login?

Ein Lastenheft oder eine strukturierte User-Story-Liste beantwortet diese Fragen vor dem Angebot. (klare Funktionsliste mit Akzeptanzkriterien) Anforderungen müssen auf Funktionsebene beschrieben sein, nicht auf Zielebene. Konkret: Jede Funktion als User Story formuliert ("Als Nutzer möchte ich mein Passwort zurücksetzen können, indem ich meine E-Mail-Adresse eingebe") oder als Funktionsliste mit Akzeptanzkriterien.

Technologie-Entscheidungen und ihre Auswirkung auf den Aufwand

Die Wahl des Tech-Stacks beeinflusst den Aufwand direkt. Eine Authentifizierungslösung mit Supabase Auth ist schneller integriert als eine selbst entwickelte JWT-Infrastruktur. Wer auf Next.js und Supabase setzt, nutzt vorhandene Integrationen für Standardfunktionen wie Auth, Datenbankzugriff und Storage – das verkürzt die Entwicklungszeit für diese Bausteine gegenüber einem komplett selbst aufgebauten Backend.

Bestehende Technologiepräferenzen ("wir nutzen bereits AWS" oder "kein Firebase") müssen vor dem Angebot kommuniziert werden, weil sie den Aufwand verschieben können.

Drittanbieter-Integrationen als häufige Scope-Falle

Zahlungsanbieter (z. B. Stripe), externe APIs, Auth-Provider oder bestehende CRM-Systeme sind häufige Scope-Fallen. Ihre Integration hängt von der Qualität der Dokumentation, Rate Limits, Sandbox-Verfügbarkeit und API-Stabilität ab – Faktoren, die der Entwickler erst einschätzen kann, wenn er sie kennt.

Vor dem Angebot müssen alle geplanten Drittanbieter-Integrationen identifiziert und, wenn möglich, mit API-Dokumentation belegt sein.

Checkliste: Wann ist dein Projekt festpreisfähig?

Arbeite diese Liste vor dem ersten Entwicklergespräch durch. Jedes offene Feld ist ein potenzieller Scope-Konflikt.

| # | Kriterium | Status | |---|-----------|--------| | 1 | Anforderungen schriftlich dokumentiert – User Stories oder Funktionsliste liegt vor | ☐ offen / ☑ erledigt | | 2 | Technologieentscheidungen oder Präferenzen geklärt – Stack-Vorgaben oder Offenheit für Empfehlung dokumentiert | ☐ offen / ☑ erledigt | | 3 | Designvorgaben oder Wireframes vorhanden – mindestens Skizzen oder ein Referenz-UI | ☐ offen / ☑ erledigt | | 4 | Drittanbieter-Integrationen identifiziert – Zahlungsanbieter, externe APIs, Auth-Provider benannt | ☐ offen / ☑ erledigt | | 5 | Abnahmekriterien definiert – klar beschrieben, wann eine Funktion als „fertig" gilt | ☐ offen / ☑ erledigt | | 6 | DSGVO-relevante Datenflüsse bekannt – welche personenbezogenen Daten werden verarbeitet, wo gespeichert? | ☐ offen / ☑ erledigt | | 7 | Zeitplan und Meilensteine grob skizziert – Wunsch-Go-Live und kritische Deadlines bekannt | ☐ offen / ☑ erledigt | | 8 | Change-Request-Prozess im Vertrag geregelt – Verfahren für Scope-Änderungen ist besprochen | ☐ offen / ☑ erledigt |

Auswertung: Sind mehr als zwei Felder offen, ist das Projekt noch nicht festpreisfähig. Das ist kein Problem – es bedeutet, dass vor dem Angebot eine Anforderungsaufnahme sinnvoll ist, ggf. als separate bezahlte Phase.

Was ein Festpreisvertrag regeln muss

*Dieser Abschnitt beschreibt operative Punkte, die Projektverantwortliche mit dem Entwickler besprechen und im Vertrag prüfen sollten. Für verbindliche rechtliche Einschätzungen empfiehlt sich die Konsultation eines Fachanwalts für IT-Recht.*

Change-Request-Prozess: Wie Scope-Änderungen sauber gehandhabt werden

Ein Festpreisvertrag ohne Change-Request-Regelung ist ein Konflikt in Wartestellung. Die Regelung sollte mindestens beschreiben:

• Wie eine Änderung beantragt wird (schriftlich, per definiertem Formular oder Ticket)
• Wer die Aufwandsschätzung für die Änderung erstellt und freigibt
• Ob Änderungen den Gesamtpreis und den Zeitplan verschieben

Beispiel: Eine neue Exportfunktion, die nach Projektstart gewünscht wird, wird als Change Request erfasst, separat geschätzt und erst nach schriftlicher Freigabe umgesetzt.

Abnahme und Meilensteine: Wann gilt eine Leistung als erbracht?

Abnahmekriterien sollten funktionsbezogen formuliert sein, nicht subjektiv. „Die App sieht gut aus" ist kein Abnahmekriterium. „Nutzer können sich registrieren, einloggen und ihr Passwort zurücksetzen – getestet in Chrome, Firefox und Safari auf Desktop" ist eines.

Statt einer einzigen Abnahme am Projektende empfehlen sich Teilabnahmen nach definierten Entwicklungsphasen. Das reduziert das Risiko auf beiden Seiten.

Übergabe und Dokumentation: Was nach Projektabschluss übergeben wird

Eine vollständige Projektübergabe umfasst typischerweise: Quellcode im vereinbarten Repository, Deployment-Dokumentation (wie wird die App gestartet, aktualisiert, gesichert?), Beschreibung der Datenbankstruktur, Drittanbieter-Zugänge sowie eine README mit Setup-Anleitung. Wer das nicht im Vertrag fixiert, riskiert eine Übergabe, die aus einem ZIP-Archiv ohne Kontext besteht. (Dokumentation bei der Übergabe)

Typische Projektphasen bei der Web-App-Entwicklung zum Festpreis

Phase 1: Anforderungsaufnahme und Scope-Fixierung

Vor jeder Zeile Code steht ein strukturiertes Gespräch: Was soll die App können? Wer nutzt sie? Welche Daten werden verarbeitet? Das Ergebnis ist ein schriftlicher Scope of Work – keine 50-seitige Spezifikation, aber eine klare Funktionsliste mit Akzeptanzkriterien. Je nach Projektkomplexität dauert dieser Schritt ein bis drei Gespräche.

Phase 2: Technische Konzeption und Stack-Entscheidung

Für ein typisches Next.js-Supabase-Projekt sieht die Konzeptionsphase so aus: Datenbankschema skizzieren, Auth-Flow definieren, API-Endpunkte planen, Hosting-Entscheidung treffen (z. B. Vercel für Next.js, Supabase für Datenbank und Auth). Technologieentscheidungen werden begründet dokumentiert – nicht als Blackbox.

In meiner Arbeit lege ich Datenmodelle und Routing-Strukturen von Anfang an so an, dass spätere Erweiterungen keine Umbaumaßnahmen erfordern. Das beeinflusst konkret, wie ich Schema-Migrationen vorbereite und welche API-Grenzen ich von Beginn an einziehe.

Phase 3: Entwicklung, Review-Zyklen und Abnahme

MVP-Entwicklung zum Festpreis läuft in der Praxis selten als Wasserfall. Sinnvoller ist ein strukturierter Rhythmus: Entwicklung in Blöcken, Review durch den Auftraggeber nach jedem Block, Feedback schriftlich erfassen, Abnahme je Meilenstein. So entstehen keine Überraschungen am Projektende.

Phase 4: Deployment, DSGVO-Prüfung und Übergabe

Vor dem Go-Live: Deployment auf der Produktionsumgebung, Funktionstest, Prüfung DSGVO-relevanter Punkte (Datenspeicherort, Auftragsverarbeitungsvertrag mit Hosting-Anbieter, Cookie-Handling). Was nach dem Projekt übergeben wird, steht bereits im Vertrag – Code, Dokumentation, Zugänge.

*Hinweis: Welche DSGVO-Maßnahmen für dein konkretes Projekt erforderlich sind, hängt von den verarbeiteten Daten und der eingesetzten Infrastruktur ab. Verbindliche Einschätzungen liefert ein Datenschutzbeauftragter oder Fachanwalt.*

Worauf du bei der Entwicklerauswahl achten solltest

Qualitätssignale im Erstgespräch

Ein seriöser Entwickler stellt im Erstgespräch mehr Fragen, als er Antworten gibt. Wer sofort einen Preis nennt, ohne den Scope zu kennen, schätzt entweder großzügig nach oben oder unterschätzt bewusst. Konkrete Qualitätssignale: Der Entwickler fragt nach Drittanbieter-Integrationen, nennt Trade-offs offen und erklärt, wann ein Festpreis aus seiner Sicht nicht sinnvoll ist.

Portfolio und Case Studies: Was wirklich zählt

Freelance-Web-App-Entwicklung lässt sich am besten an produktiven Anwendungen beurteilen – nicht an Mockups. Relevante Fragen: Ist die App live? Welche technischen Entscheidungen wurden getroffen und warum? Ein Entwickler, der Case Studies mit Tech-Stack-Details und Trade-offs präsentiert, zeigt mehr als einer, der nur Screenshots zeigt.

Direkt vs. Agentur: Trade-offs offen betrachtet

Direkt bei einem Fullstack-Entwickler zu beauftragen bedeutet kürzere Kommunikationswege und direkten Zugang zur Person, die den Code schreibt. Der Trade-off: Ein einzelner Entwickler hat begrenzte Parallelkapazität. Agenturen bieten mehr Kapazität, aber auch mehr Koordinationsaufwand und oft eine Zwischenschicht zwischen Auftraggeber und Entwickler. Welches Modell passt, hängt von Projektgröße, Zeitplan und persönlicher Präferenz ab – nicht von einer pauschalen Empfehlung.

FAQ

Was passiert beim Festpreis, wenn sich die Anforderungen während der Entwicklung ändern?

Scope-Änderungen werden als Change Request erfasst, separat geschätzt und erst nach schriftlicher Freigabe umgesetzt. Sie können den Gesamtpreis und den Zeitplan verschieben. Ein sauber formulierter Festpreisvertrag regelt diesen Prozess vorab – damit keine Änderung stillschweigend in den ursprünglichen Preis eingerechnet wird.

Für welche Web-App-Projekte eignet sich das Festpreismodell besonders?

Festpreis eignet sich für Projekte mit klar definierbarem Funktionsumfang: MVPs mit begrenztem Feature-Set, interne Tools mit stabilen Anforderungen, Portale mit definiertem Datenmodell. Weniger geeignet ist es für explorative Entwicklung, laufende Produktweiterentwicklung oder Projekte, bei denen sich Anforderungen erfahrungsgemäß stark verschieben.

Wie lange dauert die Entwicklung einer Web App zum Festpreis?

Das hängt vom Scope ab. Ein fokussierter MVP mit drei bis fünf Kernfunktionen kann in wenigen Wochen lieferbar sein; komplexere Anwendungen mit mehreren Integrationen und Nutzerrollen benötigen mehr Zeit. Eine belastbare Zeitschätzung ist erst nach Scope-Fixierung möglich – pauschale Angaben ohne Scope-Kenntnis sind nicht verlässlich.

Was sollte bei der Projektübergabe nach der Entwicklung enthalten sein?

Mindestens: Quellcode im vereinbarten Repository, Deployment-Dokumentation, Datenbankschema, Beschreibung aller Drittanbieter-Zugänge und eine README mit Setup-Anleitung. Idealerweise auch eine kurze Beschreibung der Architekturentscheidungen, damit ein nachfolgender Entwickler das Projekt ohne Rückfragen übernehmen kann.

Kann ein einzelner Freelancer eine Web App zum Festpreis liefern, oder brauche ich eine Agentur?

Ein erfahrener Fullstack-Entwickler kann MVPs und mittelgroße Web-Apps alleine liefern – mit dem Vorteil direkter Kommunikation und ohne Koordinationsaufwand. Bei sehr großen Projekten mit parallelen Workstreams kann Agenturkapazität sinnvoll sein. Entscheidend ist nicht die Teamgröße, sondern ob der Entwickler den Scope realistisch einschätzt und belastbare Referenzprojekte vorweisen kann.