About the project and the client#
The Polish Hunting Association (PZŁ) is the national body of Polish hunters — structurally it covers hunting clubs, regional boards and the National Board. SKŁ PZŁ 2.0 is the largest digital initiative in the Association's history, replacing fragmented tools and the paper hunt log with a single nationwide system.
Design and ship a mobile app that is a natural extension of the PZŁ 2.0 web system — covering the full lifecycle of a hunting club: the Electronic Hunt Log, individual and group hunts, wildlife damage, club inventory, district maps with overlay layers, hunting equipment, settlements, annual plan execution, the National Board newsletter, chat, alert reports, weather with wind speed, guest invitations and peer assistance — with a unified permissions split across all levels of the PZŁ structure.
We have received many comments and questions from members of the Association. It's a clear signal that the community expects modern solutions that will improve the work of clubs and strengthen the PZŁ organization.
What we tackled#
The Hunting Clubs System covers the full lifecycle of a club's work — from hunt logging, through individual and group hunts, wildlife damage and inventory, to internal communication. That means the mobile app had to fit a very broad range of scenarios into one coherent product.
Electronic Hunt Log
A digital replacement for the paper log where hunters record a hunt. The central element of a club's work — has to be fast, reliable and easy to use.
Hunts — individual and group
Two different processes in one app. A solo hunt is a quick entry. A group hunt is a list of participants, posts, progression and final settlement.
The district map as the app's center
District boundaries, hunting equipment, parcels, forest divisions, orthophoto maps. The map is the screen users return to dozens of times a day — it has to be instant and readable.
Wildlife damage
Preliminary and final estimation, with the damage area marked on the map. A sensitive process for farmers and insurers — there's no room for error.
One user, many roles, many clubs
The same person may be a hunter in one club and a hunting master in another. The app has to show only what belongs to the current context — without re-logging.
Coherence with web and backend
A hunting master may open the same entry on a laptop in the morning and on a phone in the evening. Mobile, web and backend have to see exactly the same data, in the same way.
Alert report — shot
Emergency incident report with location, available instantly. A feature where every second of design matters.
Club inventory and settlements
Assets, reservations, hunting equipment, individual and group settlements, annual plan execution — in one module, with a clear permissions split.
National Board communication
The National Board newsletter reaching all hunters, user messages, announcements — the daily communication channel inside the Association.
Background location — only when needed
A hunter's position matters during a group hunt. Outside of it — not. We turn it on only when it actually adds value.
Weather and field conditions
Current weather, wind direction and speed, sunrise and sunset — information that decides whether a hunter sets out into the field at all.
Guests and invitations
A hunter from another club may be invited to a hunt. This requires a full permits workflow — issuance, acceptance, validity for a given day and district.
The new system will significantly improve the work in hunting clubs. It's simpler to use, more intuitive, and many activities — such as reporting or document handling — will become much faster and less prone to any errors.
Got a similarly complex project? Let's talk.
Maps, roles, cross-team integrations and scale — we know how to wrap it all into one coherent mobile product.
How we entered the project#
The project is led by SmallGIS as the contractor of the PZŁ 2.0 system. SmallGIS selected the technologies for the whole solution — including React Native for the mobile app — and then looked for a partner to lead that part. That's how they reached us. Our role as Mobile Development Leader was to take full ownership of the mobile layer and lead the React Native team so the app would close on time and quality.
Entering the project and taking ownership of the mobile layer
SmallGIS had a defined product vision, stack and a contract with PZŁ. Our first task was understanding the scope, flagging risks on the mobile side and agreeing how to collaborate with the SmallGIS web and backend teams.
Staged development with large releases
We worked in several stages — each closed with a release of a concrete feature package presented to SmallGIS and PZŁ. A package, not a sprint — because a package shows business value, while a sprint only shows time passing.
Beta with hunters and handover to the client
Closed beta with a group of clubs selected by PZŁ, iterations on the back of real hunting reports, final handover of code and documentation to SmallGIS after 6 months.
No vendor lock-in. The client owns the code in full.
For PZŁ it was crucial that after the engagement they would have full influence on further development — the ability to extend, integrate with new tools and possibly change contractors without the risk of losing data or stalling the project. That's why the stack is deliberately standard, the code is delivered in full together with a full transfer of economic copyright, and the technical documentation and CI/CD are handed over from day one.
Key views#
Nine key app views — from group hunt and team communication to damage assessment and guest management.
Note: the views above are our redesigns of the original app screens. The design and ongoing development of SKŁ PZŁ 2.0 are now handled directly by the Polish Hunting Association — philosopht no longer works on its design.
What we delivered#
The app was handed over to SmallGIS in 6 months and is part of the nationwide PZŁ digital infrastructure — the largest digital initiative in the Association's history.
Decisions that made the difference#
Three technical decisions that most strongly shaped how the app behaves and how easily it is maintained. The rest of the stack is deliberately standard — no exotic dependencies, so SmallGIS and PZŁ can maintain it after handover.
API client generated from spec, not hand-written
The app talks to the backend across more than twenty functional modules. Writing the REST client by hand means inevitable drift between mobile, web and backend — every contract change spawns a new regression across three platforms at once.
We bet on OpenAPI codegen: types, validation schemas and data-fetching hooks are generated automatically from the backend spec, regeneration runs on every build. The effect for the team: a change in the API shows up immediately in mobile as a compile error, never as a silently dropped field.
There's also a second, less obvious effect — moving validation responsibility to where it naturally belongs: the backend. The frontend doesn't write its own validation rules that could drift from the contract — it trusts the spec and the auto-generated schemas. Data safety is enforced in one place, consistently for every client — mobile, web and any future one.
Permissions as a layer, not if-statements scattered across components
The system handles many roles across many clubs at once. Without a shared permissions layer, every screen would quickly turn into a thicket of conditions — unreadable and prone to security mistakes.
We designed a central permissions registry based on Expo Router routes and a single hook that enforces the rules in every component. The active context (which club, which role) is one source of truth — switching accounts changes module visibility instantly, without re-logging, without magic.
Background location only when it actually matters
A hunter's position matters during a group hunt — you know who's where on the line. Outside of that, it's unnecessary and would be concerning from a privacy and battery point of view.
We run background location per active hunt, not globally. The task starts when a hunter joins a group hunt, ends by itself when the hunt closes. Foreground tracking is also throttled — as much accuracy as the map needs, without draining the phone after an hour in the forest.
Tech stack#
Library and tooling choices around the three decisions above. Standard, well-maintained, no abandonment risk.
FRAMEWORK · NAVIGATION
LANGUAGE
MAPS & LOCATION
STATE, DATA & CODEGEN
NOTIFICATIONS
RELEASE & DELIVERY
AUTH & SECURITY
UI & PERFORMANCE
Environments and paths to the user#
Four environments, each with a separate role and audience. The closer to the end user, the sharper the entry criteria.
Want similar outcomes at your company?
Initial analysis and estimate within 48h. No obligations — the first step is always on us.
District map — a layered system #
Four base layers, six overlay layers, one coherent experience
The map in the app is not a one-off view — it's the central screen the user returns to from various modules: the group hunt screen, wildlife damage, hunting equipment, district list. Every time they want to see the same picture of the world, only with a different accent — different overlays, a different base layer.
The first approach was intuitive but flawed: changing the base layer remounted the entire map. A screen flicker, lost camera position and zoom, a full reload of all tiles — unacceptable on a screen used during a hunt.
The solution was decomposing the map into four distinct layers of responsibility:
Controller — holds the view state, decides which base layer is active and which overlays the user has enabled. Composition — assembles all base and overlay layers at once, but only the active ones render tiles; the rest is ready to flash in instantly. Single layer — each data source (orthophoto, topo, parcels, forest divisions) has its own component with its own loading strategy. Lazy loading — heavy overlay layers only mount on first use, without blocking the map's initial render.
The effect is invisible at first glance — which is the biggest compliment for map code. The user switches between orthophoto and OSM, the camera stays in place, the tiles slide in smoothly. From the perspective of a hunting master checking district boundaries mid-hunt — the map just works, the way it should.
// koncepcyjnie: jedna kompozycja, wiele warstw, jedna mapa <MapComposition camera={camera}> // warstwy bazowe — zawsze w drzewie, aktywna jedna <BaseLayers active={baseLayer} /> // nakładki — lazy, montują się przy pierwszym użyciu <Overlays visible={enabledOverlays} lazy /> </MapComposition>
This is an investment not only in technology, but above all in the better functioning of our hunting community.