SaaS-Entwicklung zum Festpreis: So funktioniert das Modell und worauf du achten solltest

Kurzantwort: SaaS-Entwicklung zum Festpreis bezeichnet ein Projektmodell, bei dem Umfang, Features, Architektur und Abnahmekriterien vor Projektbeginn exakt definiert werden – und der Preis auf dieser Basis verbindlich vereinbart wird. Ohne sauberes Scoping ist ein Festpreis kein Schutz, sondern ein Risiko für beide Seiten. Wer diesen Prozess strukturiert angeht, bekommt Planungssicherheit; wer ihn überspringt, zahlt ihn später durch Change Requests.

Was SaaS-Entwicklung zum Festpreis bedeutet – und was nicht

Festpreis vs. Time-and-Material: Die entscheidenden Unterschiede

Beim Festpreismodell wird ein Preis für einen definierten Leistungsumfang vereinbart. (Festpreismodell für Web Apps) Änderungen außerhalb dieses Umfangs werden separat bewertet und beauftragt. Beim Time-and-Material-Modell (T&M) wird nach tatsächlichem Aufwand abgerechnet – Stunden oder Tage zu einem vereinbarten Tagessatz.

| Kriterium | Festpreis | Time & Material | |---|---|---| | Budgetsicherheit | Hoch | Variabel | | Flexibilität bei Änderungen | Gering (Change Request nötig) | Hoch | | Anforderung an Scoping | Sehr hoch | Mittel | | Geeignet für | Klar definierte Projekte | Explorative oder iterative Vorhaben |

Wann ein Festpreis funktioniert – und wann nicht

Ein Festpreis funktioniert, wenn der Projektumfang vor Beginn stabil ist: Features sind priorisiert, Schnittstellen bekannt, Abnahmekriterien schriftlich vereinbart. Er funktioniert nicht, wenn das Produkt noch in der Konzeptphase steckt oder sich die Anforderungen erfahrungsgemäß während der Entwicklung verschieben. In solchen Fällen ist T&M oder ein hybrides Modell – Festpreis pro Phase – die ehrlichere Variante für beide Seiten.

Typische SaaS-Architektur und was sie im Festpreis-Kontext bedeutet

Architekturentscheidungen treffen den Aufwand direkt. Wer eine SaaS-Plattform zum Festpreis entwickeln lässt, muss verstehen, welche technischen Bausteine welche Komplexität mitbringen.

Multi-Tenancy: Shared vs. isolierte Datenbank

Multi-Tenant-Architektur bedeutet, dass eine Instanz der Anwendung mehrere Kunden (Tenants) bedient. Zwei Hauptansätze:

• Shared Database: Alle Tenants teilen eine Datenbank, Datentrennung erfolgt über eine `tenant_id`-Spalte. Günstiger im Betrieb, aber Datenisolation muss konsequent auf Anwendungsebene durchgesetzt werden – zum Beispiel mit Row Level Security in PostgreSQL und Supabase.
• Isolierte Datenbank pro Tenant: Jeder Kunde bekommt eine eigene Datenbankinstanz. Höhere Datenisolation, aber deutlich mehr Infrastrukturaufwand und laufende Betriebskosten.

Diese Entscheidung beeinflusst den Entwicklungsaufwand erheblich und muss vor dem Scoping geklärt sein – nicht danach.

Subscription-Management und Zahlungsintegration

Subscription Management umfasst Abonnement-Logik: Pläne, Upgrades, Downgrades, Kündigungen und Rechnungsstellung. Die Integration von Stripe – Billing, Webhooks, Customer Portal – ist ein häufig unterschätzter Aufwandsblock. Stripe Webhooks müssen idempotent verarbeitet werden; Fehlerbehandlung und Testabdeckung kosten Zeit. Wer das im Festpreis-Scoping nicht explizit adressiert, bekommt einen unvollständigen Preis.

Auth, Nutzerrollen und DSGVO-Anforderungen

Authentifizierung mit Supabase Auth oder einem vergleichbaren Dienst ist technisch schnell eingebunden – Nutzerrollen, Berechtigungsebenen und datenschutzkonforme Datenhaltung sind es nicht. Zu klären sind: Wer darf was sehen? Wie werden Nutzer auf Anfrage gelöscht? Wo werden Daten gespeichert? Diese Fragen beeinflussen das Datenbankschema, die API-Logik in Next.js und TypeScript und die Übergabedokumentation. Welche konkreten Pflichten sich aus der DSGVO für dein Projekt ergeben, solltest du mit einem Datenschutzbeauftragten oder Rechtsberater klären – das variiert je nach Datenart und Nutzerkreis.

Ein API-First-Ansatz – bei dem die Geschäftslogik über eine saubere API getrennt von der UI lebt – erleichtert spätere Erweiterungen, erhöht aber den initialen Aufwand. Das ist ein Trade-off, der vor dem Scoping auf den Tisch muss.

Der Weg zum Festpreis: Vom ersten Gespräch zum signierten Angebot

Discovery und Anforderungsanalyse

Im Erstgespräch geht es nicht darum, sofort einen Preis zu nennen. Es geht darum zu verstehen, was gebaut werden soll, warum, und welche Rahmenbedingungen gelten. Relevante Fragen in dieser Phase:

• Welche Nutzergruppen gibt es, und was ist ihre primäre Aufgabe in der App?
• Welche Schnittstellen zu Drittsystemen sind erforderlich?
• Gibt es bestehende Systeme, die abgelöst oder integriert werden?
• Welche technischen Vorgaben gibt es – Hosting, Tech Stack, Datenschutz?

Die Anforderungsanalyse mündet in einem strukturierten Feature-Set mit Priorisierung. Ohne dieses Dokument ist jede Preiszahl eine Schätzung ins Blaue.

Meilensteine und Abnahmekriterien definieren

Ein Meilensteinplan zerlegt das Projekt in abnahmeprüfbare Lieferabschnitte. (Meilesteinplan und Abnahmekriterien) Jeder Meilenstein hat konkrete Abnahmekriterien – keine vagen Beschreibungen wie „funktioniert", sondern testbare Aussagen: „Nutzer kann sich registrieren, einloggen und sein Passwort zurücksetzen. Fehlermeldungen erscheinen auf Deutsch."

Ich bevorzuge klare, nutzbare Formulierungen gegenüber generischer Projektsprache – weil ein Abnahmekriterium, das jeder anders liest, im Streitfall nichts wert ist.

Was ein seriöses Festpreisangebot enthält

Ein belastbares Festpreisangebot für SaaS-Entwicklung enthält mindestens:

• Detaillierte Feature-Liste mit Scope-Grenzen
• Tech Stack und Architekturentscheidungen
• Meilensteinplan mit Terminen und Abnahmekriterien
• Regelung für Change Requests (Prozess, Bewertungszeit, Aufpreis)
• Übergabedokumentation und Quellcode-Eigentümerschaft
• Zahlungsplan, typischerweise an Meilensteine gekoppelt

Fehlt einer dieser Punkte, ist das Angebot unvollständig – unabhängig davon, wie attraktiv die Zahl darunter aussieht.

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

Bevor ein Festpreisangebot sinnvoll erstellt oder bewertet werden kann, müssen folgende Punkte geklärt sein. Diese Festpreis-Checkliste richtet sich an Auftraggeber und Projektverantwortliche.

| # | Punkt | Geklärt? | |---|---|---| | 1 | Feature-Liste mit Priorisierung – Must-have vs. Nice-to-have schriftlich festgehalten | ☐ | | 2 | Tech Stack und Hosting – Vorgaben oder Präferenzen dokumentiert (z. B. Next.js, Supabase, eigener Server vs. Vercel) | ☐ | | 3 | Schnittstellen zu Drittsystemen – alle API-Integrationen benannt und Dokumentation vorhanden | ☐ | | 4 | Abnahmekriterien je Meilenstein – testbar, schriftlich, von beiden Seiten bestätigt | ☐ | | 5 | Change-Request-Prozess – wie werden Änderungswünsche während der Entwicklung bewertet und beauftragt? | ☐ | | 6 | Datenschutz-Anforderungen – Datenspeicherort, Nutzerrollen, Löschkonzept, Auftragsverarbeitungsvertrag besprochen und mit Rechtsberater abgestimmt | ☐ | | 7 | Übergabedokumentation – Umfang und Format vereinbart (README, Architekturdiagramm, Deployment-Anleitung) | ☐ | | 8 | Quellcode-Eigentümerschaft – Auftraggeber erhält vollständigen Quellcode nach Abnahme | ☐ | | 9 | Zeitplan mit Lieferterminen – Meilensteine mit konkreten Daten, nicht nur Wochen-Schätzungen | ☐ | | 10 | Ansprechpartner und Entscheidungswege – wer kann auf Auftraggeberseite Scope-Entscheidungen treffen? | ☐ |

Scope Creep entsteht fast immer dort, wo Punkte 1, 4 oder 5 unklar sind. Ein Change-Request-Prozess muss nicht bürokratisch sein – aber er muss existieren, bevor das Projekt beginnt.

MVP zuerst: Warum ein schlankes erstes Release den Festpreis schützt

Was ein SaaS-MVP realistisch enthält

Ein MVP (Minimum Viable Product) ist nicht die abgespeckte Version des Endprodukts – es ist das kleinste Produktinkrement, das echten Nutzern echten Nutzen liefert und Feedback ermöglicht. Für eine SaaS-Plattform bedeutet das typischerweise:

• Nutzerregistrierung und Login (inkl. Passwort-Reset)
• Ein zentrales Kernfeature, das den primären Use Case abdeckt
• Einfaches Subscription-Modell (ein Plan, Stripe-Integration)
• Grundlegendes Nutzerrollen-Konzept (Admin / User)

Beispiel: Eine fiktive SaaS-App für Praxisverwaltung könnte als MVP die Terminbuchung durch Patienten und die Kalenderansicht für das Praxisteam liefern – ohne Abrechnung, Dokumentenverwaltung oder Statistiken. Das ist ein abgrenzbarer Scope, der sich sauber bepreisen lässt.

Wie MVP und Festpreis zusammenpassen

Ein MVP reduziert das Produktrisiko für beide Seiten: Der Auftraggeber investiert in einen klar abgegrenzten Umfang und kann nach dem ersten Release entscheiden, welche Features tatsächlich gebraucht werden. Der Entwickler arbeitet gegen einen stabilen Scope.

Iterative Entwicklung – MVP, Feedback, nächste Phase – ist mit dem Festpreismodell kompatibel, wenn jede Phase separat gescoped und bepreist wird. Das ist kein Widerspruch, sondern eine saubere Release-Planung.

Freelancer vs. Agentur für SaaS-Entwicklung zum Festpreis

Wann ein Freelancer die passendere Wahl ist

Ein Freelancer mit SaaS-Erfahrung im Fullstack-Bereich eignet sich, wenn:

• Der Scope klar ist und direkte Kommunikation ohne Projektmanagement-Layer gewünscht wird
• Das Team auf Auftraggeberseite selbst technisch mitdenken kann
• Flexibilität bei Architekturentscheidungen wichtiger ist als Prozesskonformität
• Projektverantwortung bei einer einzelnen Person liegen soll, die den gesamten Stack kennt

Der Vorteil: kein Overhead durch Accountmanager, kein Informationsverlust zwischen Vertrieb und Entwicklung.

Wann eine Agentur mehr Sinn ergibt

Eine Agentur ist die sinnvollere Wahl, wenn:

• Parallele Entwicklungsteams für mehrere Komponenten benötigt werden
• Feste Prozesse – etwa zertifizierte Abläufe – vertraglich gefordert sind
• Der Auftraggeber keine eigene technische Begleitung leisten kann und ein dediziertes Projektmanagement braucht
• Subunternehmer-Kapazität für laufende Systeme mit SLA-Anforderungen gefragt ist

Beide Modelle können Festpreise anbieten. Der Unterschied liegt im Kommunikationsweg, der Verantwortlichkeit und dem Overhead – nicht in der Qualität per se.

FAQ

Was ist SaaS-Entwicklung? SaaS (Software as a Service) bezeichnet webbasierte Software, die Nutzer über ein Abonnement nutzen – ohne lokale Installation. SaaS-Entwicklung umfasst den Aufbau dieser Plattformen: Multi-Tenant-Architektur, Nutzerverwaltung, Subscription-Logik und API-Schnittstellen. Typische Technologien sind Next.js, Supabase, PostgreSQL und Stripe.

Welche laufenden Kosten fallen bei einer SaaS-Plattform an? Laufende Kosten entstehen durch Hosting, Datenbankbetrieb, Zahlungsdienstleister-Gebühren, E-Mail-Dienste und externe APIs. Die genauen Beträge hängen von Anbieter, Tarif und Nutzungsvolumen ab – aktuelle Preise sollten direkt auf den jeweiligen Anbieter-Seiten geprüft werden, da sie sich regelmäßig ändern.

Hat SaaS als Geschäftsmodell Zukunft? SaaS ist ein etabliertes Geschäftsmodell mit wiederkehrenden Einnahmen und skalierbarer Infrastruktur. Ob es für ein konkretes Produkt tragfähig ist, hängt von Zielgruppe, Wettbewerb und Preisbereitschaft ab – das ist eine Frage der Marktvalidierung, keine allgemeingültige Aussage.

Wird SaaS durch KI ersetzt? KI verändert, wie SaaS-Produkte gebaut und genutzt werden – etwa durch KI-gestützte Features, Automatisierung und personalisierte Empfehlungen. Das Geschäftsmodell selbst bleibt davon unberührt. Viele SaaS-Produkte integrieren KI als Feature, nicht als Ersatz für das Modell.

Wie schütze ich mich vor Scope Creep bei einem Festpreisprojekt? Durch drei Maßnahmen: eine priorisierte Feature-Liste vor Projektbeginn, schriftliche Abnahmekriterien je Meilenstein und einen definierten Change-Request-Prozess. Jede Anforderung, die nach Projektstart hinzukommt, wird separat bewertet und beauftragt – das ist kein Misstrauen, sondern Grundlage für einen funktionierenden Festpreis.