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.
Scope greifbar machen: ein Beispiel
„Eine Tracking-App bauen“ ist keine abnehmbare Anforderung. Ein konkreteres Beispiel lautet: Angemeldete Nutzer erfassen täglich einen ganzzahligen Wert von 1 bis 100; sie sehen die letzten 30 Tage als Graph und exportieren die eigenen Einträge als CSV. Auch bei keinem Eintrag oder ungültigen Werten muss das Verhalten feststehen. Das ist ein Beispielszenario, kein fertiges Angebot.
| Bereich | Im Beispiel enthalten | Gesondert zu klären |
|---|---|---|
| Zugang | Anmeldung und zwei festgelegte Rollen | SSO, weitere Rollen, mehrere Organisationen |
| Daten | Eingabe, eigene Einträge und CSV-Export | Datenmigration und externe Datenquellen |
| Oberfläche | Graph und begrenzte Administration | Native Mobile-App, PDF-Berichte und zusätzliche Analytik |
| Betrieb | Ein vereinbartes Deployment | Supportzeiten, laufende Wartung und zusätzliche Umgebungen |
Prüfpunkte vor der Beauftragung
Die Checkliste zum Festpreis lässt sich um konkrete Liefer- und Mitwirkungspunkte erweitern:
- Funktionen und ausdrücklich ausgeschlossene Leistungen schriftlich festhalten.
- Datenfelder, Rollen und erlaubte Zugriffe benennen.
- Messbare Abnahmekriterien pro Ablauf vereinbaren.
- Browser, Zielgeräte und Anforderungen an Barrierefreiheit festlegen.
- Frühzeitig die erforderlichen API-, Hosting- und Testzugänge bereitstellen.
- Eine Staging-Umgebung und passende Beispieldaten bestimmen.
- Eine Entscheidungsperson sowie Kommunikationskanal und Feedbackfenster benennen.
- Umgang mit Änderungen, Fehlern und zusätzlichen Wünschen vereinbaren.
- Termine und Abhängigkeiten von Zulieferungen sichtbar machen.
- Zahlungsmeilensteine an Lieferobjekte knüpfen, etwa Anmeldung, Erfassung und Graph; keine pauschale Standardquote voraussetzen.
- Quellcode, Dokumentation, Lizenzen und Nutzungsrechte für die Übergabe klären.
- Laufende Kosten, Zuständigkeiten und den Supportweg nach dem Start schriftlich festhalten.
Ein praktisches Abnahmeprotokoll enthält Datum, geprüfte Funktionen, festgestellte Mängel mit vereinbarter Nachbesserung und die Bestätigung der beteiligten Personen. Das beschreibt einen Arbeitsablauf und ersetzt keine Prüfung individueller Vertragsbedingungen.
Wenn eine Agentur den Auftrag vermittelt
Bei einem Unterauftrag muss zusätzlich klar sein, wer Vertragspartner und Rechnungsempfänger ist, wer technisch entscheidet und wer abnimmt. NDA, Repository-Zugang, Coding-Standards, Review-Prozess und Übergabe der Änderungen gehören vor dem Start abgestimmt. Ein Wochenplan oder Zahlungsmodell ist immer projektspezifisch.
Die konkrete Umsetzung erläutere ich auf der Seite Web-App entwickeln lassen. Für die Berechnung des Aufwands gibt es die Drei-Punkt-Schätzung.
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.