Lerne, wie du ein Backend für Web- und Mobile-Apps mit einem gemeinsamen Datenmodell, gemeinsamen Regeln und UI-Entscheidungen entwirfst, die Büro- und Feldteams passen.
Zwei Apps können mit dem gleichen Ziel starten und trotzdem anfangen, sich wie unterschiedliche Systeme zu verhalten. Das Büroteam braucht eine klare Admin-Web-App. Das Feldteam braucht eine schnelle Mobile-App. Beide arbeiten mit denselben Aufträgen, Kunden, Formularen und Statusmeldungen, aber jede App wird von unterschiedlichen täglichen Abläufen geprägt.
Hier beginnt die Spaltung. Büro-Mitarbeiter planen und vergeben Arbeit, während Außendienst-Mitarbeiter vor Ort aktualisieren. Wenn beide Teams dieselben Datensätze anfassen, die Apps sie aber unterschiedlich behandeln, zeigen sich schnell Probleme. Ein Job, der im Web als "assigned" markiert ist, kann auf dem Mobilgerät als "ready" betrachtet werden. Eine Notiz, die in einer App Pflicht ist, ist in der anderen optional. Bald erzählt der Datensatz keine klare Geschichte mehr.
Die Hauptursache ist duplizierte Logik. Wenn Geschäftsregeln in beiden Apps eingebaut sind, werden kleine Unterschiede zu echten Konflikten. Ein Bildschirm erlaubt es einem Techniker, eine Aufgabe ohne Fotos zu schließen. Ein anderer blockiert die Abrechnung, bis Fotos hinzugefügt wurden. Nun sagt der Status, die Arbeit sei fertig, aber die Daten sind unvollständig.
Auch Begriffe drifteten auseinander. Ein Team sagt „Besuch abgeschlossen“. Ein anderes sagt „Auftrag erledigt“. Ein Manager sagt „geschlossen“. Diese Begriffe klingen im Gespräch ähnlich, aber in der Software werden sie zu separaten Schritten, Filtern und Berichten. Die Verwirrung wächst mit der Zeit, besonders wenn neue Teammitglieder den Prozess von dem Bildschirm lernen, der ihnen gerade gegenübersteht.
Selbst kleine Änderungen vergrößern die Lücke. Ein neuer Freigabeschritt, eine erforderliche Unterschrift oder ein zusätzliches Kundenfeld klingt unbedeutend. Wenn die Änderung aber an zwei Stellen neu gebaut werden muss, wird eine App meist zuerst aktualisiert und die andere holt später nach. Diese Verzögerung verursacht Nacharbeit, Supportfälle und schlechte Daten.
Deshalb ist ein gemeinsames Backend wichtig. Wenn Admin-Web-App und Feld-Mobile-App zwar Datensätze teilen, aber nicht die Regeln, spaltet sich das System langsam in zwei Teile.
Bevor du über Bildschirme nachdenkst, schreibe den realen Prozess von Anfang bis Ende auf. Beginne im Moment der Anfrageerstellung und ende, wenn der Auftrag geschlossen, freigegeben oder abgerechnet wird. Das gibt beiden Apps dieselbe Skelettstruktur.
Ein häufiger Fehler ist, die Admin-Web-App und die Feld-Mobile-App als zwei getrennte Produkte zu planen. Das erzeugt meist zwei Versionen desselben Prozesses, zwei Bedeutungen für denselben Status und später zusätzliche manuelle Korrekturen. Der Workflow muss zuerst kommen.
Verwende einfache Sprache. Zum Beispiel: Anfrage erstellt, zugewiesen, akzeptiert, in Arbeit, pausiert, abgeschlossen, überprüft. Schau dann jeden Schritt an und frage, wer ihn bearbeitet. Manche Schritte gehören zu beiden Rollen. Ein Büro-Mitarbeiter weist die Arbeit zu, während der Außendienstmitarbeiter sie auf dem Mobilgerät annimmt. Beides ist Teil eines Workflows, nicht zweier verschiedener.
Die einfachste Methode ist, geteilte Aktionen von gerätespezifischen Aktionen zu trennen.
Geteilte Aktionen sind Dinge wie eine Anfrage erstellen, einen Mitarbeiter zuweisen, den Status aktualisieren, Notizen hinzufügen und einen Auftrag schließen. Web-spezifische Aktionen umfassen meist das Überprüfen von Warteschlangen, das Neuvergeben von Arbeit, das Genehmigen von Abschlüssen und das Erstellen von Berichten. Mobile-spezifische Aktionen sind oft das Annehmen einer Aufgabe, das Hochladen von Fotos, das Erfassen einer Unterschrift und das Markieren der Ankunft.
Das hilft zu erkennen, wo sich die Apps unterscheiden sollten und wo nicht. Die Web-App kann mehr Filter und Admin-Kontrollen zeigen. Die Mobile-App kann größere Buttons und weniger Wahlmöglichkeiten nutzen. Aber Statuslogik, Validierung und Geschäftsregeln sollten an einem Ort bleiben.
Wähle früh eine einzige Vertrauensquelle für Statusänderungen. Wenn ein Auftrag erst auf "Completed" gesetzt werden darf, nachdem Fotos und eine Kundenunterschrift hinzugefügt wurden, sollte diese Regel im Backend leben. Sie darf nicht nur auf dem Mobilbildschirm oder nur im Admin-Panel existieren.
Ein einfacher Test hilft: Führt dieselbe Aktion in beiden Apps zum identischen Ergebnis? Wenn ja, ist euer Workflow geteilt. Wenn nicht, stecken Geschäftsregeln wahrscheinlich in der Oberfläche.
Beginne mit den Datensätzen, über die sich beide Apps einig sein müssen. Fang nicht mit Bildschirmen an. Fang mit den realen Dingen an, die dein Geschäft täglich nachverfolgt: Kunden, Standorte, Aufträge, Mitarbeiter, Bestand, Rechnungen oder Inspektionen. Wenn sowohl die Admin-Web-App als auch die Feld-Mobile-App denselben Auftrag bearbeiten, sollte dieser Auftrag als ein Datensatz in einem gemeinsamen Datenmodell existieren.
Ein nützlicher Test ist die Frage: „Könnten diese beiden Apps über die Wahrheit uneinig sein?“ Wenn die Antwort ja ist, ist das Modell an der falschen Stelle geteilt. Das Backend sollte die einzige Quelle der Wahrheit halten.
Bei jedem Kern-Datensatz sollten die geteilten Felder zusammenbleiben. Ein Arbeitsauftrag könnte eine ID, Status, Kunde, Standort, zugewiesener Mitarbeiter, geplantes Datum, Abschlussdatum, Notizen, Anhänge und Fotos enthalten.
Diese Felder sind für beide Erfahrungen wichtig, auch wenn sie unterschiedlich angezeigt werden. Das Admin-Team kann Zeitpläne bearbeiten und Mitarbeiter über ein Web-Dashboard zuweisen. Das Feldteam kann vielleicht nur den Zeitplan ansehen, Fotos hochladen und den Auftrag als erledigt markieren. Es ist trotzdem derselbe Datensatz, nur mit unterschiedlichen Berechtigungen.
Füge rollen-spezifische Felder nur hinzu, wenn es einen echten Bedarf gibt. Wenn Disponenten eine interne Prioritätsbewertung brauchen, kann diese auf demselben Arbeitsauftrag liegen und für Feldnutzer verborgen bleiben. Wenn Mobile-Mitarbeiter ein Offline-Sync-Flag oder Geräte-Metadaten benötigen, füge es vorsichtig hinzu, ohne die Hauptbedeutung des Datensatzes zu verändern.
Vergiss nicht die Support-Felder, die Apps im echten Betrieb brauchbar machen. Eigentumsfelder zeigen, wer einen Datensatz erstellt hat, wem er gehört oder wer ihm zugewiesen ist. Zeitstempel zeigen, wann er erstellt, aktualisiert, begonnen oder abgeschlossen wurde. Dateien und Bilder liefern Arbeitsnachweise. Notizen helfen Menschen, Ausnahmen zu erklären, ohne die Hauptdaten zu verändern.
Wenn du AppMaster nutzt, bedeutet das meist, zuerst gemeinsame Entities zu modellieren und dann unterschiedliche UI- und Zugriffsregeln in Web- und Mobile-Apps anzuwenden. So bleibt die Logik im Backend zentriert, statt über zwei Oberflächen verteilt zu werden.
Wenn die Admin-Web-App und die Feld-Mobile-App jeweils selbst entscheiden, was erlaubt ist, driften sie fast sofort auseinander. Ein Bildschirm akzeptiert einen Wert, den der andere ablehnt, oder eine App setzt einen Auftrag auf "completed", während die andere ihn noch als "in progress" sieht.
Die Lösung ist einfach: Lege Geschäftsregeln im Backend ab, und lasse beide Apps dieselbe Logik aufrufen.
Validierungsregeln gehören an einen Ort. Wenn ein Arbeitsauftrag einen Kunden, einen Standort und mindestens eine Aufgabe haben muss, bevor er zugewiesen werden kann, sollte das Backend das bei jedem Aufruf erzwingen. Die Web-App kann eine hilfreiche Meldung zeigen, und die Mobile-App ebenso, aber keine der beiden darf die Regel besitzen.
Dasselbe gilt für Statusänderungen. Nutze einen gemeinsamen Status-Flow für beide Apps, z. B. Entwurf, Zugewiesen, In Arbeit, Abgeschlossen und Geschlossen. Sobald dieser Flow im Backend lebt, folgen beide Apps demselben Pfad. Das Admin-Team kann Arbeit über die Web-App zuweisen, und das Feld-Team kann den Fortschritt über die Mobile-App aktualisieren, aber keine App kann Schritte überspringen, wenn das Backend es nicht erlaubt.
Berechnungen und Prüfungen sollten ebenfalls an einer Stelle ausgeführt werden. Hängt die Gesamtkostenberechnung von Stunden, Materialien, Steuern oder Freigabegrenzen ab, dann mache das im Backend. Wenn ein Techniker einen Auftrag nicht ohne Foto oder Unterschrift schließen kann, prüfe das dort.
Stell dir ein Service-Unternehmen vor. Das Büroteam nutzt die Web-App, um Jobs zu erstellen, und Techniker nutzen die Mobile-App vor Ort. Beide Apps sollten dieselbe Backend-Logik für Erstellen von Jobs, Zuweisen von Mitarbeitern, Statusänderungen und Berechnungen aufrufen.
Diese Trennung hält Bildschirme einfach. Jede App konzentriert sich darauf, was Nutzer sehen und tun müssen, während das Backend die Regeln schützt, die konsistent bleiben müssen.
Beginne mit Menschen, nicht mit Bildschirmen. Schreibe auf, wer das System nutzt, was sie tun und welche Entscheidungen sie treffen dürfen.
Für eine Admin-Web-App und eine Feld-Mobile-App sind das häufig Büro-Mitarbeiter, Manager und Außendienstler. Das Büro-Team erstellt Jobs, weist Personen zu, genehmigt Änderungen und schließt Arbeiten. Das Feld-Team sieht meist nur zugewiesene Jobs, aktualisiert Fortschritt, fügt Notizen hinzu und lädt Nachweise hoch.
Wenn das klar ist, skizziere das gemeinsame Datenmodell auf einer Seite. Halte es anfangs einfach: Jobs, Kunden, Mitarbeiter, Standorte, Fotos und Status-Historie. Füge nur die Felder hinzu, die jeder Datensatz wirklich braucht.
Designe um Datensätze und Zustandsänderungen herum, nicht um Seiten. Wenn beide Apps denselben Auftrag berühren, sollten sie dieselben Statuswerte, dieselben Zuweisungsregeln und dieselbe Freigabelogik verwenden.
Der letzte Schritt ist am wichtigsten. Nimm einen realistischen Fall, z. B. eine Reparaturanfrage, die im Büro erstellt, einem Techniker zugewiesen, vor Ort aktualisiert und dann von einem Manager überprüft wird. Wenn dein Modell diesen Ablauf ohne versteckte bildschirmspezifische Regeln handhabt, bist du auf dem richtigen Weg.
Das Backend bleibt geteilt, aber die Nutzererfahrung sollte es nicht. Eine Admin-Web-App und eine Feld-Mobile-App bedienen unterschiedliche Aufgaben, daher sollten sie dieselben Datensätze unterschiedlich darstellen.
Auf der Web-Seite brauchen Leute meist einen breiteren Überblick. Sie vergleichen viele Datensätze, sortieren Spalten, scannen Historien, nutzen Filter und führen Massenaktualisierungen durch. Ein Disponent oder Operations-Manager möchte vielleicht zehn Arbeitsaufträge auf einmal aktualisieren, Mitarbeiter zuweisen und Statusänderungen in einer Tabelle prüfen.
Auf dem Mobilgerät zählt Geschwindigkeit mehr als Übersicht. Ein Außendienstmitarbeiter braucht meist eine klare Antwort: Was ist als Nächstes zu tun? Der Home-Screen sollte die nächste Aufgabe, Adresse, Kontaktdaten, Frist und den Button zur Statusaktualisierung in den Vordergrund stellen.
Die Kernidee ist einfach: Behalte die Datensätze gleich und ändere das Layout drumherum. Wenn beide Apps dasselbe Job-, Kunden-, Status- und Notiz-Objekt nutzen, bleiben die Geschäftsregeln an einem Ort.
Was sich ändert, ist die Oberfläche. Web kann dichte Tabellen, gespeicherte Filter und Massenbearbeitungstools zeigen. Mobile sollte die aktuelle Aufgabe und die nächste Aktion hervorheben. Mobile kann Kamera-Fotos, Unterschriften, Barcode-Scans oder Standort erfassen. Web kann tiefere Überprüfungen, Reporting und Ausnahmebehandlung unterstützen.
Offline-Nutzung ist ein weiterer Unterschied. Eine Feld-App kann das Signal in einem Keller, auf einer Straße oder vor Ort verlieren. Das beeinflusst Sync-Design, Konfliktbehandlung und welche Daten auf dem Gerät zwischengespeichert werden müssen. Die Admin-Web-App geht meist von einer stabilen Verbindung aus und kann stärker auf Live-Updates vertrauen.
Ein einfaches Beispiel ist ein Inspektionsprozess. Das Büroteam nutzt die Web-App, um Besuche zuzuweisen, Ergebnisse zu prüfen und fehlerhafte Einträge massenhaft zu korrigieren. Der Inspektor nutzt die Mobile-App, um den nächsten Besuch zu öffnen, Fotos zu machen, die Ankunft zu bestätigen und den Bericht abzusenden. Verschiedene Bildschirme, derselbe Inspektionsdatensatz.
Stell dir ein Service-Unternehmen vor, das Geräte repariert. Das Büroteam arbeitet an Laptops, während Techniker den Großteil des Tages unterwegs sind.
Ein Disponent erstellt im Admin-Web-Tool einen neuen Arbeitsauftrag. Er trägt Kundenname, Adresse, Problem, Priorität, geplante Zeit und zugewiesenen Techniker ein. Das erzeugt einen gemeinsamen Datensatz, nicht eine separate Web-Version des Jobs.
Später öffnet der Techniker die Feld-Mobile-App und sieht denselben Arbeitsauftrag. Der Bildschirm sieht anders aus, weil der Job in einem anderen Kontext genutzt wird, aber die zugrunde liegenden Daten sind identisch. Der Techniker kann die Adresse sehen, den Kunden anrufen, die Aufgaben prüfen und den Fortschritt aktualisieren, ohne etwas neu einzugeben.
Vor Ort fügt der Techniker Fotos vom beschädigten Teil hinzu, schreibt ein paar Notizen und holt die Kundenunterschrift ein. All das wird in denselben Job-Datensatz gespeichert. Die Mobile-App erstellt kein eigenes Nebensystem für Fotos oder Notizen. Sie fügt einfach weitere Informationen zum geteilten Datenmodell hinzu.
Im Büro öffnet der Manager die Admin-Web-App und prüft den aktualisierten Auftrag. Er sieht, was vor Ort ergänzt wurde, genehmigt die Arbeit und leitet die Rechnung oder Folgeaufträge ein. Niemand muss zwei Versionen der Wahrheit vergleichen.
Die Status-Historie macht das nützlich. Wenn der Disponent den Auftrag auf Scheduled setzt, der Techniker ihn auf In Progress markiert und der Manager ihn als Completed schließt, sehen alle dieselbe Timeline. So lassen sich einfache Fragen leichter beantworten: Wer hat den Status wann geändert und was geschah vor und nach dem Besuch?
Der größte Fehler ist, dieselbe Regel an zwei Orten zu haben. Wenn die Admin-Web-App sagt, ein Job könne von "Scheduled" zu "In Progress" wechseln und die Mobile-App das auch prüft, werden diese Regeln driften. Halte Statusänderungen, Berechtigungen und erforderliche Prüfungen im Backend, wo beide Apps derselben Logik folgen.
Ein weiteres Problem ist, separate Datensätze für eigentlich denselben Auftrag zu erstellen. Teams tun das, wenn sie die Büroansicht anders erscheinen lassen wollen als die Feldansicht. Dann hat die Admin-App einen "Termin" und die Mobile-App einen "Besuch" und jemand muss sie synchron halten. Das führt meist zu widersprüchlichen Notizen, doppelten Aktualisierungen und Verwirrung darüber, welcher Datensatz echt ist.
Felder sind eine weitere Falle. Es ist leicht, immer wieder Spalten hinzuzufügen, weil ein Team „nur noch ein Detail“ will. Aber jedes Feld sollte einen Zweck haben. Frag, warum es wichtig ist, wer es nutzt und ob es eine Regel, einen Bericht oder eine Entscheidung beeinflusst. Wenn die Antwort unklar ist, lass es weg, bis der Bedarf real ist.
Schwache Konnektivität wird oft ignoriert, bis der erste Tag im Feld kommt. Ein Techniker öffnet die Mobile-App im Keller, auf einer ländlichen Straße oder in einem Lager ohne Signal. Wenn die App für jede Aktion eine Live-Verbindung braucht, steht die Arbeit. Plane, welche Daten offline verfügbar sein müssen, welche Aktionen warten und synchronisiert werden können und wie Konflikte beim Wiederverbinden gelöst werden.
Begriffe können ein geteiltes System ebenfalls zerstören. Wenn ein Team einen Schritt "Assigned" nennt, ein anderes "Dispatched" und ein drittes "Ready", behandeln Menschen sie bald als verschiedene Zustände. Einigt euch früh auf eine gemeinsame Sprache und verwendet sie überall.
Ein guter Riechtest ist simpel: Ein Auftrag sollte eine Quelle der Wahrheit haben, eine Regel sollte nur an einem Ort leben und ein Status sollte einen klaren Namen haben.
Bevor du etwas baust, teste den Plan auf Papier. Wenn das Modell einfach genug ist, um es in ein paar Minuten zu erklären, ist es meist stabil genug, während beide Apps wachsen.
Eine gute Kontrolle ist: Können beide Teams auf denselben Datensatz zeigen und dasselbe meinen? Wenn das Büro-Team einen Job, eine Aufgabe, einen Kunden oder einen Inspektionsbericht anders sieht als das Feld-Team, beginnt die Drift früh.
Nutze eine kurze Checkliste:
Ein kleines Szenario hilft. Stell dir eine Admin-Web-App vor, die Reparaturbesuche plant, und eine Mobile-App, die Techniker vor Ort nutzen. Das Admin-Team braucht Filter, Berichte und die komplette Kundenhistorie. Der Techniker braucht vielleicht nur die Jobs des Tages, Kontaktdaten, Sicherheitsnotizen und eine Möglichkeit, den Status zu aktualisieren. Verschiedene Bildschirme sind in Ordnung. Unterschiedliche Geschäftsregeln sind es nicht.
Ein weiterer Praxistest: Ändere eine Regel und sieh nach, wie viele Stellen betroffen sind. Wenn „ein Foto ist vor Abschluss erforderlich“ zu ändern bedeutet, Backend-Logik plus mehrere separate Bildschirme zu editieren, beginnt das Design bereits auseinanderzulaufen.
Wenn du ein Backend für Web und Mobile willst, fang nicht damit an, jeden Bildschirm oder jede Team-Anforderung zu kartieren. Fang mit einem Workflow an, der jeden Tag wichtig ist, z. B. einen Auftrag erstellen, zuweisen, den Status aktualisieren und schließen. Ein kleiner Workflow lässt sich leichter testen und zeigt schnell, wo das Datenmodell klar ist und wo noch Lücken sind.
Baue die Backend-Regeln, bevor du die Bildschirme polierst. Entscheide, welche Felder Pflicht sind, wer den Status ändern darf, was passiert, wenn Daten fehlen, und welche Aktionen Alerts oder Folgeaufgaben auslösen. Wenn diese Regeln im Backend leben, können Admin-Web-App und Feld-Mobile-App an der Oberfläche unterschiedlich aussehen, aber dieselbe Logik folgen.
Eine praktische Reihenfolge ist einfach: definiere die Hauptdatensätze und ihre Beziehungen, schreibe die Kern-Geschäftsregeln und Statusänderungen, teste den Workflow mit Beispieldaten, designe die Web-Ansicht für Büroaufgaben und die Mobile-Ansicht für Feldaufgaben, und überprüfe die erste Version mit echten Nutzern.
Diese Reihenfolge hilft, einen häufigen Fehler zu vermeiden: zwei polierte Apps zu bauen, die sich widersprechen.
Wenn du schneller vorankommen willst, kann eine No-Code-Plattform wie AppMaster helfen. Sie ermöglicht Teams, Daten und Geschäftslogik an einem Ort zu definieren und daraus eine Web-App und eine native Mobile-App zu erstellen.
Halte die erste Version klein. Bitte einen Manager, die Web-App für eine echte Aufgabe zu nutzen, und einen Außendienstmitarbeiter, die Mobile-App während einer echten Schicht zu verwenden. Beobachte, wo sie zögern, was sie auslassen und was sie als Nächstes erwarten. Behebe diese Punkte zuerst und erweitere dann die Workflows.
Das ist meist der sicherste Weg: ein gemeinsames Modell, einheitliche Regeln und zwei Erlebnisse, die an realer Arbeit ausgerichtet sind.
10. März 2026
6 Min
08. März 20269 Min
07. März 20266 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
