Die Frage “Ergibt eine mobile App für mein Unternehmen Sinn?” erreicht uns meist zu spät. Ein paar Wochen, nachdem jemand einen Vertrag mit einer Kreativagentur unterschrieben, das Grafikkonzept freigegeben und der Geschäftsführung eine Premiere auf der Messe versprochen hat. Wir sind das Team von Web Systems, ein software house aus Łódź, tätig seit 2006. Und wissen Sie was? Wir raten häufiger von der Entwicklung einer nativen mobilen App ab, als wir sie vorschlagen. Klingt seltsam aus dem Mund einer Firma, die mit dem Schreiben von Code ihr Geld verdient, oder? Genau deshalb lohnt es sich, uns zuzuhören. Wir haben kein Interesse daran, von Projekten abzuraten, die wirklich Sinn ergeben.
Das Problem ist nämlich, dass die Entscheidung für eine App oft emotional und nicht analytisch fällt. Jemand hat die App der Konkurrenz gesehen. Jemand hat gelesen, dass “Kunden heute mobil sind”. Und wieder jemand möchte einfach das Firmenlogo als Symbol auf dem Handybildschirm haben. Dabei ist eine mobile App eines der teuersten und wartungsintensivsten digitalen Produkte, die ein Unternehmen überhaupt beauftragen kann. Bevor Sie irgendetwas unterschreiben, prüfen Sie, ob das Projekt nicht schon die Merkmale eines künftigen Scheiterns trägt.
In diesem Artikel zeigen wir fünf konkrete Warnsignale, die wir am häufigsten schon in der Phase der Anforderungsanalyse sehen, also bevor die erste Codezeile geschrieben ist. Jedes davon ist eine rote Flagge. Für sich genommen kippt keines das Projekt, aber ihre Häufung sollte eine Warnlampe aufleuchten lassen und zum Innehalten führen: Ist eine mobile App für Ihr Unternehmen eine Investition oder nur eine teure Ausgabe für ein digitales Gadget? Am Ende sagen wir Ihnen außerdem, was Sie statt einer vollwertigen App tun können, wenn die Warnsignale aufleuchten.
Spis treści
Wann eine mobile App eine Ausgabe ist und keine Investition
Die Grenze zwischen Investition und Ausgabe ist dünner, als es scheint. Eine Investition zahlt sich in neuen Umsätzen, gesparter Zeit, besserem Kundenservice oder einem Wettbewerbsvorteil aus, den man in Zahlen fassen kann. Eine Ausgabe ist etwas, das schlicht kostet, ständig Nachschub verlangt und keinen Wert erzeugt. Eine mobile App kann beides sein. Wohin sie sich neigt, entscheidet sich in der Regel in der Analysephase und nicht beim Programmieren.
In unserer Praxis sieht das häufigste Szenario so aus: Der Kunde kommt mit einer fertigen Vision – “wir brauchen eine App für iOS und Android”. Nicht mit einem zu lösenden Problem, sondern mit einer konkreten Lösung, für die wir erst noch eine Begründung suchen sollen. Das kehrt die natürliche Reihenfolge um. Ein guter Dienstleister sollte dann die unbequeme Frage stellen: Welches reale mobile Nutzungsszenario wollen wir bedienen, und was verlangt dieses Szenario, das sich nicht günstiger erreichen lässt? Lautet die Antwort “na ja, die Kunden müssen unser Angebot vom Handy aus sehen können”, haben wir das erste Warnsignal.
Eine native App ist nicht deshalb teuer, weil Entwickler gern zu hohe Angebote schreiben. Sie ist teuer, weil sie ein Produkt mit langem Lebenszyklus und hoher technischer Komplexität ist. Sie erstellen nicht ein, sondern zwei getrennte Produkte – für iOS und für Android – Sie pflegen sie in zwei Stores mit unterschiedlichen Regeln, verfolgen Änderungen der Betriebssysteme, reagieren auf erzwungene Bibliotheksaktualisierungen und beantworten Nutzerbewertungen. Das ist eine Verpflichtung für Jahre. Kein einmaliges Projekt mit Enddatum.
Deshalb behandeln wir bei Web Systems die Phase der Anforderungsanalyse als Filter. Bevor wir irgendetwas kalkulieren, prüfen wir, ob die App fünf Kontrollfragen besteht. Jede entspricht einem der unten beschriebenen Signale. Fällt ein Projekt bei mehreren davon durch, sagen wir dem Kunden offen, dass eine responsive Website, eine PWA, ein Web-Werkzeug oder die Integration eines vorhandenen Systems der bessere erste Schritt ist. Und die native App heben wir uns für den Moment auf, in dem der Bedarf wirklich belegt ist.
Warum ergibt dieser Filter ausgerechnet am Anfang Sinn? Weil die Kosten einer Entscheidungsänderung mit dem Projektfortschritt exponentiell steigen. Ein Rückzug in der Analysephase kostet ein paar Termine und etwas verletzten Stolz. Ein Rückzug nach sechs Monaten Arbeit, wenn das Backend halb fertig ist und der UI-Designer bereits alle Screens geliefert hat, ist ein verbranntes Budget in Höhe von Hunderttausenden Zloty. Warnsignale lassen sich vor dem Start am günstigsten erkennen.
Schauen wir uns also fünf konkrete Situationen an, in denen wir als Dienstleister gelbes oder rotes Licht geben. Das sind keine abstrakten Warnungen aus Ratgebern. Das sind Muster, die sich in Gesprächen mit Kunden wiederholen und in Projekten, die wir nach gescheiterten Anläufen anderer Teams gerettet haben. Jedes Signal beschreiben wir aus technischer, finanzieller und geschäftlicher Sicht, denn erst die Verbindung dieser drei Perspektiven ergibt eine ehrliche Antwort auf die Frage nach dem Sinn einer App.
Signal 1: Ihre Nutzer brauchen nichts, was eine responsive Website nicht leisten kann
Das erste und häufigste Signal zeigt sich, wenn wir die Funktionsliste der geplanten App aufschreiben und feststellen, dass sie sich auf das Ansehen von Inhalten, das Ausfüllen von Formularen und die Anmeldung am Konto beschränkt. Produktkatalog, Aktuelles, Kontakt, Kundenbereich, Bestellformular. Das alles leistet heute eine gut gestaltete responsive Website oder eine PWA (Progressive Web App). Deutlich günstiger und ohne die Hürde der Installation aus dem Store.
Eine native App gewinnt erst dann an Vorsprung, wenn Sie tiefen Zugriff auf die Fähigkeiten des Geräts brauchen. Wir sprechen von flüssiger Arbeit mit der Kamera und dem Scannen von Codes in Echtzeit, zuverlässigen Push-Benachrichtigungen, einem vollwertigen Offline-Modus mit lokaler Datenbank, Geolokalisierung im Hintergrund, kontaktlosen NFC-Zahlungen, der Anbindung von Sensoren oder fortgeschrittener Bluetooth-Nutzung. Wenn nichts davon der Kern Ihrer Idee ist, ist eine native App, als würden Sie einen Lkw kaufen, um eine einzige Aktenmappe zu transportieren.
Die Grenze ist allerdings nicht scharf, denn die Webtechnologien holen gegenüber den nativen auf. Eine moderne PWA kann Push-Benachrichtigungen senden, dank Service Workern offline arbeiten, ein Symbol auf dem Startbildschirm installieren und die Kamera nutzen. Der Unterschied liegt im Detail: Push-Benachrichtigungen in einer PWA waren unter iOS lange eingeschränkt, der Zugriff auf manche APIs ist unvollständig, und das Erlebnis ist nicht immer so ausgefeilt wie in nativem Code. Deshalb sollte die Entscheidung aus einem konkreten Szenario folgen und nicht aus der allgemeinen Überzeugung, dass “eine App besser ist”.
Ein typischer Fehler, den wir ständig sehen, ist der Bau einer App, “weil die Konkurrenz eine hat”. Diese Argumentation hat zwei Schwächen. Erstens wissen Sie nicht, ob sich die App der Konkurrenz überhaupt bewährt – vielleicht hängt sie mit drei Downloads und einem Stern im Store und erzeugt nur Wartungskosten. Zweitens ist das Nachahmen einer fremden Technologieentscheidung ohne Kenntnis ihres Kontexts ein Rezept dafür, den Fehler anderer mit eigenem Geld zu wiederholen.
Tipp: Bevor Sie sich für eine App entscheiden, beschreiben Sie einen konkreten Moment im Alltag des Nutzers, in dem er zum Telefon greift, um Ihre Lösung zu verwenden. Lässt sich dieser Moment im Browser genauso bequem bedienen, brauchen Sie wahrscheinlich keine native App. Zumindest nicht zum Start.
Um diese Unterscheidung zu ordnen, hier die Situationen, in denen eine native App eine responsive Website und eine PWA tatsächlich übertrifft:
- Offline-Arbeit mit großen Datenmengen – Servicetechniker im Außendienst, Lagermitarbeiter oder Kurierfahrer an Orten ohne Empfang, die Daten lokal speichern und später synchronisieren müssen.
- Intensive Nutzung von Kamera und Sensoren – das Scannen von Dokumenten, Objekterkennung, Messungen über den Beschleunigungssensor, das Erfassen von Barcodes im Takt von mehreren Dutzend pro Minute.
- Push-Benachrichtigungen als Kern des Produkts – Apps, bei denen eine sofortige, zuverlässige Benachrichtigung über den Wert der gesamten Leistung entscheidet, etwa in der Logistik oder bei Alarmierungen.
- NFC-Zahlungen und Wallet-Anbindung – Zahlungs- und Loyalitätslösungen, die kontaktlosen Kontakt mit einem Terminal erfordern.
- Geolokalisierung im Hintergrund – Routenverfolgung, automatische Anwesenheitsmeldung, Navigation, die auch bei ausgeschaltetem Bildschirm funktionieren muss.
Fällt Ihr Projekt in keinen dieser fünf Körbe, heißt das nicht, dass Sie auf Mobilität verzichten müssen. Es heißt nur, dass es sich lohnt, mit einer günstigen, schnellen Validierung des Bedarfs zu beginnen – einer responsiven Website oder einer PWA – und zu beobachten, wie die Nutzer die Lösung tatsächlich verwenden. Daten aus der realen Nutzung sagen Ihnen mehr über den Sinn einer App als die beste Präsentation in der Vorstandssitzung.
Signal 2: Niemand hat die Wartungskosten berechnet, nur die Umsetzungskosten
Das zweite Signal leuchtet auf, wenn im Budgetgespräch ausschließlich die Frage “was kostet es, die App zu bauen” fällt. Das ist eine Frage nach den Umsetzungskosten, also nach einem einmaligen Kauf. Eine mobile App ist kostenseitig aber ein Abo-Produkt: Sie zahlen für sie durchgehend über ihre gesamte Lebensdauer. Das Weglassen der Wartungskosten in der Kalkulation ist einer der häufigsten Gründe, warum scheinbar gelungene mobile Projekte in Enttäuschung und Aufgabe enden.
Beginnen wir mit der grundlegenden Tatsache. Eine native App für zwei Plattformen bedeutet zwei getrennte Quellcodes, geschrieben in verschiedenen Sprachen und mit verschiedenen Werkzeugen. iOS ist die Welt von Swift und Xcode, Android die von Kotlin und Android Studio. Selbst wenn Sie eine Cross-Platform-Technologie wählen, die diese Doppelung verringert, bleiben Ihnen zwei Builds, zwei Veröffentlichungsprozesse und zwei Sätze plattformspezifischer Probleme. Jede Änderung ist häufig doppelt zu leistende Arbeit.
Hinzu kommen Kosten, die Kunden in der Planungsphase meist überhaupt nicht berücksichtigen. Ein Apple-Entwicklerkonto ist eine jährliche Gebühr, ein Google-Play-Konto eine einmalige, doch beide Plattformen ändern regelmäßig ihre technischen Anforderungen. Apple kann eine Anhebung der minimalen SDK-Version erzwingen, wodurch eine App, die einwandfrei lief, plötzlich nicht mehr im Store akzeptiert wird, bis Sie sie aktualisieren. Google macht genau dasselbe und schreibt neue Anforderungen an die Zielversion des Systems vor, unter Androhung der Entfernung aus Google Play.
Hier eine realistische Liste der versteckten Kosten, die man über mehrere Jahre zur Wartung einer mobilen App hinzurechnen muss:
- Konten und Zertifikate – jährliche Entwicklergebühren, Erneuerung der Signaturzertifikate, Verwaltung von Schlüsseln und Provisioning-Profilen.
- Erzwungene Plattform-Updates – Anpassung des Codes an neue Versionen von iOS und Android, die jedes Jahr erscheinen und alte APIs abschalten können.
- Aktualisierung von Bibliotheken und Abhängigkeiten – das Schließen von Sicherheitslücken in externen Komponenten, von denen eine typische App Dutzende nutzt.
- Store-Prüfungen und -Richtlinien – Zeit für das Durchlaufen des Review-Prozesses, Reaktion auf Ablehnungen, Anpassung an die sich ändernden Regeln von App Store und Google Play.
- Unterstützung vieler Systemversionen und Geräte – Tests auf verschiedenen Telefonmodellen, Bildschirmauflösungen und Systemversionen, die Ihre Nutzer verwenden.
- Monitoring und Störungsbehebung – Werkzeuge zur Fehlerverfolgung, Reaktionszeit auf Meldungen, Ausliefern von Korrekturen.
Keiner dieser Punkte ist Theorie. Jeder ist eine monatliche oder jährliche Ausgabe, die nach der Premiere nicht verschwindet. Eine App, die ein Jahr lang keine Aktualisierung erhält, beginnt zu bröckeln: Sie funktioniert auf neuen Telefonen nicht mehr, verschwindet aus dem Store oder öffnet sich für Sicherheitslücken. Ein digitales Produkt, das nicht gepflegt wird, bleibt nicht stehen. Es fällt zurück, weil sich das technische Umfeld ohne es weiterentwickelt.
Tipp: Bevor Sie das Umsetzungsbudget berechnen, schätzen Sie die Wartungskosten für zwei bis drei Jahre und behandeln Sie sie als vollwertigen Teil der Entscheidung. Nach unserer Erfahrung sind die jährlichen Wartungskosten einer gut gebauten App oft ein erheblicher Bruchteil ihrer Herstellungskosten. Wenn Sie diese Zahl erschreckt, ist das ein Zeichen dafür, dass das Projekt womöglich nicht im Verhältnis zum Bedarf steht.
Ein ehrlicher Dienstleister legt Ihnen diese Zahlen von vornherein vor, auch wenn sie die Chance auf einen Vertragsabschluss senken. Bei Web Systems verlieren wir lieber einen Auftrag für eine unpassende App, als etwas zu bauen, das nach einem Jahr aufgegeben wird, weil der Kunde die Wartungskosten nicht eingeplant hat. Ein aufgegebenes Projekt bedeutet nicht nur verlorenes Geld des Kunden. Es geht auch um unseren Ruf, und den bauen wir seit 2006 zu lange auf, um ihn für einen einmaligen Umsatz zu riskieren.
Signal 3: Es fehlen Backend, Integrationen und eine “einzige Quelle der Wahrheit” für die Daten
Das dritte Signal ist das technischste, dafür aber finanziell das gefährlichste. Es tritt auf, wenn sich das ganze Gespräch über die App um das Aussehen der Bildschirme, die Farben der Schaltflächen und Übergangsanimationen dreht und niemand fragt, woher die App ihre Daten nimmt und wo sie sie speichert. Denn eine mobile App ist vor allem eine Präsentationsschicht: das, was der Nutzer sieht. Ohne solides Backend, Datenbank und Integrationen mit den Systemen des Unternehmens ist sie eine leere, hübsche Hülle.
Stellen Sie sich eine App für ein Handelsunternehmen vor, die Lagerbestände anzeigen, Bestellungen annehmen und über den Versandstatus informieren soll. Jede dieser Funktionen erfordert eine Verbindung zu etwas auf der Serverseite: einem Lagersystem, einem ERP, einem Payment-Gateway, einem Logistikmodul. Die App selbst “weiß” nichts – sie zeigt nur an, was die API ihr liefert, und schickt zurück, was der Nutzer eingibt. Sind diese serverseitigen Systeme nicht bereit, geordnet und über sinnvolle Schnittstellen bereitgestellt, ist der Bau eines teuren mobilen Frontends wie das Errichten des Dachs, bevor das Fundament steht.
Hier lohnt der Griff zu einem Grundsatz, der seit Jahren das Fundament guter Anwendungsarchitektur bildet, auch in den offiziellen Empfehlungen für Android. Die Dokumentation zur Android-App-Architektur formuliert es so:
It’s a common mistake to write all your code in an Activity. The primary role of an Activity is to host your app’s UI. This ephemeral nature makes them unsuitable for holding application data or state.
Mit anderen Worten: Daten und Geschäftslogik dürfen nicht in der Oberflächenschicht liegen. Die Daten und Regeln, die bestimmen, wie Ihr Unternehmen arbeitet, müssen in der Datenschicht leben – im Backend und in der Datenbank – und die App sollte diese Schicht lediglich abfragen und darstellen. Diese Trennung der Verantwortlichkeiten (Schichtentrennung) ist keine akademische Spielerei. Sie ist die Voraussetzung dafür, dass sich das Produkt pflegen und weiterentwickeln lässt, ohne es bei jeder Änderung neu zu schreiben.
Damit verbunden ist der Begriff der einzigen Quelle der Wahrheit über die Daten (single source of truth). Dieselbe Architekturdokumentation sagt es direkt:
When a new data type is defined in your app, assign a single source of truth. The SSOT is the owner of that data, and only the SSOT can modify or mutate it. This pattern centralizes all changes to a particular type of data in one place and protects the data so that other types cannot tamper with it.
In der Praxis bedeutet das: Lagerbestand, Produktpreis oder Bestellstatus haben einen einzigen, maßgeblichen Ort, an dem sie gespeichert und geändert werden – in der Regel eine Datenbank auf der Serverseite. Die mobile App, die Website, das Servicepanel und das Rechnungssystem lesen dieselben Daten aus derselben Quelle. Fehlt einem Unternehmen diese Ordnung, hat jeder Kanal seine eigene Wahrheit, die Daten laufen auseinander, und die mobile App wird zu einem weiteren Ort, an dem widersprüchliche Informationen auftauchen.
Der teuerste Fehler, den wir beobachten, ist der Bau eines umfangreichen mobilen Frontends, bevor Daten und Integrationen auf der Serverseite geordnet wurden. Der Kunde zahlt für schöne Bildschirme, und dann stellt sich heraus, dass es keine API gibt, die sie füttert, dass die Daten im ERP in einem unvorhersehbaren Zustand sind und dass die Anbindung des Lagers das Neuschreiben des halben Systems erfordert. Das Frontend wartet, die Kosten steigen, und die Premiere verschiebt sich um Quartale.
Deshalb schlagen wir bei Web Systems, wenn wir dieses Signal sehen, vor, die Reihenfolge der Arbeiten umzudrehen. Zuerst bringen wir das Backend in Ordnung, entwerfen die API, legen eine einzige Quelle der Wahrheit und die Integrationen mit vorhandenen Systemen fest. Und erst danach bauen wir die mobile Schicht. Dabei zeigt sich oft, dass sich, sobald Backend und API existieren, Wert schnell und günstig über eine Webanwendung oder eine PWA liefern lässt und die native App auf den Moment verschoben werden kann, in dem sie wirklich begründet ist.
Signal 4: Die Nutzerprognose rechtfertigt nicht zwei Plattformen auf einmal
Das vierte Signal betrifft die Größenordnung. Es leuchtet auf, wenn wir eine native App für iOS und Android für eine Zielgruppe planen, die klein, bekannt und abzählbar ist. Das klassische Beispiel ist ein internes Werkzeug für dreißig Außendienstmitarbeiter oder eine App für einen geschlossenen Kreis von Geschäftspartnern. Bau und Wartung zweier getrennter nativer Apps für einen so engen Kreis lassen sich wirtschaftlich selten verteidigen.
Die Logik ist einfach. Die Kosten für Bau und Wartung einer nativen App sind weitgehend fix, unabhängig von der Nutzerzahl. Zwei Codebasen, zwei Veröffentlichungsprozesse und zwei Testsätze kosten ähnlich viel, egal ob dreißig Personen sie nutzen oder dreihunderttausend. Der Unterschied besteht darin, dass sich diese Fixkosten bei großer Reichweite auf eine riesige Nutzerbasis verteilen und auf Pfennige pro Person hinauslaufen, während sie bei kleiner Reichweite wie ein Stein auf dem Budget lasten. Deshalb sollte die Prognose der Nutzerzahl eine der ersten Eingangsgrößen für die Architekturentscheidung sein.
Zum Glück sind zwei native Apps nicht der einzige Weg zur Mobilität. Das Spektrum der Möglichkeiten ist breit, und es lohnt sich, es zu kennen, bevor man standardmäßig die teuerste Option wählt:
- Eine Cross-Platform-Codebasis – Technologien wie Flutter oder React Native erlauben es, die App einmal zu schreiben und aus einer Codebasis auf iOS und Android auszuliefern. Das beseitigt die Unterschiede zwischen den Plattformen nicht vollständig, senkt aber die Bau- und Wartungskosten deutlich, was bei mittlerer Reichweite oft ein vernünftiger Kompromiss ist.
- Progressive Web App – eine Anwendung, die im Browser läuft, sich auf dem Startbildschirm installieren lässt und einen Teil der Gerätefunktionen nutzt. Keine Installation aus dem Store und eine Codebasis für alle Plattformen machen sie zu einem sehr günstigen Einstieg in die Mobilität.
- Eine Webanwendung statt einer Store-App – für interne Werkzeuge ist oft schlicht eine responsive Webanwendung unter einer URL die beste Wahl, ohne den Umweg über App Store und Google Play mit ihren Prüfungen und Gebühren.
Ein internes Werkzeug für dreißig Mitarbeiter ist geradezu ein Lehrbuchfall, in dem eine Webanwendung oder eine PWA die native App klar schlägt. Die Mitarbeiter melden sich über den Browser an, eine Aktualisierung ist für alle sofort wirksam (Sie warten nicht, bis jeder die App im Store aktualisiert), es gibt keinen Prüfprozess, und die Wartungskosten sind ein Bruchteil dessen, was zwei native Apps verschlingen würden. Zugriff auf Kamera oder Benachrichtigungen lässt sich, wenn er nötig ist, oft im Rahmen einer PWA lösen.
Tipp: Erstellen Sie eine einfache Entscheidungstabelle mit drei Spalten – Nutzerzahl, Gerätetypen, Nutzungsszenarien – und wählen Sie erst auf dieser Grundlage die Technologie. Eine Architekturentscheidung sollte aus harten Daten folgen und nicht aus der Mode einer “App” oder dem Wunsch, ein Symbol im Store zu haben.
Denken Sie auch daran, dass die Technologiewahl keine Entscheidung für immer ist. Ein vernünftiger Weg für ein Unternehmen mit unsicherer Reichweite ist, mit einer PWA oder einer Cross-Platform-App zu beginnen, Daten zur realen Nutzung zu sammeln und dann, sofern die Zahlen es rechtfertigen, dort in eine native Lösung zu investieren, wo sie wirklich einen Vorsprung bringt. Dieses Vorgehen der schrittweisen Eskalation schützt das Budget und erlaubt es, jede weitere Entscheidung auf Belege statt auf Annahmen zu stützen.
Bei Web Systems arbeiten wir mit all diesen Technologien, wir haben also kein Interesse daran, eine davon durchzudrücken. Unsere Aufgabe ist es, das Werkzeug zum Problem zu wählen und nicht das Problem zum Lieblingswerkzeug. Wenn die Nutzerprognose nicht zwei Plattformen auf einmal rechtfertigt, sagen wir das offen und zeigen günstigere Wege zum selben geschäftlichen Ziel.
Signal 5: Niemand hat Sicherheit, Skalierung und die Zeit nach der Premiere geplant
Das fünfte Signal ist zugleich das schwerwiegendste und das am häufigsten übergangene. Es leuchtet auf, wenn im Gespräch über das Projekt kein einziger Satz zu Sicherheit, Skalierung und dem fällt, was nach der Premiere mit der App geschieht. Die gesamte Energie fließt in den Starttermin, als wäre die Premiere das Ziel und nicht der Anfang. Für ein digitales Produkt ist die Premiere aber erst der Beginn der längsten und teuersten Phase seines Lebens.
Sicherheit ist der Bereich, in dem sich ein fehlender Plan am schmerzhaftesten rächt. Eine App, die Kundendaten verarbeitet, braucht eine durchdachte Authentifizierung, sichere Speicherung und Übertragung von Daten, Schutz vor typischen Angriffen sowie DSGVO-Konformität. Das sind keine Zusätze, die man am Ende anklebt. Das ist ein Fundament, das von Anfang an entworfen werden muss. Eine mobile App läuft auf einem fremden Gerät, außerhalb der Kontrolle des Unternehmens, was zusätzliche Anforderungen stellt: Lokal gespeicherte Daten müssen geschützt, die Kommunikation mit dem Server verschlüsselt sein, und Schlüssel und Geheimnisse sollten niemals ungeschützt im Code der App landen.
Hinzu kommen Sicherheitsupdates, die ein fortlaufender Prozess sind. In den Bibliotheken, die eine App nutzt, werden regelmäßig Schwachstellen bekannt – jemand muss sie verfolgen und beheben. Ist für diesen Prozess niemand zuständig, wird die App von Monat zu Monat löchriger, bis sie schließlich ein reales Risiko für das Unternehmen und seine Kunden darstellt. Die DSGVO fügt rechtliche Pflichten hinzu: das Recht auf Löschung, Einwilligungen, das Verzeichnis von Verarbeitungstätigkeiten. All das muss sich in der Architektur widerspiegeln und nicht nur in den Nutzungsbedingungen.
Skalierung und Wartung sind der zweite Bereich, der regelmäßig in der Schublade mit der Aufschrift “darum kümmern wir uns später” landet. Und dieses “später” ist nach unserer Erfahrung die häufigste Ursache aufgegebener mobiler Projekte. Ein für hundert Nutzer ausgelegtes Backend kippt bei zehntausend um. Hastig geschriebener Code ohne Tests und Dokumentation lässt sich nicht mehr weiterentwickeln, sobald das ursprüngliche Team weg ist. Ein fehlender Entwicklungsplan bedeutet, dass jede neue Funktion ein Kampf mit den seit der Premiere angehäuften technischen Schulden ist.
Tipp: Wenn Sie die Frage nicht beantworten können, wer diese App in einem Jahr weiterentwickelt und pflegt, ist das ein sehr starkes Signal dafür, dass es vorerst keinen Sinn ergibt, sie zu bauen. Ein digitales Produkt ohne Eigentümer und ohne Wartungsplan ist keine Investition, sondern ein aufgeschobenes Problem.
Ein Plan für die Zeit nach der Premiere sollte mehrere konkrete Punkte umfassen: wer Fehler überwacht und wie schnell auf Störungen reagiert wird, wie oft Aktualisierungen erscheinen, wer für die Kompatibilität mit neuen Systemversionen verantwortlich ist, wie das Entwicklungsbudget der kommenden Jahre aussieht und wie wir messen, ob die App ihre geschäftlichen Ziele tatsächlich erfüllt. Ohne diese Antworten ist eine Premiere ein Sprung ins Dunkle und kein kontrollierter Produktstart.
Genau hier zeigt sich der Unterschied zwischen einem Dienstleister, der nur ein Projekt verkaufen will, und einem technischen Partner, der über den Lebenszyklus des Produkts nachdenkt. Bei Web Systems sind Sicherheit, Skalierbarkeit und Wartungsplan vom ersten Termin an Teil des Gesprächs und kein Thema für “irgendwann”. Wir entwerfen lieber ein kleineres, aber solides und pflegbares Produkt als eine umfangreiche App, die bei der Premiere begeistert und ein Jahr später zur aufgegebenen Last wird. Sicherheit und Skalierung sind keine Kosten, die sich umgehen lassen. Es sind Kosten, die Sie entweder vorab im Projekt zahlen oder um ein Vielfaches teurer in Form eines Vorfalls und verlorenen Kundenvertrauens.
FAQ: häufige Fragen zum Sinn einer mobilen App für Unternehmen
In Gesprächen mit Kunden kehren bestimmte Fragen fast jedes Mal wieder. Wir haben die zwei häufigsten gesammelt und beantworten sie so, wie wir sie in Terminen beantworten: konkret und ohne Marketing-Watte.
Mobile App oder responsive Website – was zum Start wählen?
Zum Start beginnen Sie fast immer mit einer günstigen Validierung des mobilen Bedarfs und nicht mit einer vollwertigen nativen App. Eine gut gestaltete responsive Website oder eine PWA erlaubt es, zu einem Bruchteil der Kosten und des Risikos zu prüfen, ob die Nutzer Ihre Lösung tatsächlich am Telefon verwenden und wie sie das tun. Sie sammeln dabei echte Daten: wie viele Personen von mobilen Geräten kommen, welche Funktionen genutzt werden, wo Probleme auftreten. Erst wenn diese Daten einen klaren Bedarf für etwas zeigen, das das Web nicht abdeckt – etwa Offline-Arbeit, intensive Kameranutzung oder zuverlässige Push-Benachrichtigungen – beginnt sich die Investition in eine native App zu rechtfertigen. Diese Reihenfolge umzudrehen, also eine teure App auf gut Glück zu bauen, ist die häufigste Ursache verbrannter Budgets, die wir sehen. Eine PWA als erster Schritt kostet ein Vielfaches weniger und gibt Ihnen eine harte Grundlage für die nächste Entscheidung.
Muss man iOS und Android immer getrennt entwickeln?
Nein. Und sehr oft lohnt es sich nicht. Getrennte native Apps für iOS und Android ergeben vor allem bei großer Reichweite Sinn, wenn sich die Fixkosten zweier Codebasen auf eine riesige Nutzerbasis verteilen, sowie dort, wo Sie maximale Leistung und den tiefsten Zugriff auf die Möglichkeiten einer bestimmten Plattform brauchen. Bei kleinerer Reichweite ist oft eine Cross-Platform-Codebasis deutlich vernünftiger – etwa in Flutter oder React Native – die beide Plattformen aus einer Basis bedient, oder schlicht eine Webanwendung beziehungsweise eine PWA, wenn die Nutzungsszenarien es zulassen. Die Entscheidung sollte aus der Nutzerzahl, der Art der Geräte und den konkreten Szenarien folgen und nicht aus der Annahme, man müsse “in beiden Stores vertreten sein”. Viele unserer Kunden waren überrascht, wie viel sich auf dem günstigeren Weg erreichen ließ, sobald wir mit der Analyse des Bedarfs begannen und nicht mit der voreingestellten Wahl der teuersten Option.
Fazit: Prüfen Sie diese 5 Signale, bevor Sie eine App bauen
Kehren wir zu den fünf Warnsignalen zurück, die wir als Dienstleister schon in der Phase der Anforderungsanalyse erkennen. Jedes davon ist eine Frage, die Sie sich ehrlich beantworten sollten, bevor Sie einen Vertrag über eine mobile App für Ihr Unternehmen unterschreiben. Zusammen bilden sie einen einfachen, aber wirksamen Filter, der Investitionen von teuren Ausgaben für ein digitales Gadget trennt.
Erstens der reale mobile Bedarf: Brauchen Ihre Nutzer etwas, das eine responsive Website oder eine PWA nicht leisten kann, oder beschränkt sich die App auf das Ansehen von Inhalten und Formulare? Zweitens die Wartungskosten: Hat jemand die Ausgaben für zwei, drei Jahre im Voraus berechnet und nicht nur die Kosten der Umsetzung selbst? Drittens ein fertiges Backend und Integrationen: Gibt es eine geordnete Datenschicht mit einer einzigen Quelle der Wahrheit, oder wird die App eine leere Hülle ohne API und ohne Verbindungen zu den Systemen des Unternehmens? Viertens die Zahl der Nutzer: Rechtfertigt die prognostizierte Zielgruppe zwei native Plattformen, oder sind eine Cross-Platform-Codebasis oder das Web die bessere Wahl? Fünftens der Sicherheits- und Entwicklungsplan: Ist klar, wer die App nach der Premiere schützt, skaliert und weiterentwickelt?
Leuchten mehrere dieser Signale gleichzeitig auf, heißt das nicht, dass Sie Ihre digitalen Ambitionen aufgeben müssen. Es heißt, dass eine vollwertige native App wahrscheinlich nicht der richtige erste Schritt ist. Oft ist ein MVP der deutlich bessere Einstieg, also eine minimale Produktversion, die die Idee mit geringem Aufwand an echten Nutzern prüft. Ebenso oft lässt sich der Wert, den Sie suchen, über eine Integration oder die Automatisierung eines bestehenden Systems liefern, ganz ohne etwas Mobiles von Grund auf zu bauen. Das Ordnen der Daten, die Bereitstellung einer sinnvollen API, die Automatisierung wiederkehrender Prozesse oder die Modernisierung eines veralteten Systems können einem Unternehmen mehr bringen als eine glänzende App, die vor allem Wartungskosten erzeugt.
Bei Web Systems entwerfen und realisieren wir seit 2006 Web- und mobile Anwendungen, B2B-Systeme, API-Integrationen, Automatisierungen, E-Commerce-Lösungen sowie KI-Umsetzungen. Diese Erfahrung hat uns eines gelehrt: Die beste Empfehlung, die wir einem Kunden geben können, ist manchmal die, die ihm Geld spart. Deshalb beginnen wir mit der Frage nach dem Problem und nicht nach der fertigen Lösung und wählen die Technologie passend zum tatsächlichen Bedarf, zur Größenordnung und zum Budget.
Wenn Sie sich fragen, ob eine mobile App in Ihrem Fall Sinn ergibt, oder einen vernünftigen ersten Schritt suchen, lassen Sie uns sprechen. Wir helfen Ihnen, diese fünf Signale an einem konkreten Projekt durchzugehen, und sagen Ihnen, ob ein MVP, eine App, eine API-Integration, eine Automatisierung, eine KI-Lösung oder die Modernisierung eines bestehenden Systems die bessere Wahl ist. Nehmen Sie Kontakt mit dem Team von Web Systems auf – wir beginnen bei Ihrem Problem und nicht bei einer fertigen App.
