Was gehört in ein belastbares Budget für eine mobile App?

Erst einen nutzbaren Ablauf kalkulieren

Ein hypothetischer Außendienstpilot: Eine Mitarbeiterin meldet sich an, öffnet zugewiesene Aufträge, füllt offline ein Formular aus und überträgt es bei erneuter Verbindung. Eine kleine Webadministration ermöglicht die Prüfung. Das Beispiel umfasst iOS und Android, einen bestehenden Identitätsdienst, eine Backend-Anbindung und vereinbarte Barrierefreiheitstests. Zahlungen, Tourenoptimierung, neue Hardware und regulierte klinische Entscheidungen sind ausgeschlossen. Dies ist eine Kalkulationsübung, kein Kundenprojekt.

Fünf Ansichten können komplexe Berechtigungen, Datenkonflikte und unzuverlässige Fremdsysteme verbergen. Schreiben Sie zuerst Abnahmebeispiele: Niemand sieht Aufträge eines anderen Teams; ein ungesendetes Formular bleibt nach dem Neustart erhalten; eine Wiederholung erzeugt keinen zweiten Datensatz. Jeder Anbieter sollte diese Leistungen ausdrücklich zuordnen. Androids Architekturhinweise für Offline-Nutzung verdeutlichen, warum Verbindungsprobleme die Datenschicht betreffen und nicht erst nach dem UI gelöst werden.

Ein offengelegtes EUR-Beispiel

Die Annahme lautet: 44 Personentage zu je EUR 900 ergeben EUR 39.600. Eine beispielhafte Lieferreserve von 20% beträgt EUR 7.920. Das anfängliche Entwicklungsbudget liegt damit bei EUR 47.520. Tagessatz und Reserve sind Annahmen, keine Wavect-Preise oder Marktdurchschnitte. Die Tabelle zeigt die Verteilung der 44 Tage. Personentage sind Aufwand, keine kalendarische Laufzeit; parallele Arbeit, Kundenentscheidungen und Store-Prüfung beeinflussen den Termin.

Für zwölf Betriebsmonate setzen wir EUR 300 monatlich für Hosting und Werkzeuge an (EUR 3.600) sowie zwei Wartungstage pro Monat zum selben angenommenen Satz (EUR 21.600). Zusammen ergeben Entwicklung und diese Betriebsannahmen EUR 72.720 ohne Umsatzsteuer. Store-Programme, weitere kostenpflichtige Dienste, Transaktionsgebühren, Inhaltsproduktion und neue Funktionen sind nicht enthalten. Die Reserve deckt Lieferunsicherheit ab, nicht nochmals Wartung. Annahmen und Rechenweg herunterladen und durch eigene Angebotswerte ersetzen.

Was verändert den Aufwand?

Offline-Schreibzugriffe brauchen Regeln für lokale Speicherung, abgelaufene Anmeldung, Wiederholungen und konkurrierende Änderungen. Ein Lesecache ist ein anderer Umfang als das verbindliche Einreichen eines Datensatzes. Bluetooth-Zubehör, Hintergrundaktivitäten, Kamera und spezielle Gerätefunktionen müssen auf Zielgeräten erprobt werden, bevor breite Kompatibilität zugesagt wird.

Ein gemeinsames Framework liefert nicht automatisch zwei fertige Apps zum Preis einer. React Native dokumentiert plattformspezifischen Code; Flutter beschreibt seine Plattformanbindungen. Fragen Sie, welche Teile nativ bleiben, wer Abhängigkeiten wartet und wer ein Release reproduzieren kann. Der Vergleich React Native und Flutter behandelt die Stackwahl. Hier geht es um vollständige Budgetpositionen.

Das Release testen, nicht nur die Demo

Vereinbaren Sie echte Geräte, OS-Versionen, Screenreader-Abläufe, langsame Verbindungen, unterbrochene Uploads und abgelaufene Sitzungen. Prüfen Sie signierte Release-Builds zusätzlich zu Entwicklungsständen. Dazu gehören verweigerte Berechtigungen, Wechsel in den Hintergrund und gegebenenfalls Kontolöschung. Priorisieren Sie Fehler nach Nutzerwirkung und legen Sie Startblocker vorher fest. Eine grüne automatisierte Testsuite belegt nicht jedes Geräteverhalten.

Bestimmen Sie Verantwortliche für Entwicklerkonten, Zertifikate, Signaturschlüssel, Datenschutzauskünfte und Release-Notizen. Apples Review-Richtlinien sind eine Primärquelle für Anforderungen an Einreichungen. Fertigstellung der Entwicklung garantiert keine Store-Freigabe. Klären Sie den Aufwand für Rückfragen und unterscheiden Sie Lieferfehler von späteren Produkt- oder Richtlinienänderungen.

Angebote auf gleicher Grundlage vergleichen

Verlangen Sie eine Umfangstabelle: enthaltene Abläufe, ausgeschlossene Funktionen, Zielgeräte, Abhängigkeiten, Testnachweise, Kundenzuarbeit und Betreuung nach dem Release. Benennen Sie für jede Unklarheit einen Versuch und einen Entscheidungstermin. Eine unbekannte Schnittstelle gehört nicht hinter einen pauschalen Reserveprozentsatz. Ein kleiner Integrationstest kann wertvoller sein als ein weiterer ausgearbeiteter Bildschirm.

Planen Sie nach dem Start OS- und Abhängigkeitsupdates, Überwachung, Störungsbearbeitung, Wiederherstellung und wiederholbare Releases. Neue Funktionen sind von der Wartung der abgenommenen Version zu trennen. Repository-Zugriff, Konten, Build-Anleitung, Datenexport und Zuständigkeit für offene Störungen müssen auch bei Vertragsende klar sein. Mobile App-Entwicklung verantwortet die Umsetzung; Software Discovery klärt den Umfang vor der Beauftragung.