App-Entwickler beauftragen: 15 Fragen, bevor Sie unterschreiben

Bevor Sie einen App-Entwickler oder eine App-Agentur beauftragen, klären Sie, wer die App tatsächlich baut, wem Code und Store-Konten gehören, wie Releases in den App Store und zu Google Play gelangen, wie Daten geschützt werden und was nach dem Launch passiert. Ein Portfolio zeigt, was ein Team gebaut hat. Diese Fragen zeigen, wie es Ihre App bauen wird.

Die folgende Checkliste richtet sich an Gründerinnen, Gründer und Product Owner, die Angebote vergleichen. Sie spiegelt die Fragen wider, die bei echten Releases und Übergaben zählen, einschließlich der öffentlichen Fallstudie von ImadDhin und der wiederkehrenden Store-Probleme, die an anderer Stelle in diesem Blog behandelt werden. Sie ist kein Anbieter-Ranking.

Warum die Wahl des richtigen App-Partners schwierig ist

Die meisten Angebote sehen auf der Ebene, auf der Auftraggeber üblicherweise vergleichen, ähnlich aus: eine Liste von Screens, ein Technologie-Stack, ein Zeitplan und ein Preis. Die Unterschiede, die über Erfolg oder Misserfolg entscheiden, sind weniger sichtbar. Wer hält die Entwicklerkonten bei Apple und Google? Ist das Backend so dokumentiert, dass ein anderes Team es betreiben könnte? Hat der Anbieter schon oft den Store-Review durchlaufen, oder hat er meist Builds geliefert, die jemand anderes veröffentlichen musste?

Mobile Apps bringen Einschränkungen mit, die Webprojekte nicht haben. Jedes Release durchläuft einen Store-Review. Alte App-Versionen bleiben monatelang auf den Geräten der Nutzer, also muss das Backend sie weiter unterstützen. Push-Benachrichtigungen, In-App-Käufe, Standortzugriff im Hintergrund und Kamerazugriff unterliegen jeweils Plattformregeln. Ein Anbieter, der das als Details behandelt, entdeckt sie spät, und zwar auf Ihre Kosten.

Was Auftraggeber häufig falsch machen

• Stundensätze vergleichen statt der Gesamtkosten bis zu einem funktionierenden Release, einschließlich Store-Einreichung, Backend und Korrekturen nach dem Review.
• Den Anbieter Entwicklerkonten, Cloud-Projekte und Domains in seiner eigenen Organisation anlegen lassen.
• Eine Demo auf dem Smartphone des Anbieters als Liefernachweis akzeptieren statt eines Builds, der in Ihrem eigenen Store-Eintrag veröffentlicht ist.
• Die Frage nach der Zeit nach dem Launch überspringen, wenn Absturzberichte, Betriebssystem-Updates und Review-Ablehnungen eintreffen.
• Einen Stack wählen, weil er gerade angesagt ist, und nicht, weil er zu dem Team passt, das die App pflegen wird.

So nutzen Sie die 15 Fragen

Stellen Sie sie in einem Gespräch oder schicken Sie sie schriftlich. Gute Anbieter antworten konkret und ohne sich zu rechtfertigen. Vage Antworten sind ebenfalls eine Information.

Fragen 1 bis 4: Team und Eigentum

1. Wer baut die App tatsächlich?

Fragen Sie nach Namen und Rollen der Personen, die die Arbeit machen, nicht nach dem Vertriebsteam. Fragen Sie, ob Teile an Subunternehmer vergeben werden und an wen. Ein inhabergeführtes Studio, eine Agentur und ein Freelancer von einer Plattform können alle gute Arbeit leisten, aber Sie sollten wissen, wen Sie beauftragen.

2. Wem gehört der Code, und wo liegt er?

Das Repository sollte in einer Organisation liegen, die Ihnen gehört, oder nach einem festgelegten Zeitplan an Sie übertragen werden. Stellen Sie sicher, dass Sie den vollständigen Quellcode, die Build-Konfiguration und die Infrastrukturdefinitionen erhalten, nicht nur kompilierte Builds.

3. Wessen Entwickler- und Cloud-Konten werden verwendet?

Apple Developer, Google Play Console, Firebase- oder andere Cloud-Projekte, Domains und Zahlungskonten sollten Ihrem Unternehmen gehören, und der Anbieter wird als Teammitglied eingeladen. Eine App später zwischen Store-Konten zu verschieben ist möglich, aber langwierig und störend.

4. Was passiert, wenn wir uns mitten im Projekt trennen?

Fragen Sie, wie eine Übergabe zu jedem Zeitpunkt funktioniert: Code, Zugangsdaten, Dokumentation und eine kurze Einweisung. Die Antwort zeigt, ob der Anbieter für Sie baut oder auf Abhängigkeit setzt.

Fragen 5 bis 9: Produkt und Architektur

5. Warum dieser Stack für diese App?

Native Entwicklung, Flutter, React Native und Low-Code-Tools wie FlutterFlow haben alle ihre Berechtigung. Die richtige Antwort bezieht sich auf Ihre Anforderungen: Plattformfunktionen, Offline-Bedarf, Fähigkeiten des Teams, Time-to-Market und wer die App später pflegt. Die falsche Antwort lautet, dass der Anbieter das immer so macht.

6. Wie sieht das Backend aus, und wer betreibt es?

Fragen Sie, wo Daten gespeichert werden, wie die Authentifizierung funktioniert, wie Serverlogik ausgerollt wird und wie das Backend überwacht wird. Fragen Sie, ob dasselbe Backend später auch eine Web-App bedienen soll, denn das beeinflusst, wie Konten und Berechtigungen gestaltet werden.

7. Wie werden Daten geschützt?

Fragen Sie, wie Zugriffsregeln auf dem Server oder in der Datenbank durchgesetzt werden, nicht nur in der App. Fragen Sie, wo Secrets liegen, denn alles, was in eine mobile App gebündelt wird, lässt sich extrahieren. Fragen Sie, wie personenbezogene Daten verarbeitet werden und ob die Anforderungen der DSGVO sowie etwaige Vorgaben in Ihren Zielmärkten berücksichtigt wurden, bei Bedarf mit rechtlicher Prüfung. Auch Fragen wie Auftragsverarbeitung und Serverstandort gehören in dieses Gespräch.

8. Wie gehen Sie mit alten App-Versionen um?

Nicht alle Nutzer aktualisieren. Fragen Sie, wie das Backend mit älteren Versionen kompatibel bleibt und ob es einen Mechanismus gibt, ein Update zu erzwingen, wenn eine inkompatible Änderung unvermeidbar ist.

9. Was passiert bei schlechtem Netz?

Fragen Sie, welche Screens offline oder bei schwacher Verbindung funktionieren, wie Schreibvorgänge wiederholt werden und was Nutzer sehen, wenn etwas fehlschlägt. Diese eine Frage trennt Teams, die echte Nutzer betreut haben, von Teams, die nur im Büro-WLAN vorgeführt haben.

Fragen 10 bis 12: Release und Betrieb

10. Wer reicht die App im App Store und bei Google Play ein?

Fragen Sie, wer Store-Einträge, Screenshots, Datenschutzangaben und Review-Hinweise vorbereitet und wer auf Ablehnungen reagiert. Fragen Sie, wie oft das Team bereits eine App durch den Review gebracht hat und worum es bei der letzten Ablehnung ging.

11. Wie werden Builds erstellt und signiert?

Fragen Sie, ob Builds aus einer reproduzierbaren Pipeline stammen oder vom Laptop eines einzelnen Entwicklers. Signaturschlüssel und Store-API-Zugangsdaten sollten sicher, unter Ihrer Kontrolle und dokumentiert aufbewahrt werden.

12. Welches Monitoring ist zum Launch vorhanden?

Absturzberichte, grundlegende Analysen und Fehlerprotokollierung im Backend sollten Teil des ersten Releases sein. Ohne sie ist das erste Anzeichen eines Problems eine Ein-Stern-Bewertung.

Fragen 13 bis 15: kaufmännische Bedingungen

13. Was genau ist im Preis enthalten?

Klären Sie, ob Store-Einreichung, Backend-Arbeit, Design, Tests auf echten Geräten und Korrekturen nach dem ersten Review enthalten sind. Fragen Sie, wie Änderungen gehandhabt und berechnet werden.

14. Wie sieht der Support nach dem Launch aus?

Fragen Sie nach einer Gewährleistungsphase für Fehler, nach Reaktionszeiten und den Kosten laufender Wartung wie Betriebssystem-Updates und Abhängigkeits-Upgrades. Mobile Apps brauchen regelmäßige Pflege, auch wenn sich keine Funktion ändert.

15. Welche laufenden Kosten entstehen?

Lassen Sie sich die wiederkehrenden Kosten und ihre Treiber auflisten: Gebühren für Entwicklerprogramme, Backend-Hosting, Datenbanknutzung, Push-Benachrichtigungen, E-Mail, gegebenenfalls KI-Modellaufrufe und Monitoring-Tools. Diese Kosten tragen Sie, also sollten Sie sie vor der Unterschrift kennen.

Hinweise zur Umsetzung

Lassen Sie sich die Antworten schriftlich geben und übernehmen Sie die wichtigsten in den Vertrag: Kontoeigentum, Code-Übertragung, enthaltener Umfang und Support-Bedingungen. Eine freundliche Antwort im Gespräch ist nicht durchsetzbar.

Wenn Sie die technischen Antworten nicht selbst beurteilen können, stellen Sie jedem Anbieter dieselben Fragen und vergleichen Sie, wie konkret die Antworten sind. Konkretheit ist ein brauchbarer Indikator für Erfahrung. Sie können auch eine kurze, bezahlte Discovery-Phase vereinbaren, bevor Sie sich auf die komplette Umsetzung festlegen.

Planen Sie die Store-Konten früh. Die Registrierung als Organisation bei Apple und Google erfordert eine Unternehmensverifizierung, die Zeit kosten kann, und es ist viel einfacher, mit den richtigen Konten zu starten, als später zu migrieren.

Abwägungen

Eine größere Agentur bietet mehr Kapazität und Kontinuität, wenn Personen ausscheiden, allerdings mit mehr Ebenen zwischen Ihnen und den Menschen, die den Code schreiben. Ein kleineres oder inhabergeführtes Studio bedeutet meist direkten Zugang zu der Person, die Entscheidungen trifft, bei weniger freier Kapazität. Ein einzelner App-Entwickler als Freelancer kann bei klar umrissenen Aufgaben hervorragend sein, trägt aber ein höheres Risiko, wenn diese eine Person ausfällt.

Cross-Platform-Frameworks senken die Kosten, beide Plattformen zu unterstützen, während native Entwicklung die bessere Wahl sein kann, wenn eine App stark auf plattformspezifische Funktionen setzt. Low-Code-Tools können den Weg zur ersten Version verkürzen, vorausgesetzt, das Team weiß, wann eigener Code oder ein Export nötig wird.

Erkenntnisse aus der Arbeit von ImadDhin

Die öffentliche FoCoCo-Fallstudie umfasst eine Flutter-App für das Smartphone, eine Next.js-Web-App, ein Firebase-Backend, Sprachfunktionen in Echtzeit und Mitgliedschaften. Als Beobachtung auf Implementierungsebene: Die wichtigsten Fragen betrafen nicht die Screens. Sie betrafen eine einheitliche Identität über Smartphone-App und Web-App hinweg, damit ein auf einer Plattform angelegtes Konto samt Mitgliedschaft auch auf der anderen funktioniert, sowie Store-Release und Backend-Regeln, die stimmen mussten, bevor sich das Produkt fertig anfühlte.

Der Beitrag zu FlutterFlow und dem App Store in diesem Blog dokumentiert ein Muster, das die Fragen 3, 10 und 11 aufdecken sollen: eine App, die optisch fertig ist, aber TestFlight nicht erreicht, wegen Bundle-Identifiern, Berechtigungen von Store-API-Schlüsseln oder fehlender Datenschutztexte. Solche Probleme gehören zum Release-Engineering und damit ins Gespräch mit dem Anbieter, bevor Sie unterschreiben.

Häufige Fehler, die Sie testen sollten

• Lassen Sie sich einen Store-Eintrag zeigen, den der Anbieter veröffentlicht hat, und prüfen Sie, unter wessen Konto er liegt.
• Bitten Sie den Anbieter, eine frühere Review-Ablehnung zu erklären und wie sie gelöst wurde.
• Prüfen Sie, ob das Angebot laufende Kosten getrennt vom Entwicklungspreis ausweist.
• Lassen Sie sich schriftlich bestätigen, dass Entwicklerkonten und Cloud-Projekte in Ihrer Organisation angelegt werden.
• Fragen Sie nach einem Beispiel für Übergabedokumentation aus einem früheren Projekt, ohne Kundendaten.

Wann eine einfachere Option besser ist

Wenn Sie noch testen, ob Menschen Ihr Produkt überhaupt wollen, brauchen Sie womöglich noch keine mobile App. Eine responsive Web-App oder ein klickbarer Prototyp kann die Nachfrage mit einem Bruchteil des Aufwands validieren, und der Store-Review steht Ihnen nicht im Weg, wenn Sie täglich etwas ändern wollen.

Wenn Sie ein kleines internes Tool für eine bekannte Nutzergruppe brauchen, kann ein Low-Code- oder webbasierter Ansatz genügen. Beauftragen Sie einen App-Entwickler, wenn Sie Store-Präsenz, Gerätefunktionen oder ein Erlebnis brauchen, das wirklich davon profitiert, nativ zu sein.

Sprechen Sie mit den Menschen, die die App bauen würden

Nehmen Sie diese Fragen in jedes Anbietergespräch mit, auch in unseres. Wenn Ihr Projekt auf FlutterFlow basiert, sehen Sie sich an, wie ImadDhin FlutterFlow-Projekte umsetzt und rettet; für einen breiteren Umfang lesen Sie mehr über unsere Projektformate oder senden Sie ein Projekt-Briefing. Der schnellste nächste Schritt ist ein 30-minütiges Gespräch, in dem Sie alle 15 Fragen direkt stellen können.