{"id":29281,"date":"2024-05-23T06:00:00","date_gmt":"2024-05-23T05:00:00","guid":{"rendered":"https:\/\/www.web-systems.pl\/webanwendung-statt-mobiler-app-7-signale\/"},"modified":"2024-05-23T06:00:00","modified_gmt":"2024-05-23T05:00:00","slug":"webanwendung-statt-mobiler-app-7-signale","status":"publish","type":"post","link":"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/","title":{"rendered":"Webanwendung statt mobiler App? 7 Signale, dass sich Ihr digitales Produkt genau so entwickeln sollte"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Am Anfang vieler digitaler Projekte f\u00e4llt ein Satz, der wie eine fertige Spezifikation klingt: &#8220;Machen wir eine App&#8221;. Nur ist das keine Produktentscheidung. Das ist ein Reflex. Der Kunde sieht das Icon auf dem Handybildschirm schon vor sich, bevor irgendjemand ein reales Nutzungsszenario, die Zielgruppe oder die Art beschrieben hat, wie Menschen dieses Werkzeug tats\u00e4chlich einsetzen werden. Als Web Systems, ein <a href=\"https:\/\/www.web-systems.pl\/de\/softwareentwicklung\/\">Software House aus \u0141\u00f3d\u017a, das seit 2006 Software entwickelt<\/a>, sehen wir dieses Muster immer wieder. Das Projektteam bekommt eine fertige Annahme \u00fcber die Plattform, und erst danach stellt sich heraus, dass der Nutzer am Schreibtisch sitzt, an einem gro\u00dfen Bildschirm arbeitet und nie im Leben zum Smartphone greifen wird, um seine t\u00e4gliche Arbeit zu erledigen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Wahl zwischen einer Web-App und einer mobilen App folgt h\u00e4ufiger der Mode als einer Bedarfsanalyse. Eine mobile App wirkt modern, also landet sie automatisch im Briefing, wie eine Selbstverst\u00e4ndlichkeit. Dabei ist gerade die Webanwendung, nicht die mobile, in vielen F\u00e4llen der vern\u00fcnftigere, g\u00fcnstigere und besser skalierbare Startpunkt. Besonders bei B2B-Produkten, internen Systemen und L\u00f6sungen, die stark auf Daten und Integrationen aufbauen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In diesem Artikel zeigen wir sieben konkrete Signale, die in der Praxis darauf hindeuten, dass Ihr digitales Produkt als Webanwendung wachsen sollte. Das sind keine Allgemeinpl\u00e4tze aus Ratgebern. Das sind Beobachtungen aus realen Umsetzungen: Betriebspanels, Reporting-Systeme, Integrationen mit ERP und CRM sowie Prozessautomatisierung. Wenn Sie Ihr Projekt darin wiedererkennen, haben Sie einen guten Grund, die Entscheidung f\u00fcr eine native App bewusst aufzuschieben und mit einem Fundament zu beginnen, das sich leichter weiterentwickeln l\u00e4sst.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Spis tre\u015bci<\/p>\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Signal_1_Der_Nutzer_arbeitet_am_Schreibtisch_nicht_unterwegs\" >Signal 1: Der Nutzer arbeitet am Schreibtisch, nicht unterwegs<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Signal_2_Sie_muessen_Aenderungen_schnell_und_ohne_App-Stores_ausliefern\" >Signal 2: Sie m\u00fcssen \u00c4nderungen schnell und ohne App-Stores ausliefern<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Signal_3_Kosten_und_Zeit_%E2%80%93_zwei_native_Apps_bedeuten_zwei_Teams\" >Signal 3: Kosten und Zeit &#8211; zwei native Apps bedeuten zwei Teams<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Signal_4_Integrationen_APIs_und_Daten_sind_das_Herz_des_Produkts\" >Signal 4: Integrationen, APIs und Daten sind das Herz des Produkts<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Signal_5_Ihnen_sind_Skalierbarkeit_und_eine_einzige_Quelle_der_Wahrheit_wichtig\" >Signal 5: Ihnen sind Skalierbarkeit und eine einzige Quelle der Wahrheit wichtig<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Signal_6_Zugriff_von_jedem_Geraet_ohne_Installation\" >Signal 6: Zugriff von jedem Ger\u00e4t ohne Installation<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Signal_7_Wartung_und_Teamentwicklung_auf_lange_Sicht\" >Signal 7: Wartung und Teamentwicklung auf lange Sicht<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#FAQ_die_haeufigsten_Fragen_zur_Wahl_einer_Webanwendung\" >FAQ: die h\u00e4ufigsten Fragen zur Wahl einer Webanwendung<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Ersetzt_eine_Webanwendung_eine_mobile_App_vollstaendig\" >Ersetzt eine Webanwendung eine mobile App vollst\u00e4ndig?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Wann_lohnt_sich_der_Schritt_ins_Mobile_trotzdem\" >Wann lohnt sich der Schritt ins Mobile trotzdem?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Kann_man_mit_Web_anfangen_und_Mobile_spaeter_ergaenzen\" >Kann man mit Web anfangen und Mobile sp\u00e4ter erg\u00e4nzen?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/www.web-systems.pl\/de\/webanwendung-statt-mobiler-app-7-signale\/#Fazit_Web_oder_Mobile_%E2%80%93_wie_Sie_ohne_Risiko_entscheiden\" >Fazit: Web oder Mobile &#8211; wie Sie ohne Risiko entscheiden<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Signal_1_Der_Nutzer_arbeitet_am_Schreibtisch_nicht_unterwegs\"><\/span>Signal 1: Der Nutzer arbeitet am Schreibtisch, nicht unterwegs<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die erste Frage, die wir bei Web Systems bei jedem neuen Produkt stellen, klingt banal einfach: Wo und wie befindet sich der Nutzer physisch, wenn er das Werkzeug benutzt? Und genau die Antwort auf diese eine Frage entscheidet oft \u00fcber die gesamte Architektur. Wenn Ihre Zielgruppe am Schreibtisch arbeitet, Monitor, Tastatur und Maus vor sich hat und die Arbeitssitzungen sich \u00fcber Stunden ziehen, dann gestalten Sie f\u00fcr eine Desktop-Umgebung. Und nicht f\u00fcr einen Daumen, der im Bus \u00fcber den Bildschirm wischt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine mobile App bew\u00e4hrt sich dort, wo Mobilit\u00e4t z\u00e4hlt: eine schnelle Statusabfrage, eine Benachrichtigung, ein Code-Scan, Geolokalisierung, ein Foto im Au\u00dfendienst. Und die Arbeit mit Daten sieht v\u00f6llig anders aus. Lange Formulare, mehrspaltige Tabellen, Auswertungen, Filter, Export, Arbeit in mehreren Fenstern gleichzeitig &#8211; all das verlangt einen gro\u00dfen Bildschirm und pr\u00e4zise Eingabewerkzeuge. Der Versuch, ein umfangreiches Verwaltungspanel in einen Smartphone-Bildschirm zu quetschen, endet in Kompromissen, die sowohl den Nutzer als auch das entwickelnde Team frustrieren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Typische Beispiele, in denen die Desktop-Umgebung ohne Diskussion gewinnt, sind:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>B2B-Panels<\/strong> &#8211; Kundenportale, Bestellsysteme, Produktkonfiguratoren, in denen ein Partner Angebote durchsieht und Bestellungen vom Firmenrechner aus aufgibt.<\/li>\n<li><strong>Operative Systeme f\u00fcr Teams<\/strong> &#8211; Werkzeuge zur Steuerung von Projekten, Lager, Produktion oder Ticketbearbeitung, die Mitarbeiter den ganzen Tag nutzen.<\/li>\n<li><strong>Reporting- und Analysewerkzeuge<\/strong> &#8211; Dashboards mit Diagrammen, Pivot-Tabellen und mehreren Filterebenen, die niemand auf einem Vier-Zoll-Bildschirm auswertet.<\/li>\n<li><strong>Back-Office-Systeme<\/strong> &#8211; Rechnungsstellung, Personalwesen, Dokumentenbearbeitung, wo die schnelle Dateneingabe \u00fcber die Tastatur z\u00e4hlt.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Das Risiko, das wir am h\u00e4ufigsten sehen? Erzwungene Mobilit\u00e4t dort, wo sie niemand braucht. Der Kunde baut eine native App, weil &#8220;alle ein Handy haben&#8221;, und nach der Einf\u00fchrung zeigt sich, dass die eigentliche Arbeit ohnehin am Computer stattfindet. Weil sich dort einfach arbeiten l\u00e4sst. Das Ergebnis ist eine App, die im Unterhalt teuer ist und nur alle Jubeljahre benutzt wird. <strong>Tipp:<\/strong> Bevor Sie sich f\u00fcr eine Plattform entscheiden, f\u00fchren Sie kurze Gespr\u00e4che mit einigen echten Nutzern und fragen Sie nicht, was sie sich w\u00fcnschen, sondern wo und womit sie ihre Arbeit tats\u00e4chlich erledigen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn die Antwort lautet &#8220;am Schreibtisch, lange, mit einem Berg von Daten&#8221;, ist eine Webanwendung kein Kompromiss. Sie ist die passgenaue Abstimmung des Werkzeugs auf den Nutzungskontext. Eine responsive Oberfl\u00e4che deckt die Momente ab, in denen jemand kurz vom Handy aus etwas nachsehen muss, aber das Gewicht des Produkts liegt dort, wo es hingeh\u00f6rt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Signal_2_Sie_muessen_Aenderungen_schnell_und_ohne_App-Stores_ausliefern\"><\/span>Signal 2: Sie m\u00fcssen \u00c4nderungen schnell und ohne App-Stores ausliefern<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Das Tempo, in dem \u00c4nderungen ausgeliefert werden, ist einer der am meisten untersch\u00e4tzten Faktoren bei der Plattformwahl. In der Praxis entscheidet es dar\u00fcber, wie schnell ein Produkt lernt und reift. Eine Webanwendung erlaubt es, Korrekturen sofort zu ver\u00f6ffentlichen. Sie spielen eine neue Version auf den Server, und im selben Moment arbeiten alle Nutzer mit dem aktuellen Code. Keine Warteschlange. Kein Vermittler. Kein Warten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In der Welt nativer Apps ist das anders. Jede \u00c4nderung muss die Pr\u00fcfung im App Store und bei Google Play durchlaufen. Selbst wenn die Korrektur kritisch ist, warten Sie auf die Freigabe und hoffen anschlie\u00dfend, dass die Nutzer die App tats\u00e4chlich aktualisieren. Ein Teil von ihnen wird das nie tun. Von dort ist es ein kurzer Weg zur Fragmentierung der Versionen: Gleichzeitig kursieren mehrere Ausgaben Ihres Produkts auf dem Markt, jede mit einem anderen Satz an Fehlern und Funktionen. F\u00fcr ein Support-Team ist das ein diagnostischer Albtraum.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Aus architektonischer Sicht gibt Ihnen das Web eine Codebasis und eine einzige Quelle der Wahrheit dar\u00fcber, was der Nutzer sieht. Sie m\u00fcssen sich nicht sorgen, dass jemand eine ein halbes Jahr alte Version benutzt, denn diese Version existiert schlicht nicht. Das vereinfacht Wartung, Fehlersuche und Kommunikation mit dem Kunden radikal, weil alle immer auf demselben Stand sind, w\u00f6rtlich und im \u00fcbertragenen Sinn.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Am deutlichsten zeigt sich dieser Vorteil bei Projekten in der MVP-Phase, in der die Lerngeschwindigkeit z\u00e4hlt. Wenn Sie h\u00e4ufige Iterationen, das Testen von Hypothesen und Reaktionen auf R\u00fcckmeldungen der ersten Nutzer planen, verk\u00fcrzt das Web die Feedback-Schleife von Tagen auf Minuten. Sie ver\u00f6ffentlichen eine \u00c4nderung, beobachten das Verhalten, bessern nach, ver\u00f6ffentlichen erneut &#8211; und das alles am selben Tag.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Praxis zeigt, wie viel davon abh\u00e4ngt, Reibung in diesem Prozess zu minimieren. <strong>Tipp:<\/strong> Betrachten Sie bei einem Produkt in der Fr\u00fchphase jeden Tag Verz\u00f6gerung bei der Auslieferung einer Korrektur als verlorene Daten dar\u00fcber, was Nutzer wirklich brauchen. Das Web erlaubt \u00c4nderungen in einem Rhythmus, dem das Store-Modell schlicht nicht folgen kann.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das hei\u00dft nicht, dass die Pr\u00fcfung in den Stores an sich ein Nachteil w\u00e4re, sie hat ihre Berechtigung in der Sicherheit des mobilen \u00d6kosystems. Es geht um etwas anderes. In der Phase intensiver Produktentwicklung kostet Sie diese H\u00fcrde am meisten, genau dann, wenn Sie maximale Flexibilit\u00e4t brauchen. F\u00fcr viele Projekte ist das ein Argument, das allein den Ausschlag zugunsten einer Webanwendung gibt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Signal_3_Kosten_und_Zeit_%E2%80%93_zwei_native_Apps_bedeuten_zwei_Teams\"><\/span>Signal 3: Kosten und Zeit &#8211; zwei native Apps bedeuten zwei Teams<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Gespr\u00e4ch \u00fcber das Budget legt eine Wahrheit \u00fcber mobile Apps offen, die sich in der Ideenphase leicht \u00fcbersehen l\u00e4sst. Volle Pr\u00e4senz im Mobilbereich bedeutet in der Praxis zwei getrennte Entwicklungswege: iOS und Android. Zwei verschiedene Sprachen, zwei Werkzeugs\u00e4tze, zwei Oberfl\u00e4chenkonventionen und, in realen Projekten, oft zwei Teams oder zumindest der doppelte Arbeitsaufwand. Jede Funktion wird zweimal entworfen, programmiert, getestet und gepflegt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Und die Baukosten sind erst der Anfang. Die eigentlichen Ausgaben stecken im Unterhalt, nur ber\u00fccksichtigen Kunden sie bei der ersten Kalkulation selten. Es lohnt sich, sie von Anfang an vor Augen zu haben:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Tests auf vielen Ger\u00e4ten<\/strong> &#8211; der Android-Markt umfasst Hunderte Modelle mit unterschiedlichen Aufl\u00f6sungen, Bildschirmgr\u00f6\u00dfen und Systemversionen. Die Android-Dokumentation weist ausdr\u00fccklich darauf hin, dass Apps auf vielen Formfaktoren laufen: Telefonen, Tablets, faltbaren Ger\u00e4ten und Autobildschirmen. Jeder davon ist eine m\u00f6gliche Fehlerquelle.<\/li>\n<li><strong>Zertifikate und Entwicklerkonten<\/strong> &#8211; Geb\u00fchren f\u00fcr Store-Konten, Signaturzertifikate, Erneuerung von Schl\u00fcsseln. Laufende Kosten, v\u00f6llig unabh\u00e4ngig davon, ob die App weiterentwickelt wird.<\/li>\n<li><strong>Aktualisierungen f\u00fcr neue Systemversionen<\/strong> &#8211; Apple und Google ver\u00f6ffentlichen jedes Jahr neue Versionen und mit ihnen API-\u00c4nderungen, neue Anforderungen und die Abk\u00fcndigung alter L\u00f6sungen. Eine App, die niemand aktualisiert, f\u00e4ngt nach zwei Saisons an zu br\u00f6ckeln.<\/li>\n<li><strong>Einhaltung der Store-Richtlinien<\/strong> &#8211; die Regeln von App Store und Google Play \u00e4ndern sich und k\u00f6nnen den Umbau von Produktteilen erzwingen, die gestern noch einwandfrei funktioniert haben.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Eine Webanwendung streicht die meisten dieser Posten. Sie haben eine Codebasis, die auf jeder Plattform mit Browser l\u00e4uft, ohne Aufteilung in \u00d6kosysteme und ohne verdoppeltes Team. F\u00fcr ein MVP-Budget ist das der Unterschied zwischen einem Projekt, das sich finanzieren und am Markt pr\u00fcfen l\u00e4sst, und einem Projekt, das das Geld aufbraucht, bevor es \u00fcberhaupt die ersten Kunden erreicht.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei Web Systems empfehlen wir h\u00e4ufig ein schrittweises Vorgehen: Wir beginnen mit einer soliden Webanwendung, die das Gesch\u00e4ftsmodell best\u00e4tigt und die ersten Nutzer gewinnt, und erst wenn die Daten einen realen Bedarf an mobiler Pr\u00e4senz zeigen, gehen wir in eine native oder hybride App. Eine vern\u00fcnftige Reihenfolge. Sie sch\u00fctzt das Budget und erlaubt es, die n\u00e4chsten Entscheidungen auf Fakten statt auf Annahmen zu st\u00fctzen. Mobile l\u00e4sst sich in der zweiten Phase ohnehin deutlich sicherer bauen, weil Sie dann genau wissen, welche Funktionen wirklich genutzt werden und den Weg aufs Telefon wert sind.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Signal_4_Integrationen_APIs_und_Daten_sind_das_Herz_des_Produkts\"><\/span>Signal 4: Integrationen, APIs und Daten sind das Herz des Produkts<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Es gibt eine ganze Kategorie von Produkten, in denen die Oberfl\u00e4che nur die Spitze des Eisbergs ist und der wahre Wert im Datenfluss steckt. Die Rede ist von Systemen, deren Kern B2B-Integrationen, Automatisierungen und der Informationsaustausch zwischen verschiedenen Plattformen sind. Wenn Ihr Produkt Systeme verbindet, Daten synchronisiert und Prozesse orchestriert, dann ist das Web seine nat\u00fcrliche Umgebung. Nicht eine von mehreren m\u00f6glichen Optionen, sondern die nat\u00fcrliche.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine Webanwendung lebt auf dem Server, nah an den anderen Systemen, mit denen sie sprechen muss. Verbindungen zu ERP, CRM, Zahlungs-Gateways, Data Warehouses oder externen APIs werden dort direkt hergestellt, ohne den Umweg \u00fcber das Ger\u00e4t des Nutzers. Die Integrationslogik l\u00e4uft in einer kontrollierten Umgebung, mit Zugriff auf sichere Zugangsdaten, eine stabile Verbindung und die volle Rechenleistung. Im mobilen Modell brauchen dieselben Integrationen in der Regel eine Zwischenschicht, also ohnehin ein Web-Backend &#8211; was nur best\u00e4tigt, wo das Herz des Produkts wirklich schl\u00e4gt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die zweite S\u00e4ule ist die Sicherheit. Wenn Logik und sensible Daten auf der Serverseite bleiben, gewinnen Sie eine zentrale Zugriffskontrolle und eine kleinere Angriffsfl\u00e4che. Schl\u00fcssel zu externen Systemen landen nicht auf Endger\u00e4ten, Zugriffsregeln setzen Sie an einer Stelle durch, und der Entzug von Berechtigungen wirkt sofort. In einer nativen App wandert ein Teil der Logik und der Daten unweigerlich auf das Telefon, was den Bereich vergr\u00f6\u00dfert, den Sie absichern und \u00fcberwachen m\u00fcssen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Aus unseren Umsetzungen ergibt sich ein einfacher Zusammenhang: Je mehr Integrationen ein Produkt enth\u00e4lt und je sensibler die Daten sind, die durch es flie\u00dfen, desto st\u00e4rker spricht das f\u00fcr eine Architektur rund um ein Web-Backend. Das Telefon wird dann h\u00f6chstens zu einem von mehreren Zugangskan\u00e4len, nicht zu dem Ort, an dem die eigentliche Arbeit stattfindet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tipp:<\/strong> Wenn in der Produktspezifikation das Wort &#8220;Integration&#8221; h\u00e4ufiger vorkommt als die Beschreibung der Nutzeroberfl\u00e4chen, bauen Sie wahrscheinlich ein Datensystem und keine mobile App &#8211; und genau das Web gibt Ihnen die vollst\u00e4ndigste Kontrolle dar\u00fcber.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Solche Produkte gewinnen auch an Beobachtbarkeit. Da die Logik zentral l\u00e4uft, haben Sie Logs, Metriken und die Ereignishistorie an einer Stelle, was die Diagnose von Integrationsproblemen unsch\u00e4tzbar erleichtert. W\u00fcrde man diese Logik \u00fcber mobile Clients verteilen, w\u00fcrde jeder Fehler zu einer Ermittlung auf vielen Ger\u00e4ten gleichzeitig.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Signal_5_Ihnen_sind_Skalierbarkeit_und_eine_einzige_Quelle_der_Wahrheit_wichtig\"><\/span>Signal 5: Ihnen sind Skalierbarkeit und eine einzige Quelle der Wahrheit wichtig<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Gute Architektur ist kein Luxus f\u00fcr gro\u00dfe Systeme. Sie ist die Voraussetzung f\u00fcr die ruhige Entwicklung jedes ernsthaften Produkts. Die Regel ist einfach: Die Gesch\u00e4ftslogik sollte an einer Stelle wohnen und nicht \u00fcber viele Clients verstreut sein. Wenn Sie die Regeln des Produkts im Backend halten, nutzt jeder Kanal &#8211; Web, Mobile, \u00f6ffentliches API &#8211; exakt dieselbe, konsistente Logik. Genau das ist die einzige Quelle der Wahrheit, die Ihnen ganze Fehlerklassen erspart, die durch das Auseinanderdriften der Plattformen entstehen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Dokumentation zur App-Architektur bringt diesen Gedanken sehr deutlich auf den Punkt, und wir unterschreiben ihn nach Jahren der Praxis:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">The most important principle is separation of concerns: separating your app into methods, classes, files, packages, modules and layers that have clearly defined responsibilities and boundaries.<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">Die Trennung der Schichten und klar gezogene Verantwortungsgrenzen sorgen daf\u00fcr, dass sich ein Produkt leichter weiterentwickeln und debuggen l\u00e4sst. Wenn jeder Teil des Systems seinen Platz und seine Aufgabe hat, bedeutet eine neue Funktion nicht, in Dutzenden zusammenhangloser Dateien zu w\u00fchlen. Dieselbe Dokumentation erkl\u00e4rt genau, warum eine einzige Quelle der Wahrheit so wichtig ist:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">When a new data type is defined in your app, assign a single source of truth (SSOT) to it. The SSOT is the owner of that data, and only the SSOT can modify or mutate it.<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">Die Vorteile sind greifbar. Alle \u00c4nderungen an einem Datentyp geschehen an einer Stelle, die Daten sind vor versehentlicher Ver\u00e4nderung von au\u00dfen gesch\u00fctzt, und jede \u00c4nderung l\u00e4sst sich leichter nachvollziehen &#8211; Fehler kommen also schneller ans Licht. In der Praxis: weniger \u00dcberraschungen in der Produktion und k\u00fcrzere Reparaturzeiten, wenn doch etwas schiefgeht.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Skalierbarkeit ist die andere Seite derselben Regel. Eine Schichtenarchitektur erlaubt es, das Produkt ohne wachsendes Chaos auszubauen. Sie k\u00f6nnen neue Zugangskan\u00e4le erg\u00e4nzen, mehr Verkehr verkraften, weitere Entwickler ins Projekt holen, und das Fundament steht wie zuvor. Die Architekturdokumentation fasst es unmissverst\u00e4ndlich zusammen:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">Lets the app scale. More people and more teams can contribute to the same codebase with minimal code conflicts.<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tipp:<\/strong> Halten Sie die Gesch\u00e4ftsregeln im Backend und behandeln Sie jeden Client &#8211; Browser, mobile App, Integration &#8211; als d\u00fcnne Pr\u00e4sentationsschicht \u00fcber einem gemeinsamen Kern. So schreiben Sie die Logik nicht neu, wenn k\u00fcnftig eine mobile App dazukommt, sondern schlie\u00dfen nur einen neuen Kanal an einen fertigen, erprobten Motor an. Eine Webanwendung mit gut entworfenem Backend ist keine Sackgasse. Sie ist ein Fundament, auf dem sich weitere Schichten in Ruhe aufbauen lassen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Signal_6_Zugriff_von_jedem_Geraet_ohne_Installation\"><\/span>Signal 6: Zugriff von jedem Ger\u00e4t ohne Installation<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die Einstiegsh\u00fcrde entscheidet dar\u00fcber, wie viele Menschen Ihr Produkt \u00fcberhaupt ausprobieren &#8211; und eine Webanwendung senkt sie auf ein Minimum. Ein Link gen\u00fcgt. Kunde, Partner oder neuer Mitarbeiter klickt und arbeitet bereits, ohne Download, ohne Konto im Store, ohne die Pr\u00fcfung, ob das Ger\u00e4t unterst\u00fctzt wird. Im B2B-Kontext kann dieser Unterschied entscheidend sein: Es ist einfacher, einem Gesch\u00e4ftspartner eine URL zu schicken, als seine IT-Abteilung von der Installation einer weiteren App auf den Firmenhandys zu \u00fcberzeugen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Installation einer nativen App ist echte Reibung. Jeder zus\u00e4tzliche Schritt zwischen dem ersten Interesse und der ersten Nutzung kostet eine Gruppe von Menschen, die unterwegs abspringt. Der Zwang, den Store zu \u00f6ffnen, den richtigen Eintrag zu finden, mehrere Dutzend Megabyte zu laden und Berechtigungen zu erteilen, siebt einen Teil der potenziellen Nutzer wirksam aus. Vor allem bei Werkzeugen, die nur gelegentlich genutzt oder in gr\u00f6\u00dferen Organisationen eingef\u00fchrt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr Projekte, die einen Teil des mobilen Erlebnisses ohne den Bau einer separaten nativen App wollen, ist eine Progressive Web App oft ein guter Kompromiss. Eine PWA erlaubt es, das Produkt zum Startbildschirm des Telefons hinzuzuf\u00fcgen, teilweise offline zu arbeiten, Benachrichtigungen zu senden oder ausgew\u00e4hlte Ger\u00e4tefunktionen zu nutzen &#8211; und das alles auf Basis derselben Webanwendung, die Sie ohnehin entwickeln. Sie ersetzt eine native App nicht in jedem Szenario, schlie\u00dft aber in vielen F\u00e4llen die L\u00fccke zwischen Web und Mobile so gut, dass eine eigene App \u00fcberfl\u00fcssig wird.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Responsives Web ersetzt eine mobile App \u00fcberall dort wirklich, wo der Nutzer Zugriff auf Informationen und einfache Aktionen braucht und nicht auf fortgeschrittene Hardwarefunktionen des Telefons. Den Bestellstatus pr\u00fcfen, ein Dokument freigeben, einen Bericht ansehen, Daten schnell bearbeiten &#8211; all das funktioniert im Handybrowser hervorragend, ohne ein paralleles mobiles Produkt zu pflegen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Und die Universalit\u00e4t sollte man nicht vergessen. Eine Webanwendung \u00f6ffnet sich am B\u00fcrorechner genauso wie auf dem Tablet im Meeting und auf dem Telefon unterwegs. Ein Produkt bedient all diese Kontexte, und der Nutzer fragt sich nicht, ob er auf dem jeweiligen Ger\u00e4t die passende Version hat. Diese Zugriffsfreiheit ist besonders wertvoll bei Werkzeugen, die Teams und externe Partner gemeinsam nutzen, wo Sie nie im Voraus wissen, womit die jeweilige Person gerade arbeitet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Signal_7_Wartung_und_Teamentwicklung_auf_lange_Sicht\"><\/span>Signal 7: Wartung und Teamentwicklung auf lange Sicht<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein digitales Produkt endet nicht am Tag der Einf\u00fchrung. Da f\u00e4ngt es erst an, und die Kosten seines Lebens rechnet man in Jahren. Deshalb lohnt es sich, bei der Plattformwahl nicht an die erste Version zu denken, sondern an den gesamten Horizont von Wartung und Weiterentwicklung. Und in dieser Dimension hat eine Webanwendung einen klaren Vorsprung, weil sie meist auf einem einzigen, stimmigen Technologiepaket beruht.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine Technologie bedeutet einfachere Wartung. Es ist leichter, neue Entwickler zu finden und einzuarbeiten, leichter, das Projekt zwischen Teams zu \u00fcbergeben, leichter, Kontinuit\u00e4t zu sichern, wenn jemand geht oder dazukommt. Gute Architektur verst\u00e4rkt diesen Effekt, was auch die technische Dokumentation best\u00e4tigt, die darauf hinweist, dass Konsistenz im Projekt die Einarbeitungszeit neuer Teammitglieder verk\u00fcrzt und ihre Effektivit\u00e4t erh\u00f6ht. Im mobilen Modell mit getrennten Wegen f\u00fcr iOS und Android brauchen Sie Kompetenz in zwei verschiedenen Welten, und das ist bei begrenztem Team manchmal nicht zu stemmen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein typischer Fehler, den wir sehen, ist der Bau einer mobilen App ohne Plan f\u00fcr Jahre der Aktualisierungen. Der Kunde finanziert die Entstehung des Produkts, sieht aber kein Budget f\u00fcr die j\u00e4hrliche Anpassung an neue Systemversionen, API-\u00c4nderungen und Store-Richtlinien vor. Nach zwei, drei Saisons arbeitet die App schlechter, verschwindet von den Listen kompatibler Ger\u00e4te, und die Kosten ihrer Wiederbelebung sind mitunter mit einem Neubau vergleichbar. Auch das Web ist von der Notwendigkeit der Aktualisierung nicht frei, aber sein Wartungszyklus ist deutlich milder und besser vorhersehbar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Wartungsentscheidung l\u00e4uft also auf technische Schulden hinaus. Je kleiner das Team und je l\u00e4nger die geplante Lebensdauer des Produkts, desto st\u00e4rker senkt das Web das Risiko, dass das Werkzeug unwartbar wird. Eine Codebasis, ein Kompetenzprofil und ein vorhersehbarer Aktualisierungsrhythmus &#8211; das ist ein Fundament, das ruhig schlafen l\u00e4sst, auch wenn das Team klein ist und das Produkt Jahre leben soll.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Architekturdokumentation trifft den Kern dieser Investition in Codequalit\u00e4t genau:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">Improves the maintainability, quality, and robustness of the overall app.<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">Das ist kein \u00e4sthetisches Argument. Das ist eine rein wirtschaftliche Rechnung. Jede Stunde, die bei Wartung und Einarbeitung gespart wird, ist eine Stunde, die in Funktionen flie\u00dfen kann, die den Wert des Produkts wirklich steigern. Auf lange Sicht entscheidet gerade die Wartung und nicht die erste Version dar\u00fcber, ob sich das Projekt \u00fcberhaupt gelohnt hat.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"FAQ_die_haeufigsten_Fragen_zur_Wahl_einer_Webanwendung\"><\/span>FAQ: die h\u00e4ufigsten Fragen zur Wahl einer Webanwendung<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die Plattformentscheidung weckt immer wieder dieselben Zweifel. Nachfolgend beantworten wir die drei Fragen, die wir von Kunden in der Planungsphase am h\u00e4ufigsten h\u00f6ren.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Ersetzt_eine_Webanwendung_eine_mobile_App_vollstaendig\"><\/span>Ersetzt eine Webanwendung eine mobile App vollst\u00e4ndig?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In vielen F\u00e4llen ja, aber nicht in jedem. Wenn Ihr Produkt auf Arbeit mit Daten, Integrationen und Zugriff von verschiedenen Ger\u00e4ten beruht, deckt eine gut entworfene Webanwendung, unterst\u00fctzt durch PWA-Technologie, die \u00fcberwiegende Mehrheit der Bed\u00fcrfnisse ab, einschlie\u00dflich eines Teils der Funktionen, die man mit Mobile verbindet. Die Grenze verl\u00e4uft dort, wo fortgeschrittene Hardwarefunktionen des Telefons, intensive Offline-Arbeit oder ein fl\u00fcssiger Betrieb mit der vollen Leistung des Ger\u00e4ts entscheidend sind. Dann hat eine native App die Nase vorn. F\u00fcr ein typisches B2B-System, ein Panel oder ein operatives Werkzeug reicht das Web in der Regel vollkommen aus.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Wann_lohnt_sich_der_Schritt_ins_Mobile_trotzdem\"><\/span>Wann lohnt sich der Schritt ins Mobile trotzdem?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Eine native App ergibt Sinn, wenn das Produkt wirklich in Bewegung lebt und stark auf die M\u00f6glichkeiten des Telefons setzt: pr\u00e4zise Geolokalisierung, Kamera, Sensoren, Push-Benachrichtigungen als Kern des Erlebnisses, Offline-Arbeit im Au\u00dfendienst oder fl\u00fcssige, aufwendige Grafik. Der Schritt lohnt sich auch dann, wenn die Pr\u00e4senz in den Stores Teil des Vertriebsmodells ist oder wenn die Daten klar zeigen, dass Nutzer eine eigene App wollen und brauchen. Das Schl\u00fcsselwort lautet &#8220;Daten&#8221;: Die Entscheidung f\u00fcr Mobile trifft man am besten auf Basis des realen Nutzerverhaltens und nicht auf Basis von Annahmen aus dem Projektstart.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Kann_man_mit_Web_anfangen_und_Mobile_spaeter_ergaenzen\"><\/span>Kann man mit Web anfangen und Mobile sp\u00e4ter erg\u00e4nzen?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, und genau dieses Vorgehen empfehlen wir am h\u00e4ufigsten. Wenn Sie die Gesch\u00e4ftslogik im Backend halten und die Webanwendung als ersten Zugangskanal zu einem gemeinsamen Kern betrachten, wird das Hinzuf\u00fcgen einer mobilen App in der n\u00e4chsten Phase zu einem Ausbau und nicht zu einer kompletten Neuentwicklung. Sie beginnen mit Web, best\u00e4tigen das Gesch\u00e4ftsmodell, sammeln Daten \u00fcber die reale Nutzung und investieren dann bewusst in Mobile, wo es einen belegten Wert hat. Eine vern\u00fcnftige und sichere Reihenfolge, die das Budget sch\u00fctzt und Entscheidungen auf Fakten st\u00fctzt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Fazit_Web_oder_Mobile_%E2%80%93_wie_Sie_ohne_Risiko_entscheiden\"><\/span>Fazit: Web oder Mobile &#8211; wie Sie ohne Risiko entscheiden<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die Wahl zwischen Webanwendung und mobiler App ist eine technisch-gesch\u00e4ftliche und keine \u00e4sthetische Entscheidung. Es geht nicht darum, was in der Pr\u00e4sentation f\u00fcr die Gesch\u00e4ftsf\u00fchrung moderner aussieht, sondern darum, was am besten zum realen Nutzungsszenario, zum Budget und zu den Entwicklungspl\u00e4nen passt. Bevor Sie sich auf eine Richtung festlegen, gehen Sie eine einfache Checkliste auf Basis der sieben Signale aus diesem Artikel durch.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Nutzungskontext<\/strong> &#8211; arbeitet der Nutzer am Schreibtisch, lange und mit Daten, oder eher unterwegs, indem er kurz zum Telefon greift?<\/li>\n<li><strong>\u00c4nderungstempo<\/strong> &#8211; m\u00fcssen Sie Korrekturen sofort ausliefern, ohne die Warteschlange der Store-Pr\u00fcfung?<\/li>\n<li><strong>Budget und Zeit<\/strong> &#8211; k\u00f6nnen Sie sich zwei native Wege leisten, oder ist es vern\u00fcnftiger, mit einer Codebasis zu starten?<\/li>\n<li><strong>Integrationen und Daten<\/strong> &#8211; sind die Verbindungen zu anderen Systemen und der Datenfluss das Herz des Produkts?<\/li>\n<li><strong>Skalierbarkeit<\/strong> &#8211; ist Ihnen eine einzige Quelle der Wahrheit und Gesch\u00e4ftslogik an einer Stelle wichtig?<\/li>\n<li><strong>Zug\u00e4nglichkeit<\/strong> &#8211; haben eine niedrige Einstiegsh\u00fcrde, der Zugriff \u00fcber einen Link und die Arbeit von jedem Ger\u00e4t f\u00fcr Sie Bedeutung?<\/li>\n<li><strong>Wartung<\/strong> &#8211; denken Sie beim Produkt in einem Horizont von Jahren, bei begrenztem Team?<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn die meisten Antworten auf Web zeigen, haben Sie einen starken, sachlichen Grund, den Kern des Produkts genau dort anzusiedeln &#8211; und die Entscheidung \u00fcber Mobile in Ruhe zu vertagen, bis die Daten sie rechtfertigen. Dieses Vorgehen minimiert das Risiko, sch\u00fctzt das Budget und schafft ein Fundament, das sich leicht in weitere Richtungen ausbauen l\u00e4sst.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei Web Systems entwerfen und realisieren wir seit 2006 Webanwendungen, B2B-Systeme und Integrationen, wir haben also Dutzende Male geholfen, solche Entscheidungen zu treffen, in sehr unterschiedlichen Branchen. Wenn Sie vor der Plattformwahl f\u00fcr Ihr Produkt stehen, ein MVP planen, Integrationen mit APIs, Prozessautomatisierung, KI-L\u00f6sungen oder die Modernisierung eines bestehenden Systems brauchen, <strong>nehmen Sie Kontakt mit uns auf<\/strong>. Gemeinsam analysieren wir Ihr Nutzungsszenario und schlagen eine Architektur vor, die nicht nur heute Sinn ergibt, sondern auch in einigen Jahren.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Am Anfang vieler digitaler Projekte f\u00e4llt ein Satz, der wie eine fertige Spezifikation klingt: &#8220;Machen wir eine App&#8221;. Nur ist das keine Produktentscheidung. Das ist ein Reflex. Der Kunde sieht das Icon auf dem Handybildschirm schon vor sich, bevor irgendjemand ein reales Nutzungsszenario, die Zielgruppe oder die Art beschrieben hat, wie Menschen dieses Werkzeug tats\u00e4chlich [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":28382,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[817,827,807],"tags":[888,1090,1556,1113,1133,859,866],"class_list":["post-29281","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-anwendungen","category-technologien","category-webentwicklung","tag-b2b-de","tag-digitales-produkt","tag-mobile-app-de","tag-softwareentwicklung","tag-softwarehaus","tag-web-anwendung","tag-web-anwendungen"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/posts\/29281","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/comments?post=29281"}],"version-history":[{"count":0,"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/posts\/29281\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/media\/28382"}],"wp:attachment":[{"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/media?parent=29281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/categories?post=29281"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.web-systems.pl\/de\/wp-json\/wp\/v2\/tags?post=29281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}