Was eine App wirklich kostet — und warum die falsche Technologiewahl teurer ist als die Entwicklung selbst

Ein mittelständischer Einzelhändler investierte 180.000 Euro in eine native iOS-App. Achtzehn Monate später warteten 60 % seiner Kunden — Android-Nutzer — immer noch auf eine Version für ihr Betriebssystem. Als die Android-App endlich live ging, brauchte die iOS-Version bereits ein größeres Update. Gesamtkosten: über 300.000 Euro. Eine Cross-Platform-Lösung hätte beide Plattformen gleichzeitig bedient — für rund 120.000 Euro.

Dieses Szenario ist kein Einzelfall. Es ist das Muster, das wir bei Golle IT in über 500 Projekten seit 2010 immer wieder beobachten: Die teuerste Entscheidung bei der App-Entwicklung ist nicht die Entwicklung selbst — sondern die falsche Technologiewahl. Und deren Kosten potenzieren sich über Jahre.

Dieser Artikel liefert Ihnen die Kosten-Nutzen-Analyse, die Sie brauchen, bevor Sie Ihr nächstes App-Projekt beauftragen. Keine Verkaufsbroschüre, sondern ein ehrliches Entscheidungsframework mit realen Zahlen, versteckten Kostenfallen und einer klaren Empfehlung, wann welcher Ansatz sinnvoll ist.

Die drei Entwicklungsansätze — ohne Fachjargon

Bevor wir über Kosten sprechen, müssen drei Begriffe klar sein. Nicht technisch, sondern geschäftlich.

Native Entwicklung

Zwei getrennte Apps, zwei getrennte Codebasen: eine für iOS (Swift), eine für Android (Kotlin). Maximale Plattformintegration, maximaler Aufwand. Jede Funktion wird zweimal gebaut, zweimal getestet, zweimal gewartet. Ergibt Sinn, wenn Sie hardwarenahe Features brauchen — etwa AR-Anwendungen, die das letzte Quäntchen Kameraleistung ausreizen. Für die allermeisten Geschäftsanwendungen ist es schlicht Overengineering.

Cross-Platform (Flutter, React Native)

Eine Codebasis, zwei Plattformen. Flutter (von Google) und React Native (von Meta) sind die dominierenden Frameworks. Die App wird einmal geschrieben und läuft auf iOS und Android — bei Flutter sogar auf Desktop und Web. Die Performance-Lücke zu nativen Apps hat sich seit 2022 dramatisch geschlossen. Der Kostenvorteil nicht.

Progressive Web App (PWA)

Eine Webseite, die sich wie eine App anfühlt. Kein App Store, keine Installation nötig. Funktioniert für einfache Anwendungsfälle — Informationsportale, einfache Buchungssysteme. Stößt an Grenzen bei Offline-Funktionalität, Push-Benachrichtigungen auf iOS und hardwarenahem Zugriff. Für die meisten Unternehmen, die eine „echte" App planen, eher ein Zwischenschritt als eine Lösung.

Die entscheidende Erkenntnis: Die Wahl zwischen diesen Ansätzen ist keine Technologieentscheidung. Es ist eine Geschäftsentscheidung — über Budget, Teamstruktur, Wartungsfähigkeit und Marktgeschwindigkeit.

Die echte Kostenmatrix: Was Sie wirklich einplanen müssen

Die meisten Kostenleitfäden zeigen Ihnen eine Tabelle mit Entwicklungskosten und hören dann auf. Das ist, als würden Sie beim Autokauf nur den Listenpreis vergleichen und Versicherung, Wartung und Kraftstoff ignorieren.

Initiale Entwicklungskosten nach Komplexität

Die folgenden Zahlen basieren auf Branchenschätzungen mehrerer unabhängiger Quellen. Unabhängige Benchmarkdaten für den DACH-Markt sind begrenzt verfügbar — die Bandbreiten sind aber über verschiedene Quellen hinweg konsistent genug, um als belastbare Orientierung zu dienen. Beachten Sie: DACH-Entwicklerraten liegen über dem globalen Durchschnitt, weshalb Ihre Projekte eher am oberen Ende der Spannen landen werden.

Die meisten KMU-Projekte im DACH-Raum landen in der mittleren Komplexitätsstufe. Branchenschätzungen legen nahe, dass Cross-Platform-Entwicklung mit Flutter oder React Native 30–50 % der initialen Buildkosten gegenüber zwei separaten nativen Apps einspart. Anders formuliert: Dual-native Entwicklung kostet laut Branchenquellen 60–70 % mehr als der Cross-Platform-Ansatz.

Die 3-Jahres-Gesamtkosten — die Zahl, die wirklich zählt

Hier wird es interessant. Die initialen Buildkosten machen typischerweise nur 40–60 % dessen aus, was ein Unternehmen in den ersten drei Jahren für seine App ausgibt. Der Rest verteilt sich auf Wartung, Updates, OS-Kompatibilitätsfixes und Feature-Erweiterungen.

Die meisten Praktiker rechnen mit jährlichen Wartungskosten von 15–20 % der initialen Buildkosten. Das ist keine verifizierte Studie — es ist eine bewährte Faustregel aus der Praxis. Aber sie verändert die Kalkulation fundamental:

Das heißt: Die Einsparung durch Cross-Platform wächst mit jedem Jahr. Der Wartungskostenvorteil kompensiert nicht nur die initiale Differenz — er verstärkt sie. Bei einer dualen nativen Lösung müssen zwei Codebasen gepflegt, auf zwei Betriebssystem-Updates reagiert und zwei Test-Pipelines betrieben werden.

Die versteckten Kosten, die in keiner Agentur-Broschüre stehen

DSGVO-Compliance: Jede App, die Nutzerdaten verarbeitet — und das sind fast alle — braucht Consent Management, Datensparsamkeit und gegebenenfalls Datenresidenz in der EU. Das ist kein Häkchen auf einer Checkliste, sondern echter Entwicklungsaufwand. Planen Sie 5.000–15.000 Euro zusätzlich ein, je nach Datenkomplexität.

Barrierefreiheitsstärkungsgesetz (BFSG): Seit Juni 2025 müssen digitale Produkte, die an Verbraucher in Deutschland vertrieben werden, Barrierefreiheitsstandards erfüllen. Wer das nicht von Anfang an einplant, zahlt für nachträgliche Anpassungen ein Vielfaches. Barrierefreiheit nachzurüsten ist technisch komplex und teuer — sie von Tag eins mitzudenken kostet einen Bruchteil.

App-Store-Gebühren: Apples 15–30 % Provision auf In-App-Käufe und Abonnements ist keine Randnotiz — sie beeinflusst Ihr gesamtes Geschäftsmodell. Mehr dazu in unserem Artikel über In-App-Käufe.

OS-Update-Kompatibilität: Jedes Jahr bringen Apple und Google neue Betriebssystemversionen heraus. Jedes Jahr müssen Apps angepasst werden. Bei zwei nativen Codebasen verdoppelt sich dieser Aufwand.

Entwickler-Abhängigkeit: Und hier wird es strategisch wirklich relevant.

Warum die Technologieentscheidung eigentlich eine Personalentscheidung ist

Dieser Punkt wird in den meisten Kostenvergleichen ignoriert — dabei ist er für KMUs im DACH-Raum möglicherweise der wichtigste.

Wie Chop Dawg in ihrer 2026-Analyse treffend formuliert: „The real tradeoffs in 2026 go beyond performance benchmarks and touch on team structure, maintenance burden, and platform-specific UX expectations."

Übersetzen wir das in die Realität eines mittelständischen Unternehmens: Sie haben eine native iOS-App. Ihr einziger iOS-Entwickler kündigt. Jetzt stehen Sie vor der Wahl zwischen teuren Freelancer-Tagessätzen (im DACH-Raum 800–1.200 Euro pro Tag für erfahrene iOS-Entwickler) oder einem partiellen Rebuild. Beides ist schmerzhaft, beides ist teuer, beides war vermeidbar.

Eine Cross-Platform-App auf Flutter-Basis reduziert dieses Klumpenrisiko. Ein einziger Flutter-Entwickler kann beide Plattformen warten. Der Talentpool ist größer, die Abhängigkeit von einzelnen Personen geringer. Für ein Unternehmen mit 50–500 Mitarbeitern ist das kein theoretisches Argument — es ist praktisches Risikomanagement.

Fragen Sie sich: Wer in Ihrem Unternehmen wird die App nach dem Launch betreuen? Wenn die Antwort „niemand" oder „das soll die Agentur machen" lautet, haben Sie ein Problem, das keine Technologiewahl löst. Eine 200.000-Euro-App ohne internen Owner ist kein Asset — sie ist eine Verbindlichkeit.

Das Entscheidungsframework: 6 Fragen vor der ersten Zeile Code

Hier ist das Framework, das wir bei Golle IT in Kundengesprächen einsetzen, bevor ein Projekt startet. Keine Technologie-Debatte — stattdessen sechs Geschäftsfragen, die zur richtigen Antwort führen.

Frage 1: Wer sind Ihre Nutzer — und welche Plattform nutzen sie?

Prüfen Sie Ihre Webanalytics. Wenn mehr als 40 % Ihrer Zielgruppe Android nutzt — und in Deutschland liegt der Android-Marktanteil bei rund 65–70 % — ist eine reine iOS-Lösung von Tag eins an ein strategischer Fehler. Cross-Platform ist hier der Standardfall, nicht die Ausnahme.

→ Mehr als 40 % Android-Nutzer? Cross-Platform.

Frage 2: Wie sieht Ihr 3-Jahres-Budget aus — nicht nur Ihr Buildbudget?

Wenn Ihr Gesamtbudget über drei Jahre bei 150.000 Euro liegt, können Sie sich keine duale native Entwicklung leisten — selbst wenn die initiale Buildkosten noch passen würden. Die Wartung frisst den Rest. Kalkulieren Sie immer mit dem TCO.

→ Budget unter 200.000 € für 3 Jahre? Cross-Platform.

Frage 3: Brauchen Sie hardwarenahe Performance oder plattformspezifische Features?

AR-Anwendungen, die die neuesten Kamera-APIs nutzen. Bluetooth-Low-Energy-Integration mit Industriesensoren. Hochperformante 3D-Grafik. Das sind die Fälle, in denen native einen echten Vorteil bringt. Für eine Bestell-App, ein CRM-Frontend oder ein Kundenportal? Brauchen Sie nicht.

→ Keine Spezial-Hardware-Integration? Cross-Platform.

Frage 4: Haben Sie nach dem Launch einen internen technischen Owner?

Ohne jemanden, der Prioritäten für Updates setzen, Nutzerfeedback bewerten und die Agenturbeziehung steuern kann, wird jede App zum Kostengrab. Das ist keine Technologiefrage — aber sie beeinflusst die Technologiewahl. Eine Cross-Platform-App ist leichter zu übergeben und zu warten als zwei native Codebasen.

→ Kein internes Tech-Team? Cross-Platform, mit Wartungsvertrag.

Frage 5: Was sind Ihre Compliance-Anforderungen?

DSGVO ist Pflicht für praktisch jede App. BFSG-Konformität seit Juni 2025 für B2C-Apps. Branchenspezifische Regulierung (Finanzdienstleistungen, Gesundheitswesen) kommt obendrauf. Compliance-Anforderungen erhöhen den Scope — und bei zwei nativen Codebasen müssen sie zweimal implementiert und zweimal geprüft werden.

→ Hohe Compliance-Anforderungen? Cross-Platform (einmal implementieren, überall konform).

Frage 6: MVP oder Produktivsystem?

Wenn Sie einen Markt testen wollen, bauen Sie ein MVP. Schnell, schlank, lernfähig. Wenn Sie ein System bauen, das ab Tag eins Umsatz generieren soll, planen Sie anders. Die gefährlichste Falle: mit einem „einfachen" MVP starten und dann Feature für Feature nachrüsten, ohne die Architektur dafür ausgelegt zu haben. Unternehmen, die so vorgehen, geben oft mehr aus als solche, die von Anfang an für mittlere Komplexität planen.

→ Markttest? Schlankes MVP, Cross-Platform. Produktivsystem? Sauber planen, Cross-Platform mit Skalierungsarchitektur.

Die Kurzformel

Für die überwiegende Mehrheit der DACH-KMUs lautet die Empfehlung: Cross-Platform mit Flutter. Die Fälle, in denen native Entwicklung wirklich die bessere Wahl ist — Spezial-Hardware, Hochleistungs-Grafik, plattformspezifische AR/VR — sind im typischen Mittelstandskontext selten. Die Performance-Lücke zwischen Flutter und nativ hat sich dramatisch geschlossen. Die Kostenlücke nicht.

Drei Projektbeispiele aus der Praxis

Die folgenden Beispiele sind anonymisierte Composites, die auf realen Projekterfahrungen basieren. Die Zahlen sind repräsentativ, nicht exakt.

Beispiel 1: B2B-Bestell-App für einen Großhändler

Kontext: Ein Großhändler mit 200 Mitarbeitern wollte seinen Außendienst von Papier-Bestellformularen auf eine mobile Lösung umstellen. 80 Außendienstmitarbeiter, gemischte Geräteflotte (iOS und Android).

Entscheidung: Flutter, mittlere Komplexität. Offline-Fähigkeit, Anbindung an bestehendes ERP via REST-API, Barcode-Scanner.

Kosten: 85.000 Euro Build, 14.000 Euro/Jahr Wartung. 3-Jahres-TCO: 127.000 Euro.

Ergebnis: Bestellfehlerquote um 40 % reduziert, durchschnittliche Bestellzeit von 12 Minuten auf 3 Minuten. ROI nach 14 Monaten.

Was wäre nativ passiert? Geschätzte Buildkosten: 140.000 Euro. 3-Jahres-TCO: über 200.000 Euro. Gleiche Funktionalität, doppelter Preis.

Beispiel 2: Kunden-App für eine regionale Versicherung

Kontext: Eine Versicherung mit 15.000 Kunden wollte Schadensmeldungen digitalisieren und einen Self-Service-Bereich anbieten. Strenge Compliance-Anforderungen (DSGVO, BaFin-Regulierung).

Entscheidung: Flutter, hohe Komplexität. Dokumenten-Upload mit Verschlüsselung, biometrische Authentifizierung, Push-Benachrichtigungen, BFSG-konforme Barrierefreiheit.

Kosten: 165.000 Euro Build, 28.000 Euro/Jahr Wartung. 3-Jahres-TCO: 249.000 Euro.

Ergebnis: 35 % der Schadensmeldungen laufen nach 6 Monaten über die App. Sachbearbeiter-Entlastung um geschätzte 20 %.

Schlüssel-Insight: Die BFSG-Konformität war von Anfang an eingeplant und kostete ca. 12.000 Euro zusätzlich im Build. Ein nachträgliches Retrofit hätte nach Schätzung des Entwicklungsteams 30.000–40.000 Euro gekostet.

Beispiel 3: MVP für ein Fitness-Startup

Kontext: Ein Gründerteam wollte eine Fitness-App mit personalisiertem Trainingsplan testen. Budget: 40.000 Euro. Zeitdruck: 8 Wochen bis zum Markttest.

Entscheidung: Flutter, einfaches MVP. User-Registrierung, Trainingsplan-Anzeige, einfaches Tracking, Push-Benachrichtigungen.

Kosten: 32.000 Euro Build, 5.000 Euro/Jahr Wartung.

Ergebnis: 2.000 Downloads in den ersten 3 Monaten, genug Validierung für eine Series-A-Finanzierung. Die App wurde anschließend zur mittleren Komplexität ausgebaut — weil die Flutter-Architektur von Anfang an skalierbar angelegt war.

Was hätte schiefgehen können? Wäre das MVP nativ nur für iOS gebaut worden, hätten 65 % der Zielgruppe (junge, fitnessaffine Nutzer mit überdurchschnittlich hohem Android-Anteil) keinen Zugang gehabt. Der Markttest wäre nicht aussagekräftig gewesen.

Der AI-Faktor: Wie KI die Kostenstruktur verändert

Wir wären keine ehrliche Softwareagentur mit AI-Fokus, wenn wir diesen Punkt ignorieren würden.

Tools wie GitHub Copilot, Cursor und KI-gestütztes Testing komprimieren Entwicklungszeiten messbar. Einige Entwicklungsteams berichten von 20–40 % schnellerer Auslieferung bei Standardfunktionen. Belastbare, unabhängige Benchmarkdaten dazu gibt es allerdings noch nicht — die Auswirkungen auf die Preisgestaltung arbeiten sich gerade erst durch den Markt.

Was wir beobachten: AI-Tooling profitiert Cross-Platform-Entwicklung stärker als native. Die Tooling-Ökosysteme für Flutter/Dart und React Native/JavaScript sind in AI-gestützten Entwicklungsumgebungen weiter ausgereift. Das bedeutet: Der Kostenvorteil von Cross-Platform wird durch AI tendenziell noch größer, nicht kleiner.

Die strategische Implikation: Das Entscheidungsframework ändert sich durch AI nicht. Aber die Einsparungen durch die richtige Technologiewahl realisieren sich schneller. Wer heute die falsche Entscheidung trifft, zahlt den Preis nicht erst in drei Jahren — sondern merkt es bereits nach zwölf Monaten.

Was die meisten Kostenvergleiche falsch machen

Die meisten Artikel behandeln die Technologieentscheidung als die primäre Entscheidung. Das ist sie nicht.

Die primäre Entscheidung lautet: Welches Problem löst diese App — und für wen? Die Technologie folgt daraus. Ein Artikel, der mit „So viel kostet Flutter" anfängt, löst das falsche Problem. Ein Unternehmen, das mit „Unsere Kunden brauchen X, und dafür ist Y der effizienteste Weg" anfängt, trifft bessere Entscheidungen.

Der zweite blinde Fleck: organisatorische Readiness. Hat Ihr Unternehmen jemanden, der die App nach dem Launch ownen kann? Der Prioritäten setzt, Nutzerfeedback auswertet, die Roadmap steuert? Wenn nicht, ist das kein Technologieproblem — aber es macht jede Technologieentscheidung riskanter.

Und der dritte: Scope Creep. Die Komplexitätsstufen in unserer Kostenmatrix sind keine festen Kategorien. Ein Unternehmen, das mit einem „einfachen" MVP startet und dann Feature um Feature nachrüstet, gibt oft mehr aus als eines, das von Anfang an für mittlere Komplexität geplant hat. Jede nachträgliche Erweiterung einer nicht dafür ausgelegten Architektur ist teurer als der gleiche Scope im initialen Design.

Ihr nächster Schritt

Die Unternehmen, die bei der App-Entwicklung die besten Ergebnisse erzielen, sind nicht die mit den größten Budgets. Es sind die, die vor der ersten Zeile Code die richtigen Fragen gestellt haben.

Das Entscheidungsframework aus diesem Artikel — die sechs Fragen, die Kostenmatrix, die 3-Jahres-TCO-Berechnung — ist das Werkzeug, mit dem wir bei Golle IT jedes Kundenprojekt starten. Nutzen Sie es, bevor Sie Ihr erstes Agenturgespräch führen.

Sie planen eine App und wollen vor dem Start Klarheit über Technologie, Kosten und Zeitrahmen? Sprechen Sie mit uns — in einem unverbindlichen Erstgespräch ordnen wir Ihr Vorhaben ein und geben Ihnen eine ehrliche Einschätzung, welcher Ansatz für Ihre Situation der richtige ist. Keine Verkaufspräsentation, sondern eine fundierte Standortbestimmung.

Oder starten Sie mit unserem Leitfaden für KMU-Entscheider zur App-Entwicklung — dort finden Sie den kompletten Prozess von der Idee bis zum Launch.

Die falsche App zu bauen ist fast immer teurer als gar keine App zu bauen. Die richtige App zum richtigen Zeitpunkt mit der richtigen Technologie zu bauen, ist eine der besten Investitionen, die ein mittelständisches Unternehmen heute machen kann.