Bei Web Systems entwerfen und realisieren wir seit 2006 Software im Auftrag von Unternehmen aus Łódź und ganz Polen. In all diesen Jahren kam eine Frage in fast jedem Verkaufsgespräch zurück: “Was wird die mobile App kosten?”. Genau darum geht es. Das Problem ist, dass ein Kunde, der nach einer Handy-App fragt, in Wirklichkeit sehr oft etwas ganz anderes braucht. Die Entscheidung, ob Sie eine Web-Anwendung oder eine mobile Anwendung bauen, ist keine Geschmacksfrage und keine Frage der aktuellen Mode. Es ist eine Architekturentscheidung, die über Budget, Tempo der Einführungen und Wartungskosten des Produkts über Jahre hinweg bestimmt.
Spis treści
Eine Entscheidung, die über Budget und Wartung des Produkts bestimmt
Beginnen wir damit, mit einem verbreiteten Missverständnis aufzuräumen. In den Köpfen vieler Unternehmer muss ein “ordentliches digitales Produkt” ein Symbol auf dem Handybildschirm haben, am besten im App Store und bei Google Play. Und diese Überzeugung kann teuer werden. Eine native Anwendung für iOS und Android bedeutet zwei getrennte Codebasen, zwei Veröffentlichungsprozesse, zwei Testreihen und ein Backend, das Sie ohnehin separat bauen müssen. Noch bevor Sie den ersten Nutzer erreichen, tragen Sie die dreifachen Kosten.
Die Wahl zwischen einer Web-Anwendung und einer mobilen Anwendung ist eine architektonische, keine ästhetische Entscheidung. Es geht nicht darum, “was in der Präsentation für die Geschäftsführung schöner aussieht”, sondern darum, wo Ihre Nutzer wirklich leben, welche Daten Sie verarbeiten, wie oft Sie Änderungen ausliefern und wie viele Menschen das Produkt nach dem Start betreuen. Die Architektur ist das Fundament, auf dem in den kommenden Jahren Weiterentwicklung, Sicherheit und Skalierbarkeit ruhen. Ein Fehler in dieser Phase kostet keine paar hundert Złoty. Er kostet Monate an Arbeit und Zehntausende Złoty an technischen Schulden.
Ein typischer Fehler, den wir in der Praxis sehen, sieht so aus: Ein B2B-Unternehmen bestellt eine mobile Anwendung für seine Außendienstmitarbeiter oder für ein internes Team, und nach der Einführung stellt sich heraus, dass die Mitarbeiter sie ohnehin vor allem am Computer nutzen. Denn die Dateneingabe auf einem Handybildschirm ist langsam und mühsam. Bezahlt wurde für native Mobilität, die niemand tatsächlich nutzt. Auf der anderen Seite treffen wir Start-ups, die sofort die App-Stores erobern wollen, obwohl ihre Geschäftshypothese noch an keinem einzigen Nutzer geprüft wurde.
In diesem Artikel finden Sie keinen neutralen, enzyklopädischen Vergleich “Web gegen Mobile”. Wir zeigen Ihnen etwas Praktischeres: 7 konkrete Signale, die in unserer Projektarbeit meist bedeuten, dass ein digitales Produkt keine native Handy-App braucht, sondern eine gut entworfene Web-Anwendung oder PWA. Es sind Signale, die aus realen Problemen stammen: Kosten, Integration, Sicherheit und Wartung. Nicht aus der Theorie.
Jedes dieser Signale betrachten wir aus der Perspektive des Dienstleisters, der diese Anwendung später weiterentwickeln und betreuen muss. Denn es ist leicht, einem Kunden zu verkaufen, was er möchte. Schwieriger, aber ehrlicher ist es, ihm das zu empfehlen, was er wirklich braucht. Wenn Sie Ihr Produkt in mehreren der folgenden Punkte wiedererkennen, sind Ihr Geld und die Zeit Ihres Teams wahrscheinlich in einer soliden Weblösung besser angelegt. Und wenn nicht, erfahren Sie, wann eine mobile Anwendung tatsächlich Sinn ergibt. Betrachten Sie die folgenden Abschnitte als Checkliste für eine bewusste Entscheidung, bevor Sie die erste Rechnung für die Entwicklung unterschreiben.
Signal 1: Ihre Nutzer arbeiten am Schreibtisch, nicht unterwegs
Die erste Frage, die wir jedem Kunden stellen, lautet: Wo und wie nutzt Ihr Nutzer das Produkt physisch? Die Antwort sagt mehr als zehn Seiten Spezifikation. Wenn das typische Szenario eine Person ist, die am Schreibtisch sitzt, mit großem Monitor, Tastatur, Maus und einem Dutzend gleichzeitig geöffneter Browser-Tabs, dann sprechen wir von einem stationären Kontext. Und ein stationärer Kontext spricht fast immer für eine Web-Anwendung.
Denken Sie an die tatsächliche Arbeit in solchen Lösungen: das Verwaltungspanel eines Shops, ein CRM-System, in dem ein Vertriebler Gesprächsnotizen erfasst, ein Werkzeug für die Projektsteuerung, ein ERP-System, ein Panel für die Auftragsabwicklung oder eine interne Buchhaltungsanwendung. In all diesen Fällen braucht der Nutzer Platz auf dem Bildschirm, schnelles Wechseln zwischen Ansichten, das Kopieren von Daten zwischen Modulen und das bequeme Eingeben längerer Texte. Ein Handy ist hier weniger eine Einschränkung als ein echtes Hindernis für die Produktivität.
Eine mobile Anwendung ergibt Sinn, wenn das Produkt den sogenannten mobilen Kontext nutzt: präzise GPS-Ortung, Kamera, Beschleunigungssensor, Push-Benachrichtigungen, die den Nutzer im Laufe des Tages erreichen, Arbeit im Außeneinsatz ohne Zugang zu einem Computer. Ein Kurier, der Pakete scannt, ein Fahrer in einer Fahrdienst-App, ein Fitnesstrainer, eine App für kontaktloses Bezahlen: Das sind natürliche mobile Szenarien. Doch wenn Ihr Produkt weder Kamera noch Ortung braucht und Benachrichtigungen problemlos per E-Mail oder Browser laufen, wird der mobile Kontext hier schlicht nicht benötigt.
Am wichtigsten ist jedoch die wirtschaftliche Rechnung. Die Kosten für Bau und Betrieb einer nativen mobilen Anwendung rentieren sich nicht, wenn der Nutzer ohnehin stationär arbeitet. Sie zahlen für den Zugang zu Handyfunktionen, die niemand nutzt, und für die Präsenz in Stores, in die Ihre Zielgruppe gar nicht hineinschaut, weil sie sich morgens am Bürorechner anmeldet. Eine Ausgabe ohne Rendite.
Im B2B-Segment ist das besonders deutlich zu sehen. Entscheider sagen oft “wir wollen eine App” und meinen damit einfach “wir wollen ein modernes Werkzeug”. Modern ist aber nicht das Symbol auf dem Handy-Startbildschirm, sondern eine responsive, schnelle Weboberfläche, die nach der Anmeldung von jedem Gerät aus verfügbar ist. Eine gut entworfene Web-Anwendung öffnet sich auf dem Desktop im Büro, auf dem Tablet im Besprechungsraum und im Notfall auf dem Handy unterwegs. Ohne dass Sie drei getrennte Produkte bauen müssen.
Tipp: Bevor Sie sich für eine Plattform entscheiden, machen Sie ein einfaches Experiment. Bitten Sie 5 Zielnutzer, eine Woche lang zu notieren, auf welchem Gerät und in welcher Situation sie Ihr Werkzeug am häufigsten nutzen würden. Wenn die deutliche Mehrheit “Computer, am Schreibtisch, während der Arbeitszeit” angibt, haben Sie ein erstes starkes Signal, dass eine Handy-App ein überflüssiger Kostenpunkt ist und das Budget besser in die Ausarbeitung der Webversion und ihrer Integration mit den übrigen Systemen des Unternehmens fließt.
Signal 2: Sie brauchen schnelle Releases und eine Version für alle
Das zweite Signal betrifft das Tempo, in dem Sie Änderungen einführen wollen. Bei uns ist das oft der entscheidende Faktor, weil es sich direkt auf die Beweglichkeit des Geschäfts auswirkt. Eine Web-Anwendung gibt Ihnen etwas, das eine native mobile App nie bieten wird: die volle Kontrolle über den Zeitpunkt der Auslieferung. Sie spielen eine neue Version auf den Server, und in derselben Sekunde arbeiten alle Nutzer mit dem aktuellen Code. Ohne Warten, ohne Zwischeninstanzen, ohne Warteschlangen.
In der Welt der mobilen Anwendungen durchläuft jede Aktualisierung einen Freigabeprozess im App Store und bei Google Play. Eine Prüfung durch Apple kann von einigen Stunden bis zu einigen Tagen dauern, und bei einer Ablehnung beginnt der ganze Zyklus von vorn. Sie entdecken am Freitagabend einen kritischen Fehler? Im mobilen Modell erreicht die Korrektur die Nutzer vielleicht erst nächste Woche. Im Web-Modell spielen Sie den Patch sofort aus. Für ein Produkt, das sich schnell verändert, ist dieser Unterschied grundlegend.
Dazu kommt die Frage der Anzahl der Codebasen. Ein vollwertiger nativer Ansatz bedeutet, drei getrennte Welten zu pflegen: die iOS-Anwendung, die Android-Anwendung und das Backend, das beide bedient. Jede neue Funktion muss dreifach umgesetzt, getestet und ausgeliefert werden. Eine Web-Anwendung bedeutet eine Codebasis im Frontend und ein Backend. Weniger Code heißt weniger Stellen, an denen ein Fehler auftreten kann, weniger Tests und deutlich niedrigere Entwicklungskosten im Zeitverlauf.
Es lohnt sich, diese Vorteile an einer Stelle zu sammeln, denn im Eifer der Funktionsplanung übersieht man sie leicht:
- Sofortige Releases – eine Änderung erreicht alle Nutzer im Moment der Veröffentlichung auf dem Server, ohne Prüfprozess der Stores.
- Eine Codebasis – statt getrennter Teams für iOS, Android und Backend pflegen Sie ein einheitliches Frontend-Projekt.
- Keine Installation – der Nutzer öffnet einen Link im Browser und arbeitet sofort, was die Einstiegshürde nahezu auf null senkt.
- Einheitliche Versionen – es gibt kein Problem mit Nutzern, die monatelang mit einer veralteten, nicht aktualisierten Version arbeiten.
- Geringere technische Schulden – weniger Plattformen bedeuten weniger Abhängigkeiten zum Aktualisieren und weniger Risiko, dass sie auseinanderlaufen.
Der Wegfall der Installation verdient besondere Aufmerksamkeit. Bei einer mobilen Anwendung steht zwischen Ihrem Produkt und dem Nutzer ein ganzer Weg: im Store finden, herunterladen, Berechtigungen erteilen, ein Konto anlegen. Jeder dieser Schritte ist ein Punkt, an dem ein Teil der Zielgruppe abspringt. Eine Web-Anwendung funktioniert sofort nach dem Klick auf einen Link, was besonders bei der Gewinnung neuer Kunden und beim Testen des Produkts enorm wichtig ist.
Niedrigere Wartungskosten und geringere technische Schulden im Zeitverlauf sind keine Broschürenfloskeln, sondern echte Einsparungen. Je weniger Plattformen Sie synchron halten müssen, desto langsamer wächst die Komplexität des Systems und desto länger kann sich Ihr Team auf die Weiterentwicklung konzentrieren statt auf das Löschen von Bränden, die aus den Unterschieden zwischen iOS und Android entstehen. Für die meisten Geschäftsprodukte ist diese Berechenbarkeit mehr wert als native Animationen.
Signal 3: Das Herz des Produkts sind Daten, Integrationen und Geschäftslogik
Das dritte Signal erkennen wir, sobald wir darüber sprechen, worin der eigentliche Wert des Produkts liegt. Wenn sich zeigt, dass es nicht um eine effektvolle Oberfläche geht, sondern um Daten, ihre Verarbeitung, die Verbindung mit anderen Systemen und um Geschäftsregeln, dann bauen Sie im Grunde ein Informationssystem. Und Informationssysteme fühlen sich in einer Web-Architektur am wohlsten, in der die gesamte Logik auf dem Server lebt, nahe an den Daten und Integrationen.
In B2B-Projekten entsteht fast immer der Bedarf, andere Systeme anzubinden. In der Praxis ist das eine ganze Liste typischer Integrationen, die wir täglich umsetzen:
- REST API und Webhooks – Datenaustausch mit externen Diensten in Echtzeit.
- ERP-Systeme – Synchronisation von Lagerbeständen, Bestellungen und Buchhaltungsbelegen.
- CRM-Systeme – Informationsfluss zu Kunden, Leads und Kontakthistorie.
- Zahlungs-Gateways – Abwicklung von Transaktionen, Abonnements und Abrechnungen.
- Data Warehouses und BI-Werkzeuge – Versorgung von Berichten und Geschäftsanalysen.
Eine Web-Anwendung fügt sich in ein solches Ökosystem deutlich leichter ein. Sie arbeitet in derselben Netzwerkschicht wie die übrigen Unternehmensdienste und kommuniziert mit ihnen serverseitig, ohne die Beschränkungen durch Handy-Betriebssysteme oder die Richtlinien der App-Stores. Automatisierungen, zyklisch gestartete Aufgaben, Verarbeitung im Hintergrund, Integrationen mit Partnersystemen: All das gelingt natürlicher, wenn die Produktlogik auf dem Server wohnt und nicht über die Geräte der Nutzer verstreut ist.
Entscheidend wird hier die richtige interne Architektur. In einem gut entworfenen System trennen wir die Oberflächenschicht klar von der Schicht der Geschäftslogik und von der Datenschicht. Die Logik kapseln wir in Repositories, die als einzige Stelle für das Lesen und Schreiben eines bestimmten Datentyps zuständig sind. Die Oberfläche zeigt nur an, was ihr die darunterliegende Schicht liefert, und gibt die vom Nutzer ausgelösten Ereignisse nach unten weiter. Diese Trennung macht das System testbar, widerstandsfähig gegen Änderungen und leicht durch nachfolgende Entwickler erweiterbar.
Fachmaterialien zur Anwendungsarchitektur formulieren dieses Prinzip unmissverständlich. Wie die Autoren der Architekturdokumentation betonen:
Das wichtigste Prinzip ist die Trennung der Verantwortlichkeiten: die Aufteilung der Anwendung in Methoden, Klassen, Dateien, Pakete, Module und Schichten mit klar definierten Aufgaben und Grenzen.
Eng mit der Trennung der Verantwortlichkeiten verbunden ist die Idee einer einzigen Quelle der Wahrheit. Jeder Datentyp sollte einen Eigentümer haben, der ihn als Einziger verändern darf und der diese Daten dem übrigen System bereitstellt. Dadurch geschehen alle Änderungen eines bestimmten Datentyps an einer Stelle, sind vor versehentlichen Eingriffen von außen geschützt und leichter nachzuverfolgen, wenn die Fehlerquelle gefunden werden muss. In einer Web-Anwendung ist diese Quelle der Wahrheit üblicherweise die Datenbank auf der Serverseite.
Und genau hier zeigt sich der Vorteil gegenüber dem verteilten mobilen Ansatz, bei dem der Zustand der Anwendung oft auf vielen Geräten gleichzeitig lebt und mühsam synchronisiert werden muss. Eine zentrale Quelle der Wahrheit bedeutet konsistente Daten, einfachere Logik und weniger Gelegenheiten für schwer auffindbare Fehler. Wenn Daten und Integrationen das Herz Ihres Produkts sind, gibt Ihnen die Web-Architektur eine Kontrolle darüber, die die verteilte mobile Welt ohne enormen Aufwand schlicht nicht bietet.
Signal 4: Skalierbarkeit und Sicherheit wiegen schwerer als Touch-Gesten
Das vierte Signal taucht überall dort auf, wo ein Produkt sensible Daten verarbeitet oder eine wachsende Zahl von Nutzern bedienen muss. In solchen Projekten entscheiden nicht flüssige Animationen oder effektvolle Touch-Gesten über den Erfolg, sondern die Frage, wie das System mit Sicherheit, Zugriffskontrolle und Last umgeht. Die Web-Architektur bietet hier Vorteile, die kaum zu überschätzen sind.
Beginnen wir mit der Zugriffskontrolle. In einer Web-Anwendung erfolgt die Verwaltung von Berechtigungen, Rollen und Audits zentral auf der Serverseite. Der Server entscheidet, wer worauf Zugriff hat, und der Server protokolliert, wer wann welche Operation ausgeführt hat. An einer Stelle können Sie einem ausgeschiedenen Mitarbeiter die Rechte entziehen, die Zugriffsrichtlinie für eine ganze Gruppe ändern oder die vollständige Änderungshistorie nachvollziehen. In einem Modell, in dem die Logik über Geräte verteilt ist, ist eine solche zentrale Hoheit über den Zugriff deutlich schwerer zu erreichen.
Der zweite große Vorteil? Das Schließen von Sicherheitslücken. Wenn Sie in einer Web-Anwendung eine Lücke entdecken, spielen Sie die Korrektur auf dem Server aus, und das Problem verschwindet im selben Moment für alle Nutzer. In der mobilen Welt muss die Korrektur durch den Store, und danach warten Sie, bis die Nutzer die App auf ihren Handys aktualisieren. Ein Teil von ihnen tut das wochenlang nicht und lässt die Tür offen. Aus Sicht der Sicherheit ist der Unterschied zwischen einem sofortigen Patch und einer vom Nutzer abhängigen Aktualisierung gewaltig.
Der dritte Aspekt ist die Skalierbarkeit. Das Backend einer Web-Anwendung entwerfen wir so, dass es horizontal skaliert werden kann, also durch das Hinzufügen weiterer Serverinstanzen, wenn Traffic und Kundenzahl wachsen. Steigt die Zahl der Nutzer, fügen Sie Rechenleistung hinzu, und die Architektur verteilt die Last darauf. Dieser Ansatz hat sich in unzähligen Produktivsystemen bewährt. Eine gut entworfene Web-Anwendung wächst mit Ihrem Geschäft, statt zum Flaschenhals zu werden.
Der vierte, oft unterschätzte Punkt ist die Kontrolle über sensible Daten. In einer Web-Architektur speichern Sie Daten zentral, in einer kontrollierten und abgesicherten Serverumgebung. Im mobilen Modell landet ein erheblicher Teil der Daten auf den Geräten der Nutzer, und jedes verlorene oder gestohlene Handy wird zu einem möglichen Datenleck. Je sensibler die Daten sind, die Sie verarbeiten, etwa medizinische, finanzielle oder personenbezogene, desto stärker spricht das dafür, sie an einem gut geschützten Ort zu halten, statt sie über Hunderte Geräte zu verstreuen.
Tipp: Erstellen Sie bei der Vorbereitung der Projektannahmen eine einfache Datenkarte. Halten Sie fest, welche Informationen das System speichern wird, welche davon sensibel sind und wer Zugriff darauf haben sollte. Wenn diese Karte schnell um personenbezogene, finanzielle oder vertrauliche Unternehmensdaten wächst, ist das ein deutliches Zeichen, dass Sie eine Architektur mit zentraler Zugriffskontrolle und Audit brauchen, also eine Weblösung mit starkem Backend und keine Anwendung, die diese Daten über die Handys von Mitarbeitern und Kunden verteilt.
Auf einen Satz gebracht: Wenn das Gespräch über Ihr Produkt häufiger auf Rollen, Audit, DSGVO-Konformität und Lastfestigkeit kommt als darauf, wie schön sich eine Karte mit dem Finger verschieben lässt, dann bauen Sie ein System, dessen natürliches Zuhause eine gut abgesicherte Web-Architektur ist. Sicherheit und Skalierbarkeit sind Fundamente, keine Zusätze. Und sie sollten die Entscheidung über die Plattform anführen.
Signal 5: Sie bauen ein MVP und müssen den Markt schnell prüfen
Das fünfte Signal richtet sich vor allem an Gründerinnen und Gründer von Start-ups sowie an Unternehmen, die neue Produktlinien starten. Wenn Ihr Ziel ist, möglichst schnell zu prüfen, ob die Idee überhaupt einen Markt hat, ist eine Web-Anwendung fast immer der richtige erste Schritt. Ein MVP, also ein Produkt mit minimal notwendigem Funktionsumfang, hat eine Aufgabe: die Geschäftshypothese mit möglichst geringem Zeit- und Geldaufwand zu prüfen. Das Web erfüllt dieses Ziel besser als jede andere Plattform.
Der größte Vorteil ist das Fehlen einer Einstiegshürde. Die Webversion stellen Sie Testern mit einem einfachen Link zur Verfügung. Sie verschicken den Link per E-Mail, fügen ihn in eine Nachricht ein, setzen ihn in eine Anzeige, und der Empfänger klickt und nutzt das Produkt bereits. Er muss die App nicht im Store suchen, herunterladen, Berechtigungen zustimmen oder ein Konto anlegen, nur um einen Blick darauf zu werfen. Jeder dieser Schritte siebt in der mobilen Welt einen Teil der potenziellen Tester aus, und Ihnen liegt in dieser frühen Phase daran, möglichst viele Beobachtungen zu sammeln.
Der zweite Vorteil ist Tempo und Kosten der Iteration. Die Prüfung einer Idee ist kein einmaliger Schuss, sondern eine Folge schneller Zyklen: Sie veröffentlichen eine Version, beobachten die Reaktionen, nehmen Änderungen vor, veröffentlichen erneut. Im Web-Modell dauert ein solcher Zyklus Stunden, weil die neue Version die Nutzer sofort nach der Auslieferung erreicht. Im mobilen Modell bleibt jede Iteration im Veröffentlichungsprozess des Stores stecken. Für ein Start-up, das gegen die Zeit und ein schrumpfendes Budget antritt, kann dieser Unterschied über das Überleben entscheiden.
Der dritte Nutzen ist die einfache Datenerhebung. In einer Web-Anwendung binden Sie problemlos Analysewerkzeuge, Heatmaps, Sitzungsaufzeichnungen und Feedback-Formulare ein. Alles geschieht in einer Umgebung, ohne dass Sie unterschiedliche Messsysteme für iOS und Android zusammenführen müssen. Sie erhalten ein stimmiges Bild davon, wie sich Nutzer durch das Produkt bewegen, wo sie sich verlieren und was sie anzieht. Diese Daten sind der Treibstoff für Entscheidungen über die weitere Entwicklung.
Hier kommt unsere häufigste Empfehlung für Kunden in der Ideenphase. Tipp: Beginnen Sie mit einer Web-Anwendung oder einer PWA und ergänzen Sie eine native mobile App erst dann, wenn die gesammelten Daten das eindeutig rechtfertigen. Mit anderen Worten: Lassen Sie das reale Nutzerverhalten und nicht eine Annahme aus dem Businessplan über die Investition in Mobilität entscheiden. Sollte sich zeigen, dass Ihre Zielgruppe das Produkt tatsächlich im Außeneinsatz nutzen würde, die Kamera oder die Ortung braucht, dann ist der Ausbau um eine mobile Schicht eine bewusste, durch Belege gestützte Entscheidung.
In der Praxis stellen viele unserer Kunden nach der Phase des Web-MVP fest, dass sie eine mobile Anwendung überhaupt nicht brauchen, weil das Produkt im Browser hervorragend funktioniert. Andere gehen den Schritt zur Mobilität, tun es aber mit vollem Wissen darüber, welche Funktionen die Nutzer erwarten. In beiden Fällen sparen sie Geld, weil sie nicht in eine teure native Lösung investiert haben, bevor irgendjemand bestätigt hat, dass sie nötig ist. Die vernünftige Reihenfolge, erst Web und dann eventuell Mobile, schützt das Budget und ordnet die Produktentwicklung.
Signal 6: Eine PWA deckt Ihren Bedarf an Mobilität ab
Das sechste Signal betrifft Zwischensituationen, in denen Sie ein wenig Mobilität brauchen, aber nicht unbedingt eine vollständige native Anwendung. Die Antwort ist hier oft eine Progressive Web App, kurz PWA. Das ist eine Technologie, die dafür sorgt, dass sich eine Web-Anwendung weitgehend wie eine auf dem Handy installierte App verhält und zugleich eine gewöhnliche, im Browser laufende Seite bleibt. Für viele Produkte ist das der goldene Mittelweg zwischen Kosten und Möglichkeiten.
Was bietet eine PWA konkret? Der Nutzer kann die Anwendung auf dem Startbildschirm des Handys ablegen und sie über ein Symbol starten, genau wie eine native App. Die Anwendung kann offline arbeiten und dabei zuvor gespeicherte Daten nutzen, wenn die Verbindung verschwindet. Sie kann außerdem Benachrichtigungen senden und den Nutzer so an sich erinnern. All das ohne Veröffentlichung in den Stores, ohne Prüfprozess und ohne eine eigene Codebasis für jedes System.
Die zweite Säule ist die Responsivität. Eine gut entworfene Web-Anwendung nutzt adaptive Layouts, die sich an die Bildschirmgröße anpassen. Dasselbe Produkt sieht auf dem Handy, auf dem Tablet und auf einem großen Monitor sinnvoll aus und funktioniert dort auch. Fachmaterialien zur Anwendungsarchitektur empfehlen ausdrücklich, Oberflächen so zu bauen, dass sie Konfigurationsänderungen wie das Drehen des Geräts oder das Ändern der Fenstergröße überstehen und den Zustand des Nutzers dabei bewahren. Ein responsives Layout ist heute Standard, kein Luxus.
Man muss aber ehrlich sagen, wo die Möglichkeiten einer PWA enden. Wenn Ihr Produkt tiefen Zugriff auf native Systemfunktionen benötigt, etwa fortgeschrittene Bildverarbeitung aus der Kamera, längere Arbeit im Hintergrund, Integration mit den Systemkontakten, Bluetooth Low Energy für spezialisierte Geräte oder die höchstmögliche Grafikleistung in Spielen, dann brauchen Sie tatsächlich eine native Anwendung. Eine PWA deckt die überwiegende Mehrheit typischer mobiler Anforderungen ab, aber nicht alle. Unsere Aufgabe als Dienstleister ist es, ehrlich zu beurteilen, auf welcher Seite dieser Grenze Ihr Produkt liegt.
Für mobile Produkte ist das Thema der Verfügbarkeit von Offline-Daten und ihrer Aktualität besonders wichtig. Bei Anwendungen, die im Außeneinsatz laufen, ist die Verbindung mitunter unzuverlässig, und der Nutzer sollte nicht vor einem leeren Bildschirm sitzen. Die Architekturdokumentation formuliert dieses Prinzip klar:
Speichern Sie so viele relevante und aktuelle Daten wie möglich. So können Nutzer die Funktionen der Anwendung auch dann verwenden, wenn ihr Gerät offline ist. Denken Sie daran, dass nicht alle Nutzer eine dauerhafte, schnelle Verbindung haben, und selbst wenn sie sie haben, kann der Empfang an belebten Orten schlecht sein.
Dieses Prinzip lässt sich in einer PWA wirksam umsetzen. Die Anwendung speichert die benötigten Daten lokal, funktioniert bei schwacher oder fehlender Verbindung und synchronisiert die Änderungen nach der Rückkehr des Netzes mit der zentralen Quelle der Wahrheit auf dem Server. Für viele Produkte, die Kunden zunächst als “unbedingt nötige mobile App” sehen, erweist sich die PWA als ausreichende Lösung, die in Umsetzung und Betrieb deutlich günstiger ist und dabei die wichtigsten Eigenschaften von Mobilität liefert. Bevor Sie sich für volle Nativität entscheiden, prüfen Sie, ob eine progressive Web-Anwendung nicht bereits alles abdeckt, was Sie wirklich brauchen.
Signal 7: Ihr Team und Ihr Budget tragen keine zwei getrennten Anwendungen
Das siebte Signal ist das bodenständigste und zugleich das in der Praxis am häufigsten entscheidende: die Ressourcen. Sie mögen den Ehrgeiz haben, native Anwendungen für iOS und Android zu bauen, doch die eigentliche Frage lautet, ob Ihr Team und Ihr Budget deren Betrieb über die nächsten Jahre tragen. Nach unserer Erfahrung ist es gerade die Phase des Betriebs und nicht die der ersten Einführung, die Unternehmen am häufigsten überfordert, die sich ohne kühle Kalkulation für volle Nativität entschieden haben.
Der Betrieb nativer Anwendungen bedeutet doppelte, oft dreifache Kosten. Jede neue Funktion muss getrennt für iOS und getrennt für Android entstehen, auf beiden Plattformen getestet und mit dem Backend synchronisiert werden. Sie brauchen Entwickler, die unterschiedliche Technologien beherrschen, getrennte Testzyklen und eine getrennte Behandlung von Fehlern, die für das jeweilige System spezifisch sind. Wo eine Web-Anwendung ein Team an einer Codebasis erfordert, vervielfacht das native Modell Arbeitsaufwand und Kosten.
Mit der Vielzahl an Plattformen verbindet sich das Risiko, dass die Funktionen auseinanderlaufen. Wenn iOS, Android und Backend parallel weiterentwickelt werden, entsteht leicht eine Situation, in der etwas auf einem System anders funktioniert als auf dem anderen, und die Unterschiede wachsen mit der Zeit. Es treten Fehler auf, die es nur auf einer Plattform gibt, Funktionen, die in einer App ausgeliefert und in der anderen vergessen wurden, Abweichungen in der Verarbeitung derselben Daten. Jede solche Unstimmigkeit kostet zusätzliche Zeit für Diagnose und Behebung, und für den Nutzer ist es eine frustrierende Erfahrung, die davon abhängt, welches Handy er besitzt.
Dazu kommen echte, harte Kosten, die allein mit der Präsenz in den Stores verbunden sind und die man in der Planungsphase leicht vergisst. Es lohnt sich, sie aufzuschreiben:
- Gebühren und Entwicklerkonten – jährliche Kosten für die Konten in den App-Stores.
- Zertifikate und Signaturen – Verwaltung der Zertifikate, Schlüssel und Profile, die für die Veröffentlichung nötig sind.
- Prüfprozess – Zeit und Arbeit für die Freigabe jeder einzelnen Version.
- Konformität mit den Plattformvorgaben – Anpassung der App an die sich ändernden Richtlinien von Apple und Google.
- Unterstützung älterer Systemversionen – Tests und Korrekturen für die verschiedenen im Einsatz befindlichen Versionen von iOS und Android.
Diese Kosten verschwinden nach dem Launch nicht. Sie kehren bei jedem Release und bei jeder Änderung der Store-Richtlinien zurück. Für ein kleines Team können sie mehr Energie verschlingen als die Produktentwicklung selbst. Eine Web-Anwendung beseitigt die meisten davon, weil sie weder den Prozessen der Stores noch deren Zertifizierungsanforderungen unterliegt.
Der Kern dieses Signals ist ein Grundsatz, den wir unseren Kunden immer wieder nennen: Stützen Sie die Entscheidung über die Plattform auf die realen Ressourcen Ihres Teams und nicht auf technologische Mode. Dass der Wettbewerb eine App im Store hat, heißt nicht, dass Sie eine brauchen. Wenn Sie wissen, dass das Produkt nach der Einführung von einem kleinen Team oder einem einzelnen externen Partner betreut wird, setzen Sie auf eine Architektur, die Sie realistisch tragen können. In den meisten Fällen ist das eine gut entworfene Web-Anwendung, eventuell um eine PWA erweitert, und nicht ein kostspieliges Paar getrennter nativer Apps, die mit der Zeit zum Klotz am Bein werden.
Fazit: Wie Sie bewusst zwischen Web und Mobile wählen
Wir sind sieben Signale durchgegangen, die in unserer Projektpraxis am häufigsten darauf hindeuten, dass ein digitales Produkt keine native Handy-App braucht. Bevor Sie eine Entscheidung im Wert von Zehntausenden Złoty treffen, nutzen Sie sie als konkrete Checkliste für Entscheider:
- Arbeitskontext – arbeiten die Nutzer stationär am Schreibtisch und nicht unterwegs mit dem Handy in der Hand?
- Tempo der Releases – brauchen Sie sofortige Aktualisierungen und eine einheitliche Version für alle?
- Rolle der Daten – sind Daten, Integrationen und Geschäftslogik das Herz des Produkts und nicht eine effektvolle Oberfläche?
- Sicherheit und Skalierung – wiegen zentrale Zugriffskontrolle, Audit und Skalierbarkeit schwerer als Touch-Gesten?
- Marktprüfung – bauen Sie ein MVP und müssen die Geschäftshypothese schnell und günstig prüfen?
- Umfang der Mobilität – deckt eine PWA mit Offline-Modus und Installation auf dem Startbildschirm Ihren Bedarf?
- Ressourcen des Teams – tragen Budget und Personal realistisch den Betrieb von zwei getrennten nativen Apps?
Je mehr Ja-Antworten, desto stärker das Signal, dass Ihre natürliche Wahl eine Web-Anwendung oder eine PWA ist und die Investition in native Mobilität besser bis zu dem Moment aufgeschoben wird, in dem die Daten sie eindeutig rechtfertigen. Das ist kein Argument gegen mobile Anwendungen als solche, sondern ein Aufruf zu einer bewussten, durch Praxis gestützten Entscheidung.
Wann sollten Sie trotz allem eine mobile Anwendung wählen?
Dann, wenn das Produkt wirklich im mobilen Kontext lebt und sich nicht sinnvoll aus dem Browser bedienen lässt. Wir sprechen von intensiver Nutzung der Kamera, präziser GPS-Ortung, Arbeit im Außeneinsatz ohne Computer, Integration mit Gerätesensoren, kontaktlosen Zahlungen oder anspruchsvoller Grafik. Wenn das das Fundament Ihrer Idee ist und keine Zugabe, ist eine native Anwendung die richtige Wahl. Die Frage, die Sie sich stellen müssen, lautet: Ist Mobilität das Wesen des Produkts oder nur ein nettes Extra, ohne das alles im Browser genauso gut funktioniert?
Wird eine PWA die native App vollständig ersetzen?
In den meisten typischen geschäftlichen Anwendungsfällen ja, aber nicht immer. Eine PWA kommt mit der Installation auf dem Startbildschirm, dem Offline-Modus, Benachrichtigungen und Responsivität hervorragend zurecht und deckt damit den Bedarf eines großen Teils der Produkte. Sie steht der Nativität dort nach, wo tiefer Zugriff auf die System-API, maximale Leistung oder spezialisierte Hardwarefunktionen nötig sind. Unsere Rolle als Dienstleister ist es, ehrlich zu beurteilen, auf welcher Seite dieser Grenze ein konkretes Projekt liegt, statt zu versprechen, dass eine Technologie alles löst.
Bei Web Systems beraten wir Kunden seit 2006 so, als müssten wir dieses Produkt über die kommenden Jahre selbst betreuen. Denn meistens ist es genau so. Wir verkaufen weder technologische Mode noch die teuerste verfügbare Lösung. Wir helfen, eine Architektur zu wählen, die zu den realen Anforderungen, zum Budget und zu den Möglichkeiten des Teams passt, und bauen sie dann: solide, mit Blick auf Daten, Sicherheit, Integrationen und Skalierung.
Wenn Sie vor der Entscheidung Web gegen Mobile stehen, ein MVP planen, eine Web-Anwendung, Integrationen mit B2B-Systemen, Prozessautomatisierung, Lösungen auf KI-Basis oder die Modernisierung eines bestehenden Systems brauchen, sprechen wir darüber. Nehmen Sie gerne Kontakt auf – gemeinsam analysieren wir Ihren Fall und schlagen eine Lösung vor, die sich wirklich behauptet, sowohl technisch als auch wirtschaftlich.
