Schritt für Schritt: wann ein Unternehmen eine mobile App braucht

Unternehmen verlieren Kunden, weil ihnen ein mobiler Kanal fehlt. Und meistens merken sie nicht einmal, wann das anfängt. Es gibt keinen Alarm – die Conversion sinkt einfach, Warenkörbe bleiben liegen, und Außendienstler rufen aus dem Feld an, weil sie den Lagerbestand nicht prüfen können. Seit 2006 helfen wir bei Web Systems Unternehmern dabei, einen echten Bedarf von der kurzlebigen Mode einer “App” zu unterscheiden. In diesem Artikel gehen wir die konkreten Signale durch, die sagen “Zeit für eine App”, zeigen die Unterschiede zwischen den Technologien und erklären, wie Sie Ihr Budget bei der ersten Umsetzung nicht verbrennen. Es geht außerdem um Integrationen, Sicherheit und darum, was passiert, nachdem die App in den Stores gelandet ist. Denn dort fängt der Spaß erst an.

Geschäftliche Signale – woran Sie erkennen, dass es Zeit für eine mobile App ist

Der einfachste Test? Öffnen Sie Google Analytics. Wenn mehr als 60% des Traffics von Smartphones kommt und die Bounce Rate auf Mobilgeräten deutlich höher ist als auf dem Desktop, kommt eine responsive Website nicht mehr mit. Nutzer wollen Tempo, flüssige Bedienung und Steuerung mit einem Finger. Und ein mobiler Browser hat seine Grenzen. Push-Benachrichtigungen, Kamera, GPS, Offline-Modus – daran kommen Sie ohne eine dedizierte Anwendung nicht vorbei.

Das zweite Signal kommt aus dem Unternehmen selbst. Servicetechniker, Außendienstler, Fahrer, Lagermitarbeiter – diese Leute arbeiten außerhalb des Büros. Und was machen sie? Sie schicken Bestellungen per Mail, tippen Daten von Hand ab, rufen für jede Information in der Zentrale an. Das erzeugt Fehler und Verzögerungen. Ich habe das Dutzende Male gesehen. Eine mobile App, die an ein ERP oder CRM angebunden ist, kann die Reaktionszeit halbieren. Ganz ohne Übertreibung.

Und dann ist da noch der Wettbewerbsdruck. Wenn Firmen aus Ihrer Branche ihren Kunden bequeme Apps zum Bestellen, für die Paketverfolgung oder für Terminbuchungen geben, verlieren Sie ohne eine solche Lösung schlicht. Kunden vergleichen Erlebnisse. Und sie entscheiden sich für Bequemlichkeit.

1. Der mobile Traffic auf der Website liegt über 60%, und die Conversion auf Smartphones ist halb so hoch wie auf dem Desktop
2. Außendienstmitarbeiter verlieren Zeit durch manuelle Berichte und fehlenden Zugriff auf Daten in Echtzeit
3. Wettbewerber haben eigene Apps gestartet und ziehen Nutzer ab
4. Kunden wünschen sich Benachrichtigungen, ein Treueprogramm oder eine schnelle Möglichkeit für wiederkehrende Bestellungen
5. Die responsive Website deckt zentrale Szenarien nicht ab – etwa das Scannen von Codes, digitale Signaturen oder Offline-Arbeit
6. Die Kundenbindung sinkt, obwohl das Angebot weiterhin konkurrenzfähig ist

Tipp #1: Bevor Sie sich in den Bau einer App stürzen, schauen Sie in Google Analytics oder Matomo. Aber achten Sie nicht nur auf den Mobilanteil. Prüfen Sie die Conversion-Pfade auf dem Smartphone. Wenn Nutzer an einem bestimmten Schritt abspringen – beim Formular, bei der Zahlung -, ist das ein Signal, dass sie eine bessere Oberfläche brauchen. Aber nicht unbedingt gleich eine vollwertige native App. Manchmal reicht eine bessere mobile Version der Website.

PWA, Hybrid oder Native – welchen Weg wählen und warum das nicht offensichtlich ist

Hier fängt es an, schwierig zu werden. Die Wahl der Technologie ist eine Entscheidung, die dem Projekt jahrelang nachhängt. Eine Progressive Web App läuft im Browser, lässt sich auf dem Startbildschirm installieren, unterstützt Push und einen einfachen Offline-Betrieb. Der Hauptvorteil? Niedrige Einstiegskosten und keine Veröffentlichung in den Stores. Sie bewährt sich bei Produktkatalogen, Buchungssystemen und einfachen internen Werkzeugen – überall dort, wo Sie nicht tief in die Hardware des Telefons greifen müssen.

Hybride Lösungen – React Native oder Flutter – erlauben eine einzige Codebasis für Android und iOS zugleich. Sie haben Zugriff auf native Gerätefunktionen und zahlen deutlich weniger als für doppelte Entwicklung. Ehrlich? Bei Web Systems setzen wir diesen Ansatz am häufigsten ein, besonders bei ersten Produktversionen, bei denen Time-to-Market zählt. Ein Hybrid genügt für die meisten geschäftlichen Szenarien – E-Commerce, Logistik, Serviceanwendungen.

„Die App-Architektur ist das Fundament hochwertiger Android-Software. Eine gut definierte Architektur erlaubt es, skalierbare und wartbare Lösungen zu bauen, die sich an ein ständig wachsendes Geräte-Ökosystem anpassen – von Smartphones über Tablets und faltbare Geräte bis zu Displays im Auto.”

Native Apps in Kotlin (Android) und Swift (iOS) sind die Oberklasse. Höchste Performance, voller Zugriff auf die Plattform. Aber. Sie bauen faktisch zwei getrennte Produkte, das Budget steigt also fast auf das Doppelte. Wann ergibt das Sinn? Spiele, aufwendige Grafik, Augmented Reality, Anwendungen, die aus dem Akku jede Minute herausholen müssen. Für die meisten B2B- und E-Commerce-Projekte ist das zum Start überdimensioniert.

Tipp #2: Starten Sie mit einem MVP in einer hybriden Technologie – Flutter oder React Native. Sie prüfen die Idee in 3-4 Monaten am Markt, sammeln Feedback und entscheiden erst auf Basis harter Daten, ob Sie zu Native wechseln. Ich habe zu viele Projekte gesehen, in denen jemand Swift gewählt hat, weil er einen Artikel auf Medium gelesen hatte. Machen Sie das nicht. Analysieren Sie Ihre eigenen Anforderungen.

Von der Idee zum MVP – wie Sie die erste Version planen, ohne Budget zu verbrennen

Der teuerste Fehler, den ich bei Kunden sehe? Der Versuch, im ersten Anlauf ein komplettes Produkt zu bauen. Zwanzig Screens, drei Nutzerrollen, Integration mit fünf Systemen, ein Administrationspanel. Das ist kein MVP. Das ist ein vollwertiges System, dessen Entwicklung sich ein Jahr hinzieht und jedes Budget sprengt. Ein Minimum Viable Product löst ein Problem einer Nutzergruppe. Der Rest wandert in die Roadmap. Punkt.

Die Discovery- und Prototyping-Phase ist die Etappe, die alle überspringen wollen und danach bereuen. Dabei entstehen Nutzer-Personas, eine Flow-Map, Wireframes der Screens und eine technische Spezifikation. Bei uns dauert diese Phase 2-4 Wochen und kostet einen Bruchteil des Gesamtprojekts. Sie erlaubt es aber, Missverständnisse aufzufangen, bevor sie sich in teure Korrekturen im Code verwandeln. Ein klickbarer Prototyp gibt die Möglichkeit, das Konzept mit echten Nutzern zu testen, bevor die erste Zeile geschrieben ist.

„Vertiefte Branchenforschung, die Analyse bewährter Praktiken, Trendmodellierung und ein quantitativer Ansatz ermöglichen es, innovative Strategien zu entwickeln, die sich in stärkeren und nachhaltigeren Geschäftsergebnissen niederschlagen.”

Und was kostet das? Realistische Spannen für eine einfache mobile App: ab 40.000-60.000 Zloty für ein MVP als Hybrid. Ein umfangreiches Produkt mit vielen Integrationen? 200.000-500.000 Zloty und mehr. Das hängt von der Zahl der Screens, der Komplexität der Geschäftslogik, den Integrationen, dem Sicherheitsniveau und davon ab, ob Sie ein Backend von Grund auf aufbauen oder sich an eine bestehende API anbinden. Ohne detaillierte Spezifikation ist keine Schätzung belastbar – und genau deshalb ist die Discovery-Phase nicht optional.

Tipp #3: Wählen Sie 3-5 Funktionen für die erste Version. Den Rest legen Sie beiseite. Nutzen Sie eine einfache Matrix: Bewerten Sie jede Funktion nach Nutzen für den Anwender und nach Umsetzungsaufwand. Hoher Nutzen, geringer Aufwand? Kommt ins MVP. Der Rest wartet auf die nächsten Iterationen, die Sie auf Daten aus der tatsächlichen Nutzung stützen und nicht auf Vermutungen.

Integrationen, Daten und Sicherheit – die technischen Grundlagen, an die Kunden selten denken

Keine mobile App arbeitet im luftleeren Raum. Sie verbindet sich mit dem ERP für Lagerbestände, zieht Kundendaten aus dem CRM, spricht mit Zahlungs-Gateways, verschickt Benachrichtigungen über externe Dienste, synchronisiert sich mit dem Adminpanel. Und jede solche Integration ist ein eigenes Projekt – die API-Schicht, Fehlerbehandlung, ein Retry-Mechanismus, eine Caching-Strategie. Keine Planung der Integrationen zu Beginn? Das ist eine der häufigsten Ursachen für Budgetüberschreitungen. Die Architektur im laufenden Betrieb umzubauen kostet ein Vielfaches dessen, was ein durchdachter Entwurf am Anfang kostet.

Sicherheit im mobilen Bereich ist eine Geschichte für sich. Ein Telefon kann verloren gehen, gestohlen werden, sich mit einem zweifelhaften WLAN im Café verbinden. Verschlüsselung der Daten (im Ruhezustand und bei der Übertragung), mehrstufige Autorisierung, sichere Speicherung von Tokens, Konformität mit der DSGVO – das ist das absolute Minimum. Bei medizinischen oder finanziellen Daten kommen Branchenvorschriften hinzu. Bei Web Systems durchläuft jedes mobile Projekt vor der Veröffentlichung ein Sicherheitsaudit. Ohne Ausnahmen.

Die Datenarchitektur sollte sich an das Prinzip einer einzigen Wahrheitsquelle halten. Jeder Datentyp hat einen Ort, an dem er verändert wird, alle übrigen Komponenten lesen ihn nur. Ein gerichteter Datenfluss, von der Quelle über die Geschäftslogik bis zur Oberfläche, reduziert Synchronisationsfehler und erleichtert das Debugging. Ich habe beide Ansätze getestet und weiß, dass das sowohl in einfachen Katalog-Apps als auch in komplexen Systemen mit Offline-Modus funktioniert.

Und damit kommen wir zu Offline-First. Eine App, die ohne Netz ausfällt, ist für den Außendienstler im Feld, den Techniker im Keller oder den Fahrer im Funkloch nutzlos. Eine lokale Datenbank, das Einreihen von Vorgängen in eine Warteschlange, eine intelligente Synchronisation nach der Rückkehr der Verbindung – das muss vom ersten Tag an geplant werden. Man kann das später nicht einfach “nachwerfen”, ohne die halbe Anwendung umzubauen. Wirklich, das geht nicht.

Veröffentlichung, Wartung und Weiterentwicklung – was nach der Umsetzung passiert

Eine App in Google Play und den App Store zu bringen ist kein Klick-und-fertig. Google verlangt ein Entwicklerkonto, eine mit einem Zertifikat signierte Anwendung und das Bestehen einer automatischen Prüfung. Apple? Oh, Apple ist eine andere Liga. Das Review kann sich von einigen Tagen bis zu zwei Wochen hinziehen. Ablehnung wegen kleiner Abweichungen von den Human Interface Guidelines? Kommt regelmäßig vor. Planen Sie einen Zeitpuffer ein, besonders bei der ersten Veröffentlichung. Dazu kommen Beschreibungen, Screenshots, Datenschutzerklärung und Grafiken für beide Stores – allein das verschlingt einige Arbeitstage.

Und jetzt das Spannendste: die Wartung. Diese Phase unterschätzen Kunden fast immer. Android und iOS bringen jedes Jahr neue Versionen heraus, Sicherheitspatches jeden Monat. Jede Änderung an einer System-API kann in Ihrer App etwas kaputt machen. Dazu Korrekturen, die Nutzer melden, Crash-Monitoring (Firebase Crashlytics ist ein Must-have), Performance-Analyse, Akku-Optimierung. Lassen Sie das schleifen, und die Bewertungen im Store fallen. Niedrige Bewertung = weniger Downloads = schlechtere Sichtbarkeit. Eine Abwärtsspirale.

Die Weiterentwicklung nach der Umsetzung sollte auf Daten beruhen. Verhaltensanalysen (Navigationspfade, Verweildauer auf Screens, wo Menschen abspringen), Umfragen in der App, die Auswertung von Support-Tickets – das entscheidet über die Prioritäten der Roadmap. Neue Funktionen iterativ in zwei- oder vierwöchigen Sprints auszurollen erlaubt es, auf den Markt zu reagieren, ohne das zu zerstören, was bereits funktioniert.

Was kostet die Wartung? Realistisch 15-25% des jährlichen Entwicklungsbudgets. Für eine einfache App sind das 2.000-5.000 Zloty im Monat. Ein umfangreiches System mit Integrationen? 10.000-20.000 Zloty. In diesem Betrag stecken Hosting des Backends, Monitoring, Aktualisierung von Abhängigkeiten, Anpassung an neue Systemversionen und laufende Korrekturen. Berücksichtigen Sie das im Businessplan von Anfang an. Das ist ein fester Betriebskostenposten, genau wie die Wartung der übrigen IT-Infrastruktur.

FAQ

Was kostet die Entwicklung einer mobilen App für ein mittelständisches Unternehmen?

Das hängt vom Umfang, der Technologie und der Zahl der Integrationen ab. Ein einfaches MVP als Hybrid (Flutter, React Native) mit 5-8 Screens und einem Basis-Backend kostet 40.000-80.000 Zloty. Eine umfangreiche App mit Adminpanel, Integrationen mit ERP und CRM, Offline-Modus und fortgeschrittener Autorisierung? 150.000-500.000 Zloty. Deshalb ist die Discovery-Phase so wichtig: Sie erlaubt es, das Budget abzuschätzen, bevor Sie mit dem Ausgeben beginnen. Und denken Sie an die Wartungskosten, also etwa 15-25% des Projektwerts pro Jahr. Daran denken viele nicht.

Sollte man besser mit einer mobilen App oder mit einer responsiven Website beginnen?

In den meisten Fällen mit der Website. Sie ist günstiger, einfacher zu warten und ohne Installation von irgendetwas erreichbar. Aber es kommt der Moment, in dem die Website nicht mehr mitkommt: Sie brauchen Push, Offline, Zugriff auf die Hardware des Telefons, oder Sie wollen über natives UX ein tieferes Engagement aufbauen. Dann ergibt eine App Sinn. Eine PWA ist ein solider Mittelweg, der die Vorteile beider Ansätze bei vernünftigem Budget verbindet. Treffen Sie die Entscheidung aber auf Basis von Daten über das Nutzerverhalten, nicht danach, was der Wettbewerb macht.

Zusammenfassung

Der Bau einer mobilen App sollte sich aus harten Daten und echten geschäftlichen Problemen ergeben. Nicht aus der Überzeugung, dass “jedes Unternehmen eine App haben muss”. Prüfen Sie den mobilen Traffic, analysieren Sie die Prozesse, die Zugriff im Außendienst erfordern, beurteilen Sie, ob der Wettbewerb durch Mobile tatsächlich gewinnt. Erst wenn die Signale eindeutig sind, wählen Sie die Technologie nach den Anforderungen aus, nicht nach Trends.

Der Weg zu einer gelungenen Umsetzung sieht so aus: Prüfung der geschäftlichen Signale anhand der Analytik, bewusste Wahl zwischen PWA, Hybrid und Native, präzise Definition des MVP in der Discovery-Phase, Planung von Integrationen und Sicherheit vom ersten Tag an, Berücksichtigung der Wartungskosten im Budget. Lassen Sie einen dieser Schritte aus, und Sie enden mit Verzögerungen, überschrittenem Budget oder einem Produkt, das niemand nutzen will.

Wenn Sie über den Bau einer mobilen App nachdenken, ein MVP brauchen, bestehende Systeme integrieren oder Ihre aktuelle Lösung modernisieren wollen, dann sprechen wir darüber. Bei Web Systems verbinden wir seit fast zwei Jahrzehnten technisches Wissen mit einem praktischen Zugang zu Projekten und helfen Unternehmen, Technologieentscheidungen zu treffen, die sich tatsächlich auszahlen.