Taking over the EDK app and regaining control of its development.

Use context

The map supports both safety and continuity of the experience

The Extreme Way of the Cross takes participants along a night route of roughly 40 kilometers, often away from main roads and through areas with weak mobile coverage. The phone is not an optional addition to the event. It helps participants recognize the route, their location, and direction of travel while also providing the meditations assigned to each station. A small interface issue that would be a minor inconvenience in an everyday application can break concentration in the dark and make it harder to choose the right path at a junction.

The map, GPS, and compass are the primary tools guiding a participant along the route. They must work together: location needs to be legible, direction easy to understand, and the map view needs to behave predictably while the participant is walking, rotating the phone, or changing zoom. The application should provide enough information without competing for attention with the journey and reflection itself. This context shaped my technical priorities as much as the code did.

Offline access is equally practical. A route can pass through forests, fields, and villages where mobile data disappears. Participants need a previously downloaded map in a light or dark variant and locally available content, without assuming that connectivity will return at the right moment. My work therefore covered not only the online map view but also downloads, theme switching, error handling, and application lifecycle behavior.

Starting point

The external application maintenance and development model

The application was stable and very well engineered. The previous supplier specialized in mapping products, took care of versioning and quality, and followed sensible release practices - for example, it did not ship releases on Fridays. I was not taking over a product that needed a technical rescue, and I have no concerns about the quality of the previous team's work.

The challenge was to align the operating model with the Foundation's current needs. External maintenance came with a defined cost and a natural process for agreeing on larger changes. This was not a problem with the supplier, but a characteristic of that collaboration model. The Foundation needed a more agile development model: the ability to test hypotheses quickly, divide changes into small stages, and learn from behavior on real devices.

Recovering knowledge

The takeover began with reconstruction, not a rewrite

I started by reconstructing the architecture of the existing Flutter application: user flows, dependencies between screens, data sources, map state, Firebase integrations, GPS behavior, and areas particularly exposed to regression. This was not a response to chaotic code. It was the responsibility of understanding a well-built product before beginning a major modernization. I turned knowledge distributed across the codebase and change history into an explicit model of the product.

I then created version-controlled rules and project context for Claude Code. They described the architecture, conventions, constraints, quality checks, and acceptance criteria. New sessions no longer started by guessing, and important decisions remained in the repository with the code. The context did not replace product documentation. It connected that documentation with the practical instructions required to make a specific change safely.

I gave every Claude Code task a limited scope and an observable outcome. After implementation, I reviewed the changes, ran tests, built the application, and checked its behavior on real devices. I directed problems into another small iteration instead of letting them disappear inside a large batch of work. I controlled releases so that I could connect a regression to a specific scope and decide quickly how to address it.

I was responsible for this entire way of working: the architectural direction, task scope, code assessment, device testing, interpretation of failures, and the decision about what was ready to release. Claude Code supported my analysis and wrote a substantial part of the implementation, but it did not assume responsibility for the product. That distinction mattered in an application used at night, while moving, and beyond reliable mobile coverage.

Navigation in the field

From a static map to a predictable navigation tool

I migrated the application to MapLibre, moving it to vector rendering and creating the foundation for map rotation, a compass, and smoother movement of the map view. The change covered both the base-layer technology and the logic controlling the view. I had to keep the map view, user marker, and device orientation consistent so that rotating the screen did not disorient the participant and returning to location tracking remained obvious.

I designed three GPS states around distinct user intentions: freely browsing the map, following the current position, and navigating with the map aligned to the direction of travel. I added a compass for returning to north and made sure automatic tracking did not fight manual map movement. I brought the interaction patterns closer to Google Maps because familiar behavior reduces cognitive effort when attention should remain on the route.

The map presents several kinds of information at once. I added event and station clustering to reduce visual noise when zoomed out, together with a collapsible route panel that exposes details without permanently covering the map. I also built an interactive elevation chart that connects the height profile with the course of the route and helps participants understand the selected journey before and during the walk. I treated these elements as one information system rather than separate widgets.

I delivered the map rebuild in stages so that I could compare each new behavior with familiar scenarios. I first established a stable rendering foundation, then added orientation and GPS modes, followed by layers, clusters, the route panel, and the elevation chart. This order reduced the number of variables during diagnosis and allowed me to preserve a working product between releases.

Product resilience

Smooth performance and new features without losing stability

I extended offline mode with downloadable light and dark maps. I accounted for concurrent downloads, network errors, partial failures, and clear user-facing state rather than assuming a perfect connection. I also ensured that local data remained usable after a theme change so that a previously prepared map still worked when the device could not download another variant.

I improved map performance by reducing unnecessary repaints and consolidating rendering layers. This eliminated stuttering and restored smooth map performance on budget Android devices, without publishing an undocumented frame-rate measurement. I based the optimization on observed behavior, analysis of state-update paths, and reducing the work performed whenever the location or map view changed.

While expanding the product's central feature, I had to preserve the high quality that the application already had. I therefore protected the new stack against MapLibre-related SIGSEGV failures and refined GPS updates, light and dark theme switching, Firebase Remote Config, lifecycle handling, and safe areas. The issues I guarded the modernized stack against were not defects in the inherited application. They were risks introduced by the new map engine and additional features.

I verified each fix not only in isolation but also in combination with the map, navigation, and transitions between background and foreground. This prevented a fix for one scenario from changing another without detection. Device testing complemented automated checks wherever sensors, graphics drivers, phone resources, or operating-system behavior mattered.

Outcome

Controlled development from version 1.8.0 to 1.10.5

Since taking over the application, I have developed it from version 1.8.0 to 1.10.5. More important than the number of changes is the new way of working: the Foundation now has explicit technical context, a reviewable history of decisions, and a process that can divide a larger product direction into verifiable stages without losing responsibility for the whole.

I do not claim a simple relationship between the scope of changes and store ratings. The Foundation gained greater development agility through my work while preserving the product's high quality: a new vector map, predictable navigation, more resilient offline behavior, smoother performance, and context infrastructure for working with Claude Code. Together, they form a foundation on which future participant needs can be evaluated and delivered in a controlled way.