1. Was beeinflusst die App-Entwicklungskosten?
„Was kostet eine App?" ist ungefähr so präzise wie „Was kostet ein Auto?" Die Antwort lautet: zwischen 500 und 500.000 Euro — je nachdem, was Sie genau bauen. Wer Ihnen ohne Briefing einen Festpreis nennt, lügt oder unterschätzt das Projekt massiv.
Die relevanten Kostentreiber sind:
- Plattform: iOS, Android, oder beide? Native oder Cross-Platform?
- Komplexität des Backends: Einfache Datenbank oder komplexe Integrationen mit ERP, CRM, Zahlungsdienstleistern?
- Anzahl der Screens und Flows: Eine App mit 5 Screens kostet fundamental anders als eine mit 30.
- Nutzerauthentifizierung: Einfaches Login, Social Auth oder Multi-Faktor-Authentifizierung mit Rollen?
- Offline-Fähigkeit: Lokale Datenpersistenz und Sync-Logik verdoppeln oft den Entwicklungsaufwand.
- Design-Aufwand: Standardkomponenten oder vollständig maßgeschneidertes UI/UX-Design?
- Standort des Entwicklungsteams: DACH, Osteuropa oder Asien — Stundensätze variieren von 25 bis 150+ Euro.
Wichtig: Ein Angebot, das Sie nicht innerhalb von 2–3 Wochen erhält, hat das Projekt nicht ernst genommen. Seriöse Angebote basieren auf einem detaillierten Funktionskatalog — nicht auf einem Erstgespräch.
2. App-Typen im Kostenvergleich
Die Technologieentscheidung ist die erste und folgenreichste Kostenfrage. Hier ist der realistische Vergleich für 2026:
| App-Typ | Technologie | Typische Kosten | Am besten für |
|---|---|---|---|
| Native iOS | Swift / SwiftUI | 25.000–120.000 € | Performance-kritische Consumer-Apps, tiefe Hardware-Integration |
| Native Android | Kotlin / Jetpack Compose | 25.000–120.000 € | Geräte-Vielfalt, B2B-Umgebungen mit Android-Flotte |
| Cross-Platform | React Native / Flutter | 20.000–90.000 € | Die meisten Business-Apps — eine Codebasis für iOS & Android |
| Progressive Web App | React / Vue + PWA | 8.000–35.000 € | Interne Tools, B2B-Portale ohne App-Store-Anforderung |
Cross-Platform: Der Sweet Spot für die meisten Projekte
React Native (Meta) und Flutter (Google) haben sich 2026 als die dominanten Cross-Platform-Frameworks etabliert. Sie teilen 85–95 % der Codebasis zwischen iOS und Android, was die initialen Entwicklungskosten um 30–50 % gegenüber zwei separaten nativen Apps reduziert.
Die Einschränkungen sind real, aber für die meisten Business-Apps irrelevant: Hochperformante Spiele, Apps mit komplexen nativen Animationen oder tiefem Hardware-Zugriff (z. B. Bluetooth Low Energy in industriellen Szenarien) sind bei nativer Entwicklung besser aufgehoben. Für B2B-Apps, Mitarbeiter-Tools, Kundenbindungs-Apps und Marktplätze ist Cross-Platform die wirtschaftlichere Entscheidung.
Entscheidungshilfe: Wenn Ihre App primär Daten anzeigt, Formulare verarbeitet und mit einem Backend kommuniziert — und Sie keinen Kamera-Spezialzugriff oder komplexe Animationen brauchen — ist Cross-Platform die richtige Wahl. Für einen detaillierten Framework-Vergleich lesen Sie Flutter vs. React Native 2026.
3. Realistische Preisrahmen nach Komplexität
Komplexität ist der stärkste Kostentreiber. Hier sind realistische Bandbreiten für den DACH-Markt — basierend auf Projekten mit lokalen Agenturen und Freelancern mit Stundensätzen zwischen 80 und 130 Euro:
| Komplexitätsstufe | Merkmale | Entwicklungszeit | Kostenrahmen |
|---|---|---|---|
| Einfach | 5–10 Screens, einfache Datenbank, kein komplexes Backend, Standard-Auth | 6–10 Wochen | 15.000–40.000 € |
| Mittel | 15–25 Screens, REST-API, Nutzerrollen, Push-Notifications, Zahlungs-Integration | 12–20 Wochen | 40.000–90.000 € |
| Komplex | 30+ Screens, Echtzeit-Features, Offline-Sync, ERP/CRM-Integration, Admin-Dashboard | 24–40 Wochen | 90.000–200.000 € |
| Enterprise | Multi-Mandanten, komplexe Geschäftslogik, Compliance-Anforderungen, CI/CD | 6–18 Monate | 200.000+ € |
Diese Preisrahmen gelten für DACH-Entwickler oder -Agenturen. Osteuropäische Teams (Polen, Tschechien, Rumänien) liegen bei 40–70 % dieser Werte. Asiatische Offshore-Teams bei 20–40 % — mit entsprechend höherem Koordinationsaufwand und Qualitätsrisiko.
4. Versteckte Kosten: Was nach dem Launch kommt
Der häufigste Fehler bei der App-Budgetierung: Das Launch-Budget wird als Gesamtbudget behandelt. In Wirklichkeit ist der Launch der Beginn der laufenden Kosten. Eine App ist ein Produkt, das kontinuierliche Investitionen erfordert.
Wartung und Updates
Apple und Google veröffentlichen jährlich neue OS-Versionen — und API-Änderungen, die Anpassungen im Code erzwingen. Rechnen Sie mit 15–25 % der initialen Entwicklungskosten pro Jahr allein für Wartung und Kompatibilitätsupdates. Eine App, die nicht gepflegt wird, wird innerhalb von 2–3 Jahren unbrauchbar.
App-Store-Kosten
Apple Developer Program: 99 USD pro Jahr. Google Play Console: 25 USD einmalig. Für Unternehmen-Apps (Distribution ohne App Store) kostet das Apple Developer Enterprise Program 299 USD/Jahr. Dazu kommen die App-Store-Provisionen: Apple und Google nehmen 30 % (15 % für kleine Entwickler) auf In-App-Käufe und Abonnements.
Backend und Infrastruktur
Jede App mit Backend verursacht laufende Serverkosten. Kalkulieren Sie:
- Bis 1.000 aktive Nutzer: 30–100 Euro/Monat (Cloud-Instanzen, Datenbank, Storage)
- 1.000–10.000 Nutzer: 100–500 Euro/Monat
- 10.000+ Nutzer: 500–5.000 Euro/Monat (je nach Datenvolumen und API-Calls)
Push-Notification-Services (Firebase, OneSignal) sind bis zu einem bestimmten Volumen kostenlos, skalieren dann aber kostenpflichtig. Monitoring-Tools (Sentry, Datadog) kosten 20–200 Euro/Monat und sind für produktive Apps nicht optional.
Feature-Erweiterungen
Nutzer-Feedback nach dem Launch führt fast immer zu Erweiterungsanfragen. Planen Sie ein Jahresbudget von 20–30 % der Initialkostens für Feature-Entwicklung — oder bauen Sie von Anfang an eine Roadmap mit Priorisierung, um Budget-Überraschungen zu vermeiden.
Total Cost of Ownership: Eine App mit initialen Entwicklungskosten von 60.000 Euro verursacht typisch weitere 10.000–18.000 Euro pro Jahr an laufenden Kosten. Im Fünfjahreshorizont kostet die App damit 110.000–150.000 Euro. Diese Zahl gehört in jede Business-Case-Rechnung.
5. MVP-Budget: So kalkulieren Sie realistisch
Das MVP (Minimum Viable Product) ist der richtige Ansatz für die meisten neuen App-Projekte. Die Idee: Sie bauen nur die Kern-Features, die nötig sind, um den Product-Market-Fit zu validieren — und investieren erst dann in Erweiterungen, wenn Sie wissen, dass das Produkt funktioniert.
Schritt 1: Feature-Priorisierung
Erstellen Sie eine Liste aller gewünschten Features und kategorisieren Sie sie nach dem MoSCoW-Prinzip:
- Must-have: Ohne diese Features funktioniert das Kernprodukt nicht.
- Should-have: Wichtig, aber die App funktioniert ohne sie.
- Could-have: Nice-to-have für Version 2.0.
- Won't-have (jetzt): Explizit für später geplant.
Ihr MVP besteht ausschließlich aus Must-haves. Alles andere folgt nach der Validierung.
Schritt 2: Realistisches Budget definieren
Ein typisches MVP-Budget für eine Business-App im DACH-Raum liegt bei 25.000–60.000 Euro. Dazu brauchen Sie:
- UX-Design und Prototyping: 3.000–8.000 Euro
- Frontend-Entwicklung (Cross-Platform): 10.000–25.000 Euro
- Backend-Entwicklung und API: 8.000–20.000 Euro
- Testing und QA: 2.000–5.000 Euro
- App-Store-Deployment und Setup: 1.000–2.000 Euro
Schritt 3: Puffer einplanen
Kalkulieren Sie einen Puffer von 20–30 % auf Ihr Gesamtbudget. In der Praxis tauchen immer ungeplante Anforderungen auf: Der App-Store lehnt die erste Einreichung ab, ein Drittanbieter ändert seine API, oder erste Nutzer-Tests zeigen Usability-Probleme, die eine Überarbeitung erfordern.
Validieren, bevor Sie skalieren: Bringen Sie das MVP zu echten Nutzern, bevor Sie das volle Feature-Set entwickeln. Ein MVP mit 30.000 Euro Invest, das in 3 Monaten live geht, ist fast immer besser als ein Vollprodukt für 120.000 Euro nach einem Jahr Entwicklung ohne Nutzer-Feedback.
6. Stundensatz vs. Festpreis — was ist besser?
Diese Frage hören wir regelmäßig. Die ehrliche Antwort: Es kommt auf das Projekt und auf Ihr Verhältnis zur Entwicklungsorganisation an.
Festpreis
Ein Festpreisangebot gibt Ihnen Budgetsicherheit — aber nur wenn das Lastenheft wirklich vollständig ist. In der Praxis bedeutet ein Festpreis auf einem unvollständigen Lastenheft: Die Agentur kalkuliert Puffer für Unklarheiten ein (teuer) oder Sie zahlen für jeden Scope-Change extra (auch teuer). Festpreise funktionieren gut bei klar definierten, abgegrenzten Projekten.
Time & Material
Time & Material (T&M) nach Stundensatz ist flexibler und ehrlicher: Sie zahlen für tatsächlich geleistete Arbeit und können Prioritäten jederzeit anpassen. Der Nachteil: Das Budget ist nach oben offen. Kombinieren Sie T&M mit klaren Sprint-Zielen und einem definierten Gesamtrahmen, um das Beste aus beiden Welten zu erhalten.
| Modell | Vorteil | Nachteil | Empfehlung |
|---|---|---|---|
| Festpreis | Budgetsicherheit, klare Lieferdefinition | Inflexibel bei Änderungen, teurer Puffer | Nur bei vollständigem Lastenheft |
| Time & Material | Flexibel, ehrlich, Prioritäten änderbar | Offen nach oben ohne Steuerung | Mit Budget-Cap und Sprint-Zielen |
| Phasenmodell | MVP-Phase fest, dann T&M für Weiterentwicklung | Erfordert gutes Scope-Management | Best Practice für die meisten Projekte |