Viele Unternehmen suchen nach "Web-App entwickeln lassen", wenn aus einer Idee ein echtes digitales Produkt werden soll: ein Kundenportal, ein internes Tool, eine SaaS-Plattform oder ein Workflow-System. Die wichtigste Erkenntnis vorab: Eine Web-App ist keine Website mit Login. Sie ist Software, die Prozesse abbildet, Daten verändert, Rollen verwaltet und zuverlässig betrieben werden muss.
Deshalb lässt sich der Preis nicht mit einer Pauschalzahl beantworten. Spezialisierte Agenturen in der DACH-Region rechnen 2026 mit Stundensätzen zwischen 120 und 180 EUR – die eigentliche Stellschraube ist also nicht der Satz, sondern der Umfang. Dieser Beitrag erklärt mit aktuellen Zahlen, was eine Web-App kostet, wie lange sie dauert und welche Architekturentscheidungen früh über das Budget bestimmen.
Eine Web-App ist ein Produkt, keine größere Website
Der teuerste Denkfehler ist, eine Web-App wie eine erweiterte Website zu kalkulieren. Eine Website zeigt Inhalte; eine Web-App verändert Daten. Sobald Nutzer sich anmelden, Datensätze bearbeiten, Prozesse auslösen, Dateien hochladen oder zusammenarbeiten, entstehen Anforderungen an Authentifizierung, Berechtigungen, Datenmodell, Sicherheit, Performance und Betrieb.
Typische Web-Apps sind Kundenportale, SaaS-Produkte, Buchungsplattformen, interne Dashboards, CRM- oder ERP-Erweiterungen sowie Workflow-Software für Teams. Allen gemeinsam ist: Der sichtbare Teil im Browser ist nur die Spitze. Darunter liegen Geschäftslogik, ein Datenmodell und ein Betriebskonzept, die über Wartbarkeit und Folgekosten entscheiden. Genau daran bemisst sich der Aufwand – nicht an der Zahl der Screens.
Was kostet es, eine Web-App entwickeln zu lassen?
Kosten hängen vor allem von Komplexität, Risiko und Integrationen ab – nicht von der Anzahl der Seiten. Als grobe Orientierung für professionelle Individualentwicklung in der DACH-Region:
| Projekttyp | Typischer Umfang | Realistischer Korridor |
|---|---|---|
| Validierungsprototyp | klickbarer oder teilfunktionaler Prototyp, wenige Kernflows | 10.000–25.000 EUR |
| MVP | Login, Kernfunktion, Datenmodell, Admin-Bereich, Deployment | 25.000–80.000 EUR |
| Produktive Web-App | Rollen, Integrationen, Tests, Monitoring, Datenschutz, Betrieb | 80.000–200.000 EUR |
| SaaS-Plattform | Multi-Tenancy, Billing, Rechte, Reporting, Support-Prozesse | ab 150.000 EUR |
Diese Zahlen sind keine Preisliste, sondern Planungsgrößen. Ein sauber begrenztes MVP kann günstiger sein, ein reguliertes Produkt mit sensiblen Daten deutlich teurer. Wichtig ist, nicht nur die erste Version zu kalkulieren: Betrieb, Wartung und Weiterentwicklung, Sicherheitsupdates und Support gehören zur wirtschaftlichen Wahrheit jeder Web-App. Faustregel: Plane jährlich grob 15–25 % der Erstinvestition für den laufenden Betrieb ein.
Vier Faktoren treiben den Aufwand am stärksten: Produktumfang (jede zusätzliche Rolle und jeder Sonderfall kostet), das Datenmodell als Fundament für alle späteren Funktionen, Integrationen zu Zahlungsanbietern, CRM, ERP oder SSO (der größte Unsicherheitsfaktor) und Sicherheit und Compliance (Audit-Logs, Verschlüsselung, Backups, Löschkonzepte). Diese Themen sind günstiger, wenn sie von Anfang an eingeplant werden, statt nachträglich eingebaut zu werden.
Wie lange dauert die Entwicklung?
Ein realistischer Zeitplan rechnet in Monaten, nicht in Wochen – und plant den Betrieb von Anfang an mit. Ein typischer Ablauf:
| Phase | Dauer | Ergebnis |
|---|---|---|
| Discovery | 1–3 Wochen | Ziele, Nutzerrollen, Kernprozesse, Risiken |
| UX und Prototyping | 2–5 Wochen | Informationsarchitektur, Wireframes, klickbarer Flow |
| MVP-Entwicklung | 6–12 Wochen | erste produktnahe Version |
| Hardening | 2–6 Wochen | Tests, Performance, Security, Datenmigration |
| Launch und Betrieb | laufend | Monitoring, Support, Weiterentwicklung |
Eine erste produktive Version entsteht damit häufig in drei bis fünf Monaten. Schneller geht es, wenn Entscheidungen klar sind, Datenquellen verfügbar sind und der Umfang radikal priorisiert wird. Langsamer wird es, wenn Stakeholder unklar sind, Integrationen nicht getestet wurden oder das Produkt während der Entwicklung ständig seine Richtung ändert. Wie sich ein MVP sauber in eine Roadmap einbettet, zeigen wir in MVP entwickeln lassen.
Architektur: die Entscheidungen, die später Geld sparen
Die teuersten Fehler entstehen nicht im Code, sondern in frühen Architekturentscheidungen. Datenmodell, Rollenmodell und Betriebskonzept sind nach dem Launch nur mit hohem Aufwand zu ändern. Ein bewährter, langlebiger Default-Stack für SaaS-Web-Apps sieht 2026 so aus:
Im Frontend sind React und Next.js 16 eine starke Basis – mit Server-Rendering, Routing, Metadata-APIs und seit Version 16 standardmäßig dem React Compiler und Turbopack. Das Backend organisiert man sinnvoll API-first: Frontend, Admin, Mobile-App und Integrationen sprechen mit klar dokumentierten Endpunkten. Als Datenbank ist PostgreSQL 18 ein sehr belastbarer Standard mit relationaler Integrität, Transaktionen, Volltextsuche und JSON-Feldern. Auth und Rollen sind kein Formular, sondern Architektur: Rollen, Einladungen, Passwort-Reset, SSO, 2FA und oft Mandantenfähigkeit. Hosting und Betrieb schließlich umfassen Deployments, Rollbacks, Backups, Logs und Monitoring – je nach Produkt auf Vercel, Hetzner, AWS oder Kubernetes. Wie wir Datenmodell und Schnittstellen sauber aufsetzen, zeigt unsere Backend-Entwicklung.
Performance, SEO und Barrierefreiheit
Nicht jede Web-App muss ranken – aber jede öffentlich erreichbare muss messbar schnell und barrierefrei sein. Ein interner Admin-Bereich braucht kein SEO; öffentliche Landingpages, Produktseiten und Dokumentation dagegen schon. Google misst Ladeleistung, Interaktivität und visuelle Stabilität über die Core Web Vitals: LCP, INP und CLS. Seit dem 12. März 2024 hat INP die alte FID-Metrik abgelöst – ein INP-Wert von höchstens 200 ms gilt als gut. Schlechte Werte entstehen meist durch große Client-Bundles, blockierende Skripte oder Layout-Sprünge.
Hinzu kommt die rechtliche Pflicht: Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG). Web-Apps, die sich als elektronische Dienstleistung an Endverbraucher richten, müssen die Anforderungen nach EN 301 549 bzw. WCAG 2.1 AA erfüllen; Kleinstunternehmen mit unter 10 Beschäftigten und höchstens 2 Mio. EUR Jahresumsatz sind bei Dienstleistungen ausgenommen. Barrierefreiheit ist deutlich günstiger, wenn sie von Anfang an mitgedacht wird – mehr dazu in unserer BFSG- und WCAG-Checkliste.
MVP oder direkt die volle Plattform?
Ein MVP ist kein billiges Produkt, sondern ein fokussiertes. Es ist sinnvoll, wenn Markt, Prozess oder Geschäftsmodell noch validiert werden müssen – sollte aber kein Wegwerfprodukt sein, sondern technisch sauber genug, um erweitert zu werden. Die falsche Frage lautet: "Was können wir weglassen, damit es billig wird?" Die richtige lautet: "Welche kleinste Version beweist den kritischsten Nutzen?"
Für eine SaaS-Web-App heißt das oft: zuerst ein Kernworkflow, ein einfaches Rollenmodell, manuelle Abrechnung und wenige Integrationen. Billing-Automatisierung, Reporting und tiefere Integrationen folgen, wenn der Nutzen bewiesen ist. Wie aus einem MVP eine tragfähige Plattform wird, beschreiben wir am Hamburger Praxisfall in Web-App-Entwicklung Hamburg.
Nächste Schritte
Drei Fragen schärfen die Planung schneller als jedes Feature-Brainstorming:
- Nutzer und Rollen: Wer arbeitet mit der Anwendung, und welche Berechtigungen brauchen sie?
- Daten und Integrationen: Welche Daten werden verändert, und welche Bestandssysteme müssen angebunden werden?
- Version 1: Welche kleinste Version beweist den wichtigsten Nutzen – und was kann bewusst warten?
Je klarer diese Antworten sind, desto genauer lassen sich Kosten, Dauer und Architektur planen. Wir starten Web-App-Projekte meist mit einem kurzen Architektur- und Produktworkshop. Sieh dir unsere Web-App-Entwicklung an oder buche direkt ein Erstgespräch.
