Mobile-App-Entwicklungsservices: Ein Leitfaden für die richtige Plattformwahl

Unternehmen, die Mobile-App-Entwicklungsservices bewerten holen regelmäßig drei Angebote ein, deren Preise sich um das Fünffache unterscheiden und die keine gemeinsame Vergleichsgrundlage bieten. Der erste Impuls besteht darin, die Zahlen zu hinterfragen. Das ist jedoch der falsche Ansatz, denn die Preisspanne ist meist ein Symptom einer noch nicht getroffenen Entscheidung und kein tatsächlicher Preisunterschied.

Zwei Entscheidungen bestimmen die Entwicklung einer mobilen Anwendung. Sie müssen in der richtigen Reihenfolge getroffen werden. Werden sie vertauscht, entstehen nicht vergleichbare Angebote und eine Framework-Entscheidung, die achtzehn Monate später teuer werden kann. Die erste Entscheidung legt fest, was das Produkt tatsächlich benötigt. Die zweite bestimmt, wer diese Anforderungen umsetzen und auch nach dem Launch Verantwortung übernehmen kann.

Wichtige Highlights:

• Angebote für dieselbe App weisen Preisunterschiede bis zum Fünffachen auf, weil keine gemeinsame Anforderungsdefinition existiert, auf deren Grundlage Anbieter kalkulieren können.
• Treffen Sie zuerst die Plattformentscheidung auf Grundlage der Produktanforderungen und bewerten Sie anschließend Partner anhand von Architektur, Testing und Release-Verantwortung innerhalb dieser festgelegten Definition.
• Dadurch werden Angebote vergleichbar und die Framework-Wahl führt im zweiten Jahr nicht plötzlich zu kostspieligen Neuentwicklungen.
• Sigma wählt das Framework anhand der tatsächlichen Anforderungen und nicht nach verfügbaren internen Ressourcen aus. Das kann auch bedeuten, eine kostengünstigere Option zu empfehlen.

Mobile-App-Entwicklungsservices werden häufig in der falschen Reihenfolge eingekauft

Mobile-App-Entwicklungsservices umfassen Design, Engineering, Veröffentlichung und den laufenden Betrieb von Anwendungen, die über den Apple App Store und Google Play bereitgestellt werden. Die meisten Käufer beginnen mit der Einholung von Angeboten. Dadurch sollen Anbieter ein Ergebnis kalkulieren, das noch gar nicht ausreichend spezifiziert wurde. Jeder Anbieter ersetzt fehlende Angaben stillschweigend durch eigene Annahmen zu Plattform, Umfang und Qualitätsniveau. Die daraus entstehenden Angebote sind daher kaum sinnvoll vergleichbar, und der Käufer vergleicht am Ende eher das Auftreten der Anbieter als deren tatsächliche Leistung.

Die funktionierende Reihenfolge kehrt diesen Ablauf um. Zuerst wird eine ausreichend detaillierte Anforderungsdefinition erstellt, die die Plattformwahl klar eingrenzt und unabhängig von einem Anbieter mit kommerziellem Eigeninteresse entsteht. Anschließend kalkulieren alle Anbieter dieselbe definierte Leistung. Die verbleibenden Unterschiede beruhen dann tatsächlich auf Vorgehensweise, Teamzusammensetzung und enthaltenem Leistungsumfang. Allein diese Änderung der Reihenfolge beseitigt einen Großteil der extremen Preisunterschiede und zeigt, welche Anbieter zuvor von unklaren Anforderungen profitiert haben.

Erstellen Sie eine Anforderungsdefinition, die konkurrierende Angebote wirklich vergleichbar macht.

Entscheidung eins: Zuerst die Produktanforderungen, dann die Präferenzen des Teams

Die Plattformwahl sollte sich aus vier Produkteigenschaften ergeben, und keine davon ist eine Frage persönlicher Präferenz. An erster Stelle steht die Hardware-Abhängigkeit: kontinuierliche Kameraverarbeitung, Bluetooth-Peripherie, Standortverfolgung im Hintergrund oder On-Device-Inferenz sprechen eher für eine native Entwicklung, da Cross-Platform-Abstraktionen bei solchen Funktionen häufig hinter den zugrunde liegenden Plattformen zurückliegen und diese Verzögerung meist genau unter Release-Druck sichtbar wird. An zweiter Stelle steht die Erwartung an die Benutzeroberfläche. Ein Produkt, das Nutzer direkt mit führenden nativen Anwendungen derselben Kategorie vergleichen, muss einen höheren Anspruch erfüllen als ein internes Tool.

Die Release-Frequenz ist die dritte Produkteigenschaft und wird besonders häufig unterschätzt. Ein Produkt, das monatlich auf zwei Plattformen veröffentlicht wird, profitiert stark von einer gemeinsamen Codebasis, während ein Produkt mit nur zwei Releases pro Jahr deutlich weniger davon hat. Die vierte Eigenschaft ist die langfristige Teamkontinuität. Dabei handelt es sich eher um eine geschäftliche als um eine technische Frage: Zwei native Codebasen dauerhaft zu betreiben bedeutet, langfristig zwei unterschiedliche Kompetenzprofile verfügbar halten zu müssen – weit über die eigentliche Entwicklungsphase hinaus.

React Native kann eine Code-Wiederverwendung von bis zu 70 % zwischen iOS und Android ermöglichen und macht damit den gemeinsam nutzbaren Code zu einem der größten Vorteile der Cross-Platform-Entwicklung. Dieser Wert sollte jedoch nicht als Garantie für jede Anwendung verstanden werden. Die verbleibende plattformspezifische Arbeit konzentriert sich häufig auf besonders wichtige Funktionen, etwa Hardware-Integrationen, native APIs, performancekritische Workflows oder plattformspezifische UX. Ein Produkt kann daher insgesamt eine hohe Code-Wiederverwendung erreichen und dennoch für einige wenige geschäftskritische Funktionen umfangreiches natives Engineering benötigen.

Bei der obigen Tabelle ist eine wichtige Einschränkung zu beachten. Diese Eigenschaften werden gemeinsam gewichtet und nicht einfach gezählt. Ein einziges starkes Signal kann drei schwächere überwiegen. Wenn der gesamte Produktwert beispielsweise von kontinuierlicher Sensorverarbeitung abhängt, ist eine native Entwicklung die richtige Wahl, selbst wenn Release-Frequenz und Wartungsmodell eigentlich für Cross-Platform sprechen. Die Eigenschaft, die das Produkt wesentlich definiert, muss die Entscheidung bestimmen. Käufer, die alle Kriterien gleich gewichten und anschließend nach Mehrheit entscheiden, erhalten zwar scheinbar nachvollziehbare Ergebnisse, können aber genau an der wichtigsten Anforderung scheitern.

Warum Angebote für dieselbe Anwendung um das Fünffache variieren

Vier Variablen erklären nahezu die gesamte Preisspanne, und sie direkt anzusprechen ist deutlich sinnvoller als lediglich über Stundensätze zu verhandeln. Der größte Faktor ist die Interpretation des Umfangs: Ein Anbieter kalkuliert nur die beschriebenen Funktionen, während ein anderer zusätzlich Authentifizierung, Offline-Verhalten, Fehlerbehandlung und administrative Tools einrechnet, die zwar impliziert, aber nicht ausdrücklich genannt wurden. Der zweite Faktor ist das Qualitätsniveau, einschließlich automatisierter Testabdeckung, Barrierefreiheit und Umfang der Geräte-Matrix. Keiner dieser Punkte erscheint typischerweise in einer reinen Feature-Liste, alle beeinflussen den Aufwand jedoch erheblich.

Die Backend-Annahme ist die dritte und besonders folgenreiche Variable. Ein Angebot, das von bereits vorhandenen APIs ausgeht, kalkuliert ein völlig anderes Projekt als eines, bei dem diese APIs zunächst entwickelt werden müssen. Die vierte Variable ist die Verantwortung nach dem Launch. Wenn ein Angebot mit der Store-Freigabe endet, während ein anderes Monitoring, Crash-Triage und Betriebssystem-Upgrades umfasst, handelt es sich nicht um einen kleinen Einzelposten, sondern um eine mehrjährige Verpflichtung. Sigmas veröffentlichte Schätzung ordnet eine Anwendung mittlerer Komplexität für ein mittelgroßes Unternehmen im Bereich von 40.000 bis 100.000 US-Dollar ein. Angebote weit außerhalb dieser Spanne beschreiben daher meist einen deutlich anderen Umfang und nicht einfach nur einen anderen Preis.

Entscheidung zwei: Einen Partner anhand von Architektur, Testing und Release-Verantwortung bewerten

Sobald der Umfang festgelegt ist, unterscheiden sich Anbieter vor allem in drei Bereichen, die in einem Portfolio nicht sichtbar sind. Architektonische Disziplin zeigt sich beispielsweise daran, wie ein Kandidat auf die Frage nach einer Entscheidung reagiert, die er später bereut hat. Kann ein Anbieter keine solche Situation nennen, hat er entweder noch nicht lange genug ein Produkt betrieben, um die Folgen eigener Entscheidungen zu erleben, oder er antwortet nicht offen. Beide Möglichkeiten sind relevant.

Der zweite Bereich ist die Haltung zum Testing und zugleich einer der zuverlässigsten Indikatoren. Fragen Sie, was einen Release tatsächlich stoppt, welche Geräte die Testmatrix abdeckt und wie eine Regression überhaupt bis in die Produktion gelangen kann. Anbieter, die Testing als einzelne Phase statt als kontinuierliche Produkteigenschaft verstehen, beschreiben meist eine Quality-Assurance-Phase kurz vor dem Ende. Genau dort werden Fehler jedoch teuer, statt frühzeitig verhindert zu werden.

Der dritte Bereich ist die Release-Verantwortung. Die Veröffentlichung im Store richtet sich nach den veröffentlichten App Review Guidelines von Apple, die Anforderungen zu Sicherheit, Performance, Geschäftsmodell, Design und rechtlichen Aspekten abdecken. Ablehnungen sind dabei keine Ausnahme, sondern gehören zum normalen Prozess. Ein Partner mit Erfahrung aus wiederholten Review-Zyklen kann konkrete Ablehnungskategorien und typische Behebungsmuster benennen. Ein unerfahrener Anbieter wird die Einreichung dagegen eher als Formalität darstellen.

Referenzprüfungen sollten deutlich stärker gewichtet werden, als es häufig der Fall ist. Die entscheidende Frage lautet nicht, ob der Anbieter geliefert hat. Fragen Sie einen früheren Kunden, was passiert ist, als etwas schiefging – etwa ein verpasster Termin, ein Produktionsfehler oder eine Meinungsverschiedenheit über den Umfang. Jede länger laufende Zusammenarbeit enthält mindestens eine solche Situation. Das Verhalten des Anbieters in diesem Moment sagt deutlich mehr über die kommenden zwölf Monate aus als ein erfolgreicher Launch. Anbieter, die davon überzeugt sind, werden entsprechende Referenzen häufig selbst anbieten.

Die Reihenfolge der Entscheidungen bestimmt, ob eine Mobile-App-Entwicklung ihr erstes Jahr erfolgreich übersteht

Sigma strukturiert Mobile-Projekte nach einem klaren Prinzip: Jede Entscheidung, die später nur mit hohem Aufwand rückgängig gemacht werden kann, wird vor Entscheidungen getroffen, die sich leicht ändern lassen. Diese Reihenfolge klingt selbstverständlich, wird in der Praxis jedoch häufig verletzt, weil gerade die leicht reversiblen Entscheidungen sichtbar sind und den Eindruck vermitteln, das Projekt sei bereits weit vorangeschritten.

Zuerst wird die Anforderungsdefinition erstellt. Die Plattformentscheidung ist dabei ein Ergebnis und keine vorab gesetzte Vorgabe. Sigma führt diesen Schritt durch, bevor eine Teamzusammensetzung vorgeschlagen wird. Dadurch kann auch eine Empfehlung entstehen, die den Umfang und damit die Kosten reduziert. Ein Produkt mit geringer Hardware-Nutzung und hoher Release-Frequenz benötigt beispielsweise nicht zwingend zwei native Teams. Die Auswahl eines Frameworks anhand verfügbarer interner Ressourcen gehört zu den häufigsten Fehlern der Branche und ist für Käufer besonders schwer zu erkennen, weil sich die Entscheidung im Nachhinein fast immer technisch plausibel begründen lässt.

An zweiter Stelle stehen Backend- und Integrationsarchitektur, noch bevor an der Benutzeroberfläche gearbeitet wird. Der Grund ist strukturell: Datenmodell und Synchronisationsstrategie bestimmen, was die Oberfläche überhaupt leisten kann. Wird eine Oberfläche auf Grundlage eines nur angenommenen Backends entwickelt, entsteht Nacharbeit, sobald die tatsächlichen Einschränkungen sichtbar werden. Auch Offline-Verhalten gehört in diese Phase, denn es nachträglich in eine Anwendung einzubauen, die von permanenter Konnektivität ausgeht, kommt beinahe einer Neuentwicklung gleich.

Release Engineering folgt an dritter Stelle und wird vor der eigentlichen Feature-Entwicklung eingerichtet, nicht danach. Continuous Integration, Signing, Geräte-Matrix und Store-Submission-Prozess werden etabliert, solange noch kein kritischer Release davon abhängt. Dadurch ist der erste Produktionsrelease lediglich eine Wiederholung eines bereits getesteten Ablaufs statt eines ersten Versuchs unter Zeitdruck. Teams, die diesen Schritt aufschieben, entdecken Submission-Probleme häufig genau in der Woche des geplanten Launches. In diesem Moment werden Plattformrichtlinien von einer Dokumentationsfrage zu einem echten Terminrisiko.

Die Feature-Entwicklung kommt zuletzt. Das wirkt für Stakeholder oft ungewohnt, wenn Fortschritt vor allem anhand sichtbarer Screens bewertet wird. Sigma macht diesen Trade-off deshalb von Beginn an transparent: In den ersten Wochen entstehen vor allem technische Grundlagen statt eindrucksvoller Demonstrationen. Wurde dieses Vorgehen nicht vorher abgestimmt, kann ein Kunde genau in dem Moment Vertrauen verlieren, in dem die gewählte Reihenfolge ihren größten Nutzen entfaltet.

Eine Auswirkung dieser Reihenfolge sollte klar benannt werden, weil sie eher die wirtschaftliche als die technische Diskussion betrifft. Ein sauber sequenziertes Projekt wirkt im ersten Drittel seiner Laufzeit langsamer und beschleunigt anschließend. Ein unstrukturiertes Projekt wirkt anfangs schneller und verliert später an Tempo, weil grundlegende Entscheidungen unter Zeitdruck erneut aufgerollt werden müssen. Beide können einen Launch-Termin erreichen. Der Unterschied zeigt sich im zweiten Jahr: Das eine Produkt verarbeitet ein Plattform-Upgrade und eine größere neue Funktion ohne größere Probleme, während beim anderen plötzlich über eine vollständige Neuentwicklung gesprochen werden muss, für die niemand Budget eingeplant hat.

Erfahren Sie, wie eine patientenorientierte Plattform auf realen operativen Workflows aufgebaut wurde. Lesen Sie die Case Study zur Intake- und CRM-Plattform

Nach dem Launch zeigt sich, ob die gewählte Reihenfolge tatsächlich funktioniert. Performance-Arbeiten an einem Live-Produkt werden schließlich durch Entscheidungen begrenzt, die lange vor der ersten Messung getroffen wurden.

Erfahren Sie, wie Performance-Verantwortung nach dem Launch aussieht. Lesen Sie die Case Study zur Plattform-Performance

Fazit

Der erfolgreiche Einkauf von Mobile-App-Entwicklungsservices hängt weniger von der Auswahl des Anbieters ab als von der Reihenfolge, in der die beiden grundlegenden Entscheidungen getroffen werden. Werden die Produktanforderungen vor der Einholung von Angeboten definiert, verschwindet ein Großteil der Preisspanne, die einen Vergleich sonst unmöglich macht, weil alle Anbieter dieselbe Leistung kalkulieren statt ihre eigenen Annahmen. Die Plattformwahl ergibt sich aus Hardware-Abhängigkeit, Interface-Erwartungen, Release-Frequenz und dem Wartungsmodell, das das Unternehmen langfristig tragen kann. Keiner dieser Faktoren ist eine reine technische Präferenz. Die Partnerbewertung konzentriert sich anschließend auf architektonische Disziplin, Testing-Ansatz und nachgewiesene Release-Verantwortung. Diese Aspekte müssen aktiv hinterfragt werden, da sie in einem Portfolio nicht sichtbar sind. Wird diese Reihenfolge umgekehrt, entstehen scheinbar vergleichbare Angebote für tatsächlich unterschiedliche Leistungen und eine Framework-Entscheidung, die im zweiten Jahr als kostspielige Neuentwicklung wieder auftaucht.

Häufig gestellte Fragen

F1. Wie entscheidet man zwischen nativer und Cross-Platform-Mobile-Entwicklung?

A1. Vier Produkteigenschaften entscheiden darüber: wie intensiv die App Hardware und Sensoren nutzt, ob sie mit führenden nativen Anwendungen ihrer Kategorie konkurriert, wie häufig Releases auf beiden Plattformen erfolgen und ob das Unternehmen langfristig zwei unterschiedliche Kompetenzprofile aufrechterhalten kann. Teampräferenzen sollten diese Entscheidung nicht bestimmen.

F2. Warum unterscheiden sich Angebote für dieselbe Mobile-App so stark?

A2. Vier Variablen erklären den Großteil der Unterschiede zwischen konkurrierenden Angeboten. Anbieter interpretieren den beschriebenen Umfang unterschiedlich, setzen unterschiedliche Qualitätsstandards für automatisierte Tests und Barrierefreiheit voraus, treffen unterschiedliche Annahmen darüber, ob Backend-APIs bereits vorhanden sind, und übernehmen nach der ersten Store-Freigabe sehr unterschiedlich viel Verantwortung.

F3. Was sollte man einen Mobile-Development-Partner vor Vertragsabschluss fragen?

A3. Fragen Sie nach einer Architekturentscheidung, die der Anbieter später bereut hat, danach, was einen Release konkret stoppen kann, und wie eine Regression tatsächlich bis in die Produktion gelangt. Fragen Sie außerdem, welche Store-Ablehnungskategorien wiederholt auftreten. Anschließend sollten Sie einen früheren Kunden fragen, was passiert ist, als während der Zusammenarbeit etwas schiefging.

F4. Was kostet die Entwicklung einer Mobile-App mittlerer Komplexität?

A4. Sigmas veröffentlichte Schätzung liegt für eine Anwendung mittlerer Komplexität bei einem mittelgroßen Unternehmen zwischen 40.000 und 100.000 US-Dollar. Der genaue Betrag hängt von Zielplattform, Funktionsumfang und Delivery-Modell ab. Angebote deutlich außerhalb dieses Bereichs beschreiben in der Regel einen wesentlich anderen Leistungsumfang und nicht lediglich einen anderen Preis.

F5. In welcher Reihenfolge sollte die Entwicklung einer Mobile-App tatsächlich erfolgen?

A5. Entscheidungen, die später nur mit hohem Aufwand rückgängig gemacht werden können, müssen vor leicht reversiblen Entscheidungen getroffen werden. Zuerst kommen Anforderungsdefinition und Plattformwahl, danach Backend- und Integrationsarchitektur, anschließend Release Engineering und der Store-Submission-Prozess und erst danach die Feature-Entwicklung. Wird diese Reihenfolge vertauscht, entsteht unter Termindruck zuverlässig zusätzliche Nacharbeit.