Digitising catch reporting has been a valuable learning experience
This article was featured in Eurofish Magazine 4 2025.
PERK, the Estonian acronym for the digital platform created for commercial fishers to report their catches, has now covered all fishing segments for a year. An assessment of the system shows what it has achieved and what could be -improved.
Originally launched in 2018, PERK—Püügiandmete Esitamise Rakendus Kaluritele—was developed as a digital platform to simplify and modernise catch reporting for Estonia’s commercial fishers. For several years, its use was optional and limited to specific fisheries segments. However, in 2024, Estonia made the system mandatory for all licensed commercial fishing activities marking a significant milestone in the country’s broader transition toward digital fisheries governance. PERK replaced paper-based and hybrid reporting systems with a single online solution aimed at reducing administrative burden, improving data quality, and ensuring real-time accessibility for authorities.
Results from review will shape future developments
One year into implementation, the system is firmly in use by nearly 1,900 registered users. While the overall transition has been successful in achieving core objectives, the rollout has not been without friction. The first year has offered valuable lessons on balancing user feedback with system stability, planning helpdesk capacity, and understanding the constraints of a limited user base. These experiences now inform the path forward.
Ice fishing in the Pärnu bay targets pikeperch. Catches in both 2022 and 2023 were around 22 tonnes each.
PERK was never intended to be a static application. From its early launch, it was designed to evolve in response to user needs. Fishers across Estonia actively provided feedback on how to streamline entries, improve usability on mobile devices, and reduce redundant steps. This openness to input created momentum but also introduced challenges. As user suggestions were incorporated and features layered into the system, technical complexity began to impact stability. There were periods where some users experienced delays in data synchronisation or difficulties saving entries—especially during busy reporting windows. The core architecture, originally optimised for straightforward data submission, became increasingly burdened by new functions, user-specific customisations, and exceptions. Looking back, a more incremental roadmap and clearer delineation between essential and optional features might have helped maintain performance consistency.
Support was there—but not always the fix
While technical support was always available throughout the first year, not every issue could be resolved immediately. “Some days it worked fine, other times it didn’t save my entries correctly, and it wasn’t immediately clear what was causing the issue,” says Tarmo Luks, a coastal fisherman from Pärnu. “Support was there when I needed it, and they always responded. But in certain cases, it wasn’t a quick fix—they told me the issue needed a technical change from the IT side. That takes time, and in the meantime, we had to find workarounds.” These situations were not the result of missing helpdesk infrastructure but rather the absence of immediate solutions when the issue required system-level changes. The reality is that not all support queries can be resolved on the first contact—particularly when they relate to the codebase or data structure. This has prompted reflections on how to improve not just the technical response but user communication pathways. Better feedback mechanisms, clearer troubleshooting flows, and additional training resources are now under development.
One factor influencing both usability and technical flexibility is the web-based nature of PERK. Rather than -developing a native mobile application, the platform was designed to run via browsers on desktop and mobile devices. This decision was based on economic and logistical reasoning: building two native apps—one for Android and one for iOS—would have required parallel development and long-term maintenance commitments. Given the scale of the user base (approximately 1,900), the investment required to support dual native environments was deemed unsustainable at the time. A responsive web platform was selected as a single-codebase solution that could serve all users across devices. However, this approach has some limitations. Web apps are inherently more dependent on stable internet connections and do not offer the same offline capabilities or system-level integrations as native apps. This means that in low-signal coastal areas, some users experienced slower performance or temporary issues storing unsent entries—though the platform was built to cache data and synchronise once connectivity was restored. These trade-offs are now being re-evaluated as part of the system’s long-term development strategy. Future updates may explore hybrid -solutions that retain the single-platform philosophy while improving offline and mobile-first capabilities.
Business use cases and the GDPR dilemma
A significant implementation challenge emerged from the mismatch between individual user design and company-level use cases. PERK was developed with the logic that the individual fisher—the person physically conducting the fishing activity—submits the data. However, larger fishing companies soon began requesting functionalities that would allow centralised oversight, shared user access, and internal reporting across vessels and crews. As modifications were attempted to support these requests, tensions arose with data privacy regulations (GDPR). In several cases, granting license holders access to crew-entered data risked violating privacy boundaries that had not been fully anticipated in the original system design. These experiences revealed a gap in early-stage analysis: the user base had not been sufficiently segmented, and use cases related to business administration, supervisory roles, and multi-user coordination had not been structurally mapped. Retrofitting these capabilities after rollout introduced complexity, requiring legal reviews and system architecture adjustments that delayed deployment. Going forward, more thorough user profiling and stakeholder consultation are planned to guide future functionality in line with both legal frameworks and sector needs.
One unavoidable consideration for the future is the scope of investment relative to the user base. With fewer than 2,000 active users, PERK must balance expectations for functionality and flexibility with the economic realities of custom software development. Every additional module or interface revision must be carefully weighed for its operational impact, budgetary cost, and long-term maintainability. At the same time, the system has fulfilled its regulatory purpose: authorities now receive structured, near-real-time catch data from all segments of the fleet. This has improved oversight, facilitated quota tracking, and reduced reporting gaps. “We’re seeing more consistent data coming in and fewer late submissions,” says Ivo Kask, a fisheries inspector with the Environmental Board. “It helps from an enforcement and transparency perspective, but yes, the first year has also shown us where system boundaries need to be clearer.”
Catering to all Estonian fisheries’ complexity is too ambitious
The first year of PERK’s full-scale use has demonstrated the value of digitalisation in fisheries reporting—but it has also revealed the many layers of complexity involved in trying to build one unified system for a sector that, in practice, operates under a patchwork of distinct rules, environments, and traditions. One of the most important reflections from this year is that the challenge hasn’t only been technical—it’s deeply structural. Estonia’s fishing sector is not a monolith. Instead, it is composed of multiple, highly specialised fisheries, each with its own legal context, operational logic, and cultural practices. This makes the task of developing a coherent and universal reporting system not only ambitious, but extraordinarily complex.
For example, on Lake Peipsi, reporting must align with bilateral agreements between Estonia and Russia, including shared quota management, restricted areas, and unique temporal fishing rules. In contrast, Baltic Sea coastal fishing operates under EU fisheries policy and national maritime law, with entirely different control requirements and fleet profiles.
Then there is Võrtsjärv, a large inland lake with its own ecological dynamics and regionally adapted fishing practices, which do not align with Peipsi or coastal systems. Lamprey fishing in rivers is highly seasonal and uses specialised traps and gear. Winter fishing brings further complexity, as it occurs directly on the ice without vessels, meaning GPS tracking and trip reporting logic often break down. Meanwhile, shallow-water net fishing, where nets are laid manually by walking into the water, defies assumptions baked into most maritime reporting systems—there are no engine hours, no departure or arrival points, and no vessel monitoring involved. Each of these methods brings with it not only operational diversity but also administrative complexity. What may appear as a minor field in a user interface—like trip type or gear classification—may in fact require dozens of conditional rules and exceptions behind the scenes. Designing a “simple” interface becomes impossible when the underlying logic must account for hundreds of situational variables.
Future iterations must combine flexibility with robustness
In light of this, it’s clear that the original ambition of creating one system for all fishers was always going to involve compromises. In some ways, the challenge was underestimated—not due to a lack of expertise, but because no single design process could fully anticipate the combined effect of such local diversity. As we moved from pilot cases to full implementation, these differences began to assert themselves more forcefully, requiring reactive changes and adaptations that tested both the system’s technical architecture and our own assumptions.
The path forward involves acknowledging this complexity as a baseline reality, not an obstacle to be eliminated. Future development must be informed by more structured input from the full range of user types, and a governance model that can balance flexibility with sustainability. Rather than continuing to add features in response to every edge case, we must clarify the system’s core scope and build it to be robust and adaptable around clearly defined boundaries.
PERK has succeeded in laying the foundation for digital catch reporting in Estonia. What we have learned in its first year is that its continued success depends not on simplification, but on intelligent adaptation to the genuine diversity of fishing practices that define Estonia’s waters, rivers, and lakes.
Indrek Adler, Ministry of Regional Affairs and Agriculture, indrek.adler@agri.ee
