Über das Projekt und den Kunden#
Eine mobile App entwerfen und ausliefern, die eine natürliche Erweiterung des Web-Systems PZŁ 2.0 ist — und den gesamten Arbeitsalltag eines Jagdvereins abdeckt: elektronisches Jagdbuch, Einzel- und Gesellschaftsjagden, Wildschäden, Vereinslager, Revierkarten mit Overlay-Ebenen, jagdliche Einrichtungen, Abrechnungen, Ausführung des Jahresplans, Rundschreiben des Hauptvorstands, Chat, Alarmmeldungen, Wetter mit Windgeschwindigkeit, Gasteinladungen und Mitgliederhilfe — mit einer einheitlichen Aufteilung der Berechtigungen über alle Ebenen der PZŁ-Struktur hinweg.
Wir haben zahlreiche Rückmeldungen und Fragen von Verbandsmitgliedern erhalten. Das ist ein deutliches Signal, dass die Mitglieder moderne Lösungen erwarten, die die Arbeit der Vereine erleichtern und den PZŁ als Organisation stärken.
Womit wir uns beschäftigt haben#
Das System der Jagdvereine deckt den gesamten Arbeitsalltag eines Vereins ab — von der Jagderfassung über Einzel- und Gesellschaftsjagden, Wildschäden und Lager bis hin zur Kommunikation innerhalb der Organisation. Das heißt: Die mobile App musste eine sehr breite Palette an Szenarien in einem einzigen, stimmigen Produkt unterbringen.
Elektronisches Jagdbuch
Digitaler Ersatz für das papierene Jagdbuch, in dem der Jäger eine Jagd meldet. Das Herzstück der Vereinsarbeit — muss schnell, zuverlässig und einfach zu bedienen sein.
Jagden — Einzel und Gesellschaft
Zwei unterschiedliche Abläufe in einer App. Die Einzeljagd ist ein schneller Eintrag. Die Gesellschaftsjagd ist eine Teilnehmerliste, Stände, Verlauf und Schlussabrechnung.
Die Revierkarte als Zentrum der App
Reviergrenzen, jagdliche Einrichtungen, Flurstücke, Forstreviere, Orthofotos. Die Karte ist der Screen, zu dem Nutzer dutzende Male am Tag zurückkehren — sie muss sofort da und gut lesbar sein.
Wildschäden
Vorläufige und endgültige Schätzung, mit dem Schadensgebiet auf der Karte markiert. Ein heikler Prozess aus Sicht von Landwirten und Versicherern — er darf keine Fehler enthalten.
Ein Nutzer, viele Rollen, viele Vereine
Dieselbe Person ist mal Jäger im einen Verein und Jagdleiter im anderen. Die App muss ihr nur das zeigen, was zum aktuellen Kontext gehört — ohne erneute Anmeldung.
Konsistenz mit Web und Backend
Ein Jagdleiter öffnet denselben Eintrag morgens am Laptop und abends am Telefon. Mobile, Web und Backend müssen exakt dieselben Daten auf dieselbe Weise sehen.
Alarmmeldung — Schuss
Notfallmeldung eines Vorfalls samt Standort, sofort verfügbar. Eine Funktion, bei der jede Sekunde im Entwurf zählt.
Vereinslager und Abrechnungen
Bestände, Reservierungen, jagdliche Einrichtungen, Einzel- und Sammelabrechnungen, Ausführung des Jahresplans — in einem Modul, mit klarer Aufteilung der Berechtigungen.
Kommunikation des Hauptvorstands
Das Rundschreiben des Hauptvorstands, das alle Jäger erreicht, Nutzernachrichten, Bekanntmachungen — der tägliche Kommunikationskanal innerhalb des Verbands.
Standort im Hintergrund — nur bei Bedarf
Die Position des Jägers zählt während einer Gesellschaftsjagd. Außerhalb davon — nicht. Wir schalten sie nur dann ein, wenn sie tatsächlich einen Mehrwert bringt.
Wetter und Bedingungen im Revier
Aktuelles Wetter, Windrichtung und -geschwindigkeit, Sonnenauf- und -untergang — Informationen, die für den Jäger darüber entscheiden, ob er überhaupt ins Revier aufbricht.
Gäste und Einladungen
Ein Jäger aus einem anderen Verein kann zu einer Jagd eingeladen werden. Das erfordert einen vollständigen Genehmigungs-Workflow — Ausstellung, Annahme, Gültigkeit für einen bestimmten Tag und ein bestimmtes Revier.
Das neue System wird die Arbeit in den Jagdvereinen deutlich erleichtern. Es ist einfacher zu bedienen, intuitiver, und viele Tätigkeiten — etwa das Berichten oder die Dokumentenverwaltung — werden erheblich schneller und weniger fehleranfällig.
Ein ähnlich komplexes Projekt? Sprechen wir darüber.
Module, Rollen, Integrationen in bestehende Systeme und Skalierung — wir wissen, wie daraus ein stimmiges Produkt wird.
Wie wir ins Projekt eingestiegen sind#
Das Projekt wird von SmallGIS als Generalauftragnehmer des Systems PZŁ 2.0 geführt. SmallGIS hat die Technologien für die gesamte Lösung ausgewählt — darunter React Native für die mobile App — und anschließend einen Partner gesucht, der diesen Teil verantwortet. So sind sie auf uns gekommen. Unsere Rolle als Mobile Development Leader war es, die volle Verantwortung für die Mobile-Ebene zu übernehmen und das React-Native-Team so zu führen, dass die App in Zeit und Qualität fertig wird.
Einstieg ins Projekt und Übernahme der Mobile-Ebene
SmallGIS hatte eine definierte Produktvision, einen Stack und einen Vertrag mit dem PZŁ. Unsere erste Aufgabe war es, den Umfang zu verstehen, Risiken auf der Mobile-Seite zu benennen und die Zusammenarbeit mit dem Web- und Backend-Team von SmallGIS festzulegen.
Entwicklung in Etappen mit großen Releases
Wir haben in mehreren Etappen gearbeitet — jede schloss mit dem Release eines konkreten Funktionspakets ab, das SmallGIS und dem PZŁ vorgestellt wurde. Ein Paket, kein Sprint — denn ein Paket zeigt den geschäftlichen Wert, ein Sprint nur den Zeitablauf.
Beta mit Jägern und Übergabe an den Kunden
Closed Beta mit einer Gruppe vom PZŁ ausgewählter Vereine, Iterationen auf Basis realer Jagdberichte, finale Übergabe von Code und Dokumentation an SmallGIS nach 6 Monaten.
Ohne Vendor-Lock-in. Der Kunde besitzt sämtliche Rechte am Code.
Für den PZŁ war entscheidend, nach Ende der Zusammenarbeit vollen Einfluss auf die Weiterentwicklung des Systems zu behalten — die Möglichkeit zum Ausbau, zur Integration weiterer Werkzeuge und zu einem etwaigen Wechsel des Auftragnehmers, ohne Datenverlust oder Projektstillstand zu riskieren. Deshalb ist der Stack bewusst standardisiert, der Code wird vollständig übergeben — samt vollständiger Übertragung der wirtschaftlichen Urheberrechte —, und die technische Dokumentation sowie CI/CD werden vom ersten Tag an bereitgestellt.
Zentrale Ansichten#
Neun zentrale Ansichten der App — von der Gesellschaftsjagd und der Teamkommunikation bis zur Schadensschätzung und Gästeverwaltung.
Hinweis: Die obigen Ansichten sind unsere Redesigns der ursprünglichen App-Screens. Design und Weiterentwicklung von SKŁ PZŁ 2.0 liegen inzwischen direkt beim Polnischen Jagdverband — philosopht arbeitet nicht mehr an dessen grafischer Gestaltung.
Was wir geliefert haben#
Die App wurde in 6 Monaten an SmallGIS übergeben und ist Teil der landesweiten digitalen Infrastruktur des PZŁ — des größten Digitalvorhabens in der Geschichte des Verbands.
Entscheidungen, die den Unterschied machten#
Drei technische Entscheidungen, die am stärksten geprägt haben, wie sich die App verhält und wie einfach sie zu warten ist. Der Rest des Stacks ist bewusst standardisiert — ohne exotische Abhängigkeiten, damit SmallGIS und der PZŁ ihn nach der Projektübergabe pflegen können.
API-Client aus der Spezifikation generiert, nicht von Hand geschrieben
Die App spricht über mehr als zwanzig Funktionsmodule mit dem Backend. Den REST-Client von Hand zu schreiben bedeutet unvermeidliches Auseinanderdriften von Mobile, Web und Backend — jede Vertragsänderung erzeugt eine neue Regression auf drei Plattformen gleichzeitig.
Wir haben auf Codegen aus OpenAPI gesetzt: Typen, Validierungsschemata und Daten-Hooks werden automatisch aus der Backend-Spezifikation generiert, die Regenerierung läuft bei jedem Build. Der Effekt fürs Team: Eine Änderung am API zeigt sich in Mobile sofort als Kompilierfehler, nie als stillschweigend verlorenes Feld.
Es gibt noch einen zweiten, weniger offensichtlichen Effekt — die Verantwortung für die Validierung dorthin zu verschieben, wo sie natürlich hingehört: ins Backend. Das Frontend schreibt keine eigenen Validierungsregeln, die vom Vertrag abweichen könnten — es vertraut der Spezifikation und den automatisch generierten Schemata. Datensicherheit wird an einer Stelle durchgesetzt, konsistent für jeden Client — Mobile, Web und jeden künftigen.
Berechtigungen als Schicht, nicht als if-Abfragen über die Komponenten verstreut
Das System verwaltet viele Rollen in vielen Vereinen gleichzeitig. Ohne eine gemeinsame Berechtigungsschicht würde jeder Screen schnell zu einem Dickicht aus Bedingungen — unleserlich und anfällig für Sicherheitsfehler.
Wir haben ein zentrales Berechtigungsregister auf Basis der Expo-Router-Routen entworfen, dazu einen einzigen Hook, der die Regeln in jeder Komponente durchsetzt. Der aktive Kontext (welcher Verein, welche Rolle) ist die einzige Quelle der Wahrheit — ein Kontowechsel ändert die Sichtbarkeit der Module sofort, ohne erneute Anmeldung, ohne Magie.
Standort im Hintergrund nur dann, wenn er wirklich zählt
Die Position des Jägers ist während einer Gesellschaftsjagd wichtig — man weiß, wer wo auf der Linie steht. Darüber hinaus ist sie überflüssig und wäre aus Sicht von Datenschutz und Akku bedenklich.
Den Hintergrund-Standort starten wir pro aktiver Jagd, nicht global. Der Task beginnt, wenn ein Jäger einer Gesellschaftsjagd beitritt, und endet von selbst, wenn die Jagd schließt. Das Foreground-Tracking ist zusätzlich gedrosselt — so viel Genauigkeit, wie die Karte braucht, ohne das Telefon nach einer Stunde im Wald leerzusaugen.
Tech-Stack#
Die Auswahl an Bibliotheken und Werkzeugen rund um die drei Entscheidungen oben. Standardisiert, gut gepflegt, ohne Risiko, verwaist zu werden.
FRAMEWORK · NAVIGATION
SPRACHE
KARTEN & STANDORT
STATE, DATEN & CODEGEN
BENACHRICHTIGUNGEN
RELEASE & DELIVERY
AUTH & SICHERHEIT
UI & PERFORMANCE
Umgebungen und Wege zum Nutzer#
Vier Umgebungen, jede mit eigener Rolle und eigenem Adressatenkreis. Je näher am Endnutzer, desto schärfer die Eintrittskriterien.
Revierkarte — ein schichtbasiertes System #
Vier Basis-Ebenen, sechs Overlay-Ebenen, ein stimmiges Erlebnis
Die Karte in der App ist keine einmalige Ansicht — sie ist der zentrale Screen, zu dem der Nutzer aus verschiedenen Modulen zurückkehrt: vom Screen der Gesellschaftsjagd, von Wildschäden, jagdlichen Einrichtungen, der Revierliste. Jedes Mal will er dasselbe Bild der Welt sehen, nur mit einem anderen Akzent — mal andere Overlays, mal eine andere Basis-Ebene.
Der erste Ansatz war naheliegend, aber fehlerhaft: Ein Wechsel der Basis-Ebene hängte die gesamte Karte neu ein. Ein Flackern des Screens, verlorene Kameraposition und verlorener Zoom, ein voller Reload aller Kacheln — auf einem Screen, der während der Jagd genutzt wird, inakzeptabel.
Die Lösung war, die Karte in vier klar getrennte Verantwortungsebenen zu zerlegen:
Controller — hält den Ansichtszustand, entscheidet, welche Basis-Ebene aktiv ist und welche Overlays der Nutzer aktiviert hat. Komposition — setzt alle Basis- und Overlay-Ebenen auf einmal zusammen, aber nur die aktiven rendern Kacheln; der Rest ist bereit, blitzschnell eingeblendet zu werden. Einzelne Ebene — jede Datenquelle (Orthofoto, Topo, Flurstücke, Forstreviere) hat ihre eigene Komponente mit eigener Ladestrategie. Lazy Loading — schwere Overlay-Ebenen werden erst bei der ersten Nutzung eingehängt, ohne den ersten Render der Karte zu blockieren.
Der Effekt ist auf den ersten Blick unsichtbar — was das größte Kompliment für Kartencode ist. Der Nutzer wechselt zwischen Orthofoto und OSM, die Kamera bleibt an Ort und Stelle, die Kacheln gleiten flüssig herein. Aus Sicht eines Jagdleiters, der mitten in der Jagd die Reviergrenzen prüft — die Karte funktioniert einfach, so wie sie soll.
// konzeptionell: eine Komposition, viele Ebenen, eine Karte <MapComposition camera={camera}> // Basis-Ebenen — immer im Baum, eine aktiv <BaseLayers active={baseLayer} /> // Overlays — lazy, erst bei erster Nutzung gemountet <Overlays visible={enabledOverlays} lazy /> </MapComposition>
Das ist eine Investition nicht nur in Technologie, sondern vor allem in das bessere Funktionieren unserer Jägergemeinschaft.