Der Stack ist in allen drei Fällen derselbe: React, Next.js, TypeScript, PostgreSQL, dazu Stripe, sobald Geld fließt. Der Aufwand ist es nicht. Ein Innendienst-Werkzeug für einen Mittelständler, ein Patienten-Portal für eine Praxis und ein neues Modul in einem SaaS-Produkt teilen sich denselben Funktionskern – Login, Datenerfassung, Liste, Detailansicht, Export – und landen in der Kalkulation unten trotzdem bei 102, 136 und 180 Stunden. Die Differenz sitzt an drei Positionen: Rollen und Rechte, Schnittstellen zu vorhandenen Systemen, Mandantentrennung.
Wer einen Fullstack-Entwickler für Mittelstand, Praxen oder SaaS sucht, vergleicht deshalb oft das Falsche. Framework und Stundensatz sind in zehn Minuten geklärt. Wie viele Rollen das System kennt und wie viele Menschen einer Änderung zustimmen müssen, entscheidet über Budget und Laufzeit.
Gleicher Funktionskern, drei Rechnungen
Für den Vergleich habe ich dasselbe Feature-Set in drei Kontexte gestellt: Anmelden, Daten erfassen, Liste sehen, Datensatz öffnen, Ergebnis exportieren. Der Kern ist in allen drei Spalten mit identischen 60 Stunden angesetzt.
| Position | Mittelstand: Innendienst-Tool | Praxis: Patienten-Portal | SaaS: Neues Modul |
|---|---|---|---|
| Funktionskern (Login, CRUD, Liste, Detail, Export) | 60 h | 60 h | 60 h |
| Rollen und Rechte | 8 h (2 Rollen) | 18 h (4 Rollen + Vertretungsfall) | 26 h (Organisationen, Einladungen, Abo-Status) |
| Schnittstellen zu Bestandssystemen | 24 h (1 ERP-Export) | 30 h (Kalender + Datenübergabe ans PVS) | 16 h (Webhooks, kein Fremdsystem) |
| Mandanten- und Standorttrennung | 0 h | 6 h (2 Standorte) | 34 h (Trennung auf Datenbankebene, Onboarding) |
| Abrechnung | 0 h | 0 h | 28 h (Pläne, Wechsel, fehlgeschlagene Zahlungen) |
| Datenschutz-Zuarbeit und Protokollierung | 10 h | 22 h | 16 h |
| Summe | 102 h | 136 h | 180 h |
Die Zahlen stammen aus meiner eigenen Kalkulationspraxis, sind also ein Modell und kein Marktdurchschnitt. Ersetze jede Zeile durch deine Ist-Werte, sobald du sie kennst.
Interessant ist ohnehin nicht die Summe, sondern das Verhältnis: 76 Prozent Mehraufwand zwischen der schlanksten und der aufwendigsten Variante, ohne dass ein einziges zusätzliches Feature dazukommt. Wer ein SaaS-Modul mit dem Stundenbudget eines Innendienst-Tools plant, hat sich nicht in der Funktion verschätzt, sondern im Kontext.
Mittelstand: Das Projekt endet an der Schnittstelle, nicht am Feature
Die Oberfläche ist selten das Problem. Das Problem ist die Zeile „Übergabe an das ERP" – technisch drei Tage Arbeit, organisatorisch sechs Wochen. Der Zugang zum Testsystem hängt am externen Dienstleister, der das ERP betreut, und der plant in Wartungsfenstern, nicht in Sprints.
Daraus folgt eine Regel, die ich in jedes Angebot schreibe: Steht bis Ende Woche 2 kein Testzugang mit echten Daten, wird die Live-Schnittstelle auf Datei-Import und -Export zurückgestuft. Im Modell oben fallen die 24 Stunden damit auf 6 bis 8. Das Werkzeug geht in Betrieb, die Anbindung kommt als eigenes kleines Paket nach, wenn der Zugang da ist. Umgekehrt – erst warten, dann bauen – liegt ein fertiges Projekt monatelang ungenutzt herum und niemand erinnert sich noch, wie es bedient wird.
Der zweite typische Fehlschluss im Mittelstand: Es gibt eine IT, also gibt es auch jemanden, der das neue System betreibt. Häufig betreut diese IT Netzwerk, Arbeitsplätze und Telefonanlage und hat mit einer Node-Anwendung nichts zu tun. Kläre vor dem Angebot, wer nach der Übergabe Updates einspielt, und wenn niemand die Hand hebt, gehört gemanagtes Hosting in den Scope.
Praxis: Die Freigabe passt in kein Sprint-Raster
In der Praxis entscheidet eine Person, und diese Person hat zwischen 8 und 18 Uhr Patienten. Feedback kommt abends oder gar nicht. Genau daran scheitern Projekte, die technisch längst fertig sind.
Was den Aufwand gegenüber dem Mittelstands-Tool auf 136 Stunden treibt, sind drei Dinge, die auf keiner Feature-Liste stehen. Erstens der Vertretungsfall: Wer sieht was, wenn die Praxisleitung im Urlaub ist und die Vertretung aus einer anderen Praxis einspringt? Zweitens die Protokollierung – wer wann welchen Datensatz geöffnet hat, ist bei Patientendaten eine eigene Funktion, keine Konfiguration. Drittens die Löschfristen, die pro Datenklasse unterschiedlich ausfallen und die deine Datenschutzberatung vorgibt, nicht der Entwickler. Meine Zuarbeit dazu sind die technischen Angaben: Hosting-Standort, eingesetzte Dienste, was protokolliert wird, was nach welcher Frist automatisch verschwindet.
Ein Terminfehler kostet mehr als jede Fehlschätzung: Ein Portal im Herbst einzuführen, wenn das Wartezimmer voll ist, bedeutet, dass es niemand erklärt bekommt. Einführungen gehören in ruhige Wochen, und dieser Termin sollte vor dem Startdatum feststehen, nicht danach.
SaaS: Mandantentrennung gehört in die Datenbank, nicht in den Anwendungscode
Die 34 Stunden für Mandantentrennung sind der Posten, den Anfragen am zuverlässigsten übersehen – und der einzige, der sich später am schlechtesten nachrüsten lässt. Wird die Trennung im Anwendungscode gelöst, also über ein `where tenant_id = …` in jeder Abfrage, ist jeder neue Endpunkt eine neue Gelegenheit, es zu vergessen. Liegt sie auf Datenbankebene, etwa über Row Level Security in PostgreSQL, greift sie auch für die Abfrage, die jemand in einem Jahr hinzufügt.
Für die Nachrüstung rechne ich mit rund dem 1,5-Fachen des ursprünglichen Postens, im Beispiel also mit etwa 50 statt 34 Stunden – plus dem Aufwand, alle bestehenden Abfragen und Tests noch einmal durchzugehen. Wenn absehbar ist, dass ein zweiter Kunde kommt, ist es günstiger, sie sofort zu bauen.
Der zweite SaaS-eigene Posten ist die Abrechnung. Pläne anlegen ist schnell erledigt; teuer sind die Randfälle: Wechsel mitten im Abrechnungszeitraum, fehlgeschlagene Zahlungen, gekündigte Abos mit Daten, die noch exportierbar bleiben sollen. Diese Fälle gehören einzeln in den Scope, weil sie einzeln Arbeit sind. Wie man das sauber schneidet, habe ich in SaaS-Entwicklung zum Festpreis ausführlicher aufgeschrieben.
Laufzeit rechnen, nicht nur Stunden
Der Unterschied zwischen den drei Segmenten steckt nicht im Code, sondern in der Anzahl der Menschen, die einer Änderung zustimmen müssen. Das kostet keine Stunden, aber es kostet Kalender.
Meine Planungswerte für die Zeit zwischen „Meilenstein steht bereit" und „Rückmeldung liegt vor":
- Mittelstand: 3 Werktage – Fachbereich und IT müssen sich abstimmen
- Praxis: 7 Werktage – eine Person, die zwischen Sprechstunden entscheidet
- SaaS-Team: 1 Werktag – Product Owner, oft am selben Tag
Bei fünf Meilensteinen sind das 15, 35 und 5 Werktage reine Wartezeit. Drei Wochen gegen sieben Wochen, bei exakt gleichem Entwicklungsaufwand. Wer diese Latenz nicht einplant, hält am Ende einen Zeitplan für gerissen, an dem gar nicht gearbeitet wurde.
Praktische Konsequenz für Praxis-Projekte: Meilensteine größer schneiden. Vier Freigaben statt neun sparen im Modell 35 Werktage Laufzeit, ohne eine Stunde Arbeit zu streichen.
Was in die Anfrage gehört
Diese acht Angaben reichen für eine belastbare Aufwandsschätzung. Fehlt eine davon, ist jeder Festpreis eine Wette – dazu, wie man die Scope-Grenze sauber zieht, steht mehr im Beitrag zum Vertragsmodell Festpreis.
- Rollen namentlich: Nicht „Mitarbeiter und Admin", sondern jede Rolle mit einem Satz, was sie darf und was nicht.
- Bestandssysteme mit Zugangsweg: Welches System, welche Version, wer erteilt den Testzugang, welche Vorlaufzeit hat diese Person?
- Datenklassen: Welche Daten landen in der Anwendung, welche bleiben ausdrücklich draußen?
- Erwartete Last zur Spitze: Gleichzeitige Nutzer im Maximum, nicht im Monatsschnitt.
- Wer gibt frei – eine Person, mit Vertretung und realistischem Zeitfenster.
- Einführungstermin und warum genau dieser – Messe, Quartalswechsel, ruhige Wochen.
- Betrieb nach Übergabe: Wer spielt Updates ein, wer wird nachts angerufen?
- Der Satz, der das Projekt erfolgreich macht – ein messbarer Zustand, etwa „die Anmeldung läuft ohne Papier".
Drei Rückfragen aus Erstgesprächen
Reicht ein einzelner Entwickler für ein SaaS-Produkt?
Für Aufbau und Weiterentwicklung eines abgegrenzten Produkts oder Moduls in aller Regel ja – die Grenze liegt nicht bei der Komplexität, sondern bei Parallelität und Bereitschaft. Drei Teilprojekte gleichzeitig zum selben Termin gehen nicht. Ein Modul nach dem anderen geht sehr wohl.
Warum kostet das Praxis-Portal mehr als die Praxis-Website?
Weil eine Website Inhalte ausliefert und ein Portal Daten verarbeitet. Rollen, Protokollierung, Löschfristen, Vertretungsfall und Standorttrennung machen in meinem Modell 46 der 136 Stunden aus, also gut ein Drittel, und davon ist auf dem Bildschirm fast nichts zu sehen.
Können wir klein anfangen und später erweitern?
Ja, mit einer Ausnahme: Mandantentrennung und Rollenmodell sollten von Anfang an stimmen, weil beide quer durch die gesamte Anwendung laufen. Features, Auswertungen, zusätzliche Schnittstellen lassen sich dagegen problemlos in späteren Paketen nachziehen.
Wann ein einzelner Fullstack-Entwickler nicht die richtige Wahl ist
Vier Situationen, in denen ich abrate, statt anzubieten:
- Mehrere Teilprojekte parallel zu einem harten Termin. Ein Entwickler arbeitet sequenziell. Wenn drei Stränge gleichzeitig fertig sein müssen, braucht es ein Team.
- Zugesicherte Reaktionszeiten rund um die Uhr. Nachts und im Urlaub ist niemand da. Wenn Ausfälle innerhalb von Minuten behoben sein müssen, gehört ein Betriebsdienstleister dazu.
- Unklare regulatorische Einstufung. Ob eine Anwendung als Medizinprodukt gilt, klärt eine spezialisierte Beratung – und zwar vor der Angebotsphase, weil die Antwort den kompletten Prozess verändert.
- Gleichzeitige Migration aus mehreren Altsystemen. Datenübernahme aus drei Quellen ist ein eigenes Projekt mit eigenem Budget, kein Nebenposten.
In allen anderen Fällen ist die Rechnung überschaubar: Weniger Abstimmungsebenen, direkter Kontakt, aber auch nur ein Kalender. Wie sich das gegen ein Agenturangebot rechnet, steht im Kostenvergleich Freelancer gegen Agentur.
Wenn du die acht Angaben oben zusammen hast, dauert eine erste Einschätzung meist eine halbe Stunde – im kostenfreien Erstgespräch, DACH-weit remote.