Built an AI monitoring tool for an environmental NGO
Role
Company
Timeline
Built an AI monitoring tool for an environmental NGO
Stowarzyszenie Nasz Bóbr
2026
OVERVIEW
Nasz Bóbr is an environmental NGO working on beaver habitat protection, wetlands, and water retention.
To identify cases that might require intervention, volunteers regularly monitor public registers across all Polish voivodeships.
The process was entirely manual and took around 2.5 hours per monitoring cycle.
I designed and built an internal monitoring tool that automates much of this work by collecting, filtering, and organising relevant public records in one place.
The goal was not simply to automate search but it was to reduce repetitive cognitive work so volunteers could spend more time on analysis, intervention, and advocacy (and to prevent activist burnout).
Role
Product Designer & Product Builder
Scope
Product Discovery · Workflow Design · Information Architecture · Data Modelling · AI-assisted Development · Human-in-the-loop Design
CHALLENGE
Manual monitoring was taking too much time and attention
The previous process required volunteers to repeatedly open regional systems, run similar searches, scan large numbers of records, check whether they had already been reviewed, and identify potentially relevant cases.
The main problems were straightforward:
around 2.5 hours of manual work per cycle;
repetitive context switching between regional systems;
high cognitive load from scanning similar records;
duplicated work when previously reviewed cases reappeared;
limited volunteer capacity and risk of activist burnout.
The product question was:
How can we automate repetitive monitoring so volunteers spend less time searching and more time acting on relevant cases?
DISCOVERY
I mapped the existing monitoring workflow and analysed the public systems used by regional environmental authorities.
I initially expected the data to come from one consistent source, but research showed differences in regional identifiers, source configurations, and available records.
This meant the product needed to support multiple sources while presenting the results through one consistent workflow.
I defined three priorities:
Reduce manual searching
Automate repeated checks across regional sources.
Reduce noise
Surface records relevant to beaver-related cases rather than forcing volunteers to review everything.
Avoid repeated work
Remember previously seen records and highlight only new or changed cases.
SOLUTION
One place to review cases from multiple sources
I designed the product around a simple monitoring workflow:
collect → filter → compare → review
The application:
checks configured public registers;
retrieves new records;
filters them using beaver-related keywords;
normalises information from different sources;
identifies new, known, and changed records;
removes unnecessary duplicates;
presents potentially relevant cases in a consistent review interface.
Each case provides the information needed for an initial decision, such as authority, publication date, location, case description, status, and original source.
Human review remains part of the workflow before a case is treated as relevant for intervention.
Building the working product
I used AI-assisted development and Cursor to move directly from workflow design into implementation.
Working with real public data helped me iterate on the product logic, information structure, filtering, deduplication, and monitoring behaviour rather than designing against hypothetical content.
2.5 hours → approximately 20 minutes
The tool reduced the time required to monitor all voivodeships from around 2.5 hours to approximately 20 minutes per cycle.
~87% reduction in monitoring time
It also reduces the cognitive effort required to repeatedly search, compare, and remember records across multiple systems.
As a result, volunteers can spend more of their limited time on:
assessing relevant cases;
requesting documentation;
analysing ecological context;
preparing interventions and advocacy.
REFLECTION
Automate repetition, preserve attention
This project showed me how quickly a relatively small internal product can create value when it targets the right operational bottleneck.
The core problem was not a lack of information. It was the amount of repetitive work required to find the information that mattered.
By automating that work, the product reduces both time cost and cognitive load, while leaving case assessment and intervention decisions with the people who have the relevant expertise.
