Beginnen Sie mit der Frage, ob Sie eine App benötigen
Die teuerste Entscheidung für eine App wird getroffen, bevor auch nur eine Zeile Code geschrieben ist: überhaupt eine zu bauen.
Eine App muss im Store gefunden, installiert, Berechtigungen erteilt und dann auf einem Startbildschirm behalten werden, den ihr Besitzer regelmäßig aufräumt. Das ist viel Reibung. Es lohnt sich, diese zu überwinden, wenn die App etwas bietet, was eine Website nicht kann:
- Offline-Funktionalität – Außendienstmitarbeiter, Lieferfahrer, überall mit unzuverlässigem Signal
- Push-Benachrichtigungen – echte nützliche, keine Marketing-Sendungen
- Gerätehardware – Kameraschnittstellen, Bluetooth-Peripheriegeräte, Hintergrundortung
- Häufige Nutzung – etwas, das die meisten Tage geöffnet wird, wo das Sparen von drei Sekunden sich summiert
Trifft keiner dieser Punkte zu, erreicht eine schnelle, gut gebaute mobile Website mehr Menschen für weniger Geld. Wir sagen unseren Kunden das regelmäßig, und es ist meist das Wertvollste, was in einem ersten Gespräch gesagt wird.
Was eine App in Großbritannien tatsächlich kostet
Veröffentlichte "App-Kostenrechner" sind Marketinginstrumente. Hier sind die Bereiche, auf die wir uns bei einer seriösen britischen Agentur beziehen:
| Leistungsumfang | Typischer Bereich |
|---|---|
| Einzelplattform, fokussierter Funktionsumfang | £15.000 – £30.000 |
| Cross-Plattform, iOS und Android | £22.000 – £45.000 |
| Mit Zahlungen, Live-Daten oder Offline-Synchronisation | £35.000 – £70.000 |
| Laufende Wartung, pro Jahr | 15–20 % der Entwicklungskosten |
Die letzte Zeile ist diejenige, die die meisten Budgets auslassen, und sie ist unverzichtbar. iOS und Android veröffentlichen jedes Jahr eine neue Hauptversion. Google erhöht jährlich die Ziel-API-Anforderung und entfernt Apps, die nicht mehr aktuell sind. Eine App ohne Wartungsbudget hat eine Lebensdauer von etwa zwei Jahren.
Alles, was unter £8.000 angeboten wird, ist entweder ein White-Label-Template oder ein Festpreis, der nachverhandelt wird, sobald die kniffligen Teile auftauchen.
Native oder Cross-Plattform
Dies ist die Entscheidung, die die Kosten am stärksten beeinflusst, daher lohnt es sich, die Abwägungen klar zu machen, statt sie als Geschmacksfrage zu behandeln.
Plattformübergreifend (Flutter, React Native) bedeutet ein Codebase, das sowohl Apps für iOS als auch Android erzeugt. Sie sparen etwa 30–40 % bei der Entwicklung und deutlich mehr im Laufe der Zeit, da nur eine Funktionsmenge synchron gehalten werden muss und nicht zwei. Bei der überwiegenden Mehrheit der Business-Apps — Buchung, Bestellung, Dashboards, interne Tools — bemerkt der Nutzer keinen Unterschied.
Nativ (Swift, Kotlin) bedeutet zwei Codebasen und zwei Teams mit Plattform-Know-how. Die richtige Wahl, wenn die App stark auf die Hardware angewiesen ist: durchgehende Kameraverarbeitung, Hintergrund-Ortung, ARKit oder Animationen, bei denen eine Rendering-Schicht dazwischen sichtbar wird.
Die zweite Frage ist, wer die App später wartet. Wenn Ihr Team bereits React nutzt, ermöglicht React Native die gemeinsame Nutzung von Fähigkeiten und Teilen des Codes mit Ihrer Web-App, was häufig Flutters technischem Vorteil überwiegt. Haben Sie kein internes Mobile-Team, ist Flutter die technisch sicherere Wahl. In beiden Fällen ist der Arbeitsmarkt, in den Sie rekrutieren, wichtiger als jede Benchmark.
Wo Budgets leise verschwinden
Fünf Punkte verursachen die meisten Budgetüberschreitungen bei Projekten, die wir von anderen übernehmen.
1. Offline-Verhalten als Randfall behandelt
„Es muss offline funktionieren“ klingt nach einer Funktion. Es ist eine Architekturentscheidung. Nachträgliches Einbauen von lokaler Speicherung und Konfliktlösung in eine App, die auf Live-API-Aufrufe ausgelegt ist, kommt einer kompletten Neuentwicklung gleich. Entscheiden Sie das in Woche eins.
2. Push-Benachrichtigungen erst zum Schluss hinzugefügt
Benachrichtigungen erfordern Serverinfrastruktur, Berechtigungsflüsse, Segmentierung und Deep Links, die die richtige Bildschirmseite öffnen. Werden sie erst zum Schluss hinzugefügt, enden sie als „Allen dieselbe Nachricht senden“, was Nutzer dazu bringt, sie zu deaktivieren — und damit den Retentionshebel verliert, für den die App eigentlich gebaut wurde.
3. Store-Review nicht eingeplant
Erste Einreichungen bei Apple werden häufig abgelehnt. Nicht wegen schwerwiegender Fehler: fehlende Datenschutzangaben, unklare Abo-Bedingungen, fehlende Möglichkeit zum Löschen des Kontos, falsche Darstellung auf iPads bei Universal-Apps. Ein Zeitplan ohne Puffer für ein oder zwei Review-Runden ist ein Zeitplan, der öffentlich rutschen wird.
4. Backend als Nachgedanken betrachtet
Die meisten Apps sind eine Benutzeroberfläche für einen Service. Existiert dieser Service nicht, beauftragen Sie zwei Projekte. Existiert das Backend bereits, ist dessen API oft für eine Website ausgelegt und muss für Mobile umgestaltet werden — mehr Chats, Paginierung und Payloads, die für mobile Verbindungen optimiert sind.
5. Nur auf einem Top-Gerät getestet
Das ist vor allem ein Android-Problem, und ein großes. Eine App, die auf einem aktuellen Top-Gerät läuft, kann auf dem Mittelklasse-Handy, das ein erheblicher Teil der Nutzer in Großbritannien besitzt, unbrauchbar sein. Kommen noch Hersteller-Batterie-Manager hinzu, die Hintergrundprozesse beenden, wird aus „Benachrichtigungen funktionieren nicht“ Ihr häufigster Support-Fall.
Ein realistischer Zeitplan
Für eine plattformübergreifende Business-App:
- Abgrenzung und Design — 3 bis 4 Wochen. Funktionsliste, Abläufe und Oberflächendesign werden auf echten Geräten geprüft.
- Kernentwicklung — 8 bis 12 Wochen in zweiwöchigen Zyklen, jeder endet mit einer installierbaren Version.
- Beta-Test — 2 Wochen mit echten Nutzern über TestFlight und Play-Internaltest.
- Store-Einreichung — 1 bis 3 Wochen inklusive wahrscheinlicher Review-Runden.
- Nach dem Launch — 30 Tage für Fehlerbehebungen, danach Wartung.
Rund vier bis fünf Monate. Eine Verkürzung bedeutet meist, dass der Beta-Test entfällt — und genau das ist der Teil, der Probleme aufdeckt, die Ihre Nutzer sonst öffentlich in Store-Reviews melden würden.
Was Sie jede Agentur vor der Unterschrift fragen sollten
- Wem gehört der Code, und erhalten wir das Repository?
- Sind die Entwicklerkonten auf uns oder auf Sie registriert?
- Was passiert, wenn Apple die Einreichung ablehnt — wird das in Rechnung gestellt?
- Wie hoch sind die jährlichen Wartungskosten, schriftlich festgehalten?
- Auf welchen konkreten Geräten wird getestet?
- Was passiert mit der App, wenn wir die Zusammenarbeit beenden?
Die Antworten auf diese sechs Fragen sagen mehr aus als jedes Portfolio. Zögert die Agentur bei einer der Fragen, ist das Ihre Antwort.
Nächste Schritte
Wenn Sie eine App in Betracht ziehen, ist das nützliche erste Gespräch nicht über Features — es geht darum, ob die App die richtige Lösung für das Problem ist. Wir führen dieses Gespräch gerne und sagen Ihnen auch, wenn die Antwort eine Website ist.
Häufig gestellte Fragen
Eine fokussierte Single-Platform-App kostet typischerweise £15.000 bis £30.000. Cross-Platform für iOS und Android liegt meist bei £22.000 bis £45.000, abhängig vom benötigten Backend-Aufwand. Apps mit Zahlungen, Live-Daten oder Offline-Sync liegen im oberen Bereich. Alles, was unter £8.000 angeboten wird, ist meist eine Vorlage mit Ihrem Logo.
Zwölf bis zwanzig Wochen vom festgelegten Umfang bis zur ersten Veröffentlichung für die meisten Business-Apps, zuzüglich ein bis drei Wochen für die Store-Prüfung. Die größte Variable ist nicht die Entwicklungsgeschwindigkeit, sondern wie schnell Entscheidungen und Inhalte von Ihrer Seite zurückkommen.
Plattformübergreifend mit Flutter oder React Native eignet sich für die meisten Business-Apps und spart etwa 30–40 % gegenüber einer doppelten Entwicklung. Native Entwicklung lohnt sich, wenn Sie auf anspruchsvolle Gerätefunktionen wie erweiterte Kameraverarbeitung, Hintergrundortung oder komplexe kontinuierliche Animationen angewiesen sind.
Oft nicht. Wenn Ihre Nutzer die App nur etwa einmal im Monat nutzen würden, ist eine schnelle mobile Website die bessere und deutlich günstigere Lösung — niemand installiert eine App, die er nur gelegentlich nutzt. Eine App lohnt sich, wenn Offline-Zugriff, Push-Benachrichtigungen, Gerätehardware oder tatsächlich häufige Nutzung erforderlich sind.
- App-Entwicklung
- mobile
- budgeting
- iOS
- Android