komoot is a mobile app and website for navigation and route planning for outdoor activities. It was founded in 2010 and has, as of March 2025, over 7 million monthly active users (45 million total) and is the leading outdoor app in Germany and other European countries.
I joined komoot as a Senior Backend Engineer in October 2021 and started in the Monetization squad, which handled all payment related areas as well as owning most of the premium features. In late 2024, I switched to the "Developer Productivity" squad, which was founded out of internal need from the backend team.
In March 2025 the company was bought by the Italian technology company Bending Spoons which laid off a large percentage of employees, including myself, in early April.
The tech stack of komoot had no arbitrary limitations; we generally used what was best for the given task. However, for the sake of maintainability, we usually used the following components:
- AWS as a cloud platform
- Databases: MySQL (for historical reasons), PostgreSQL (for anything GIS related), and DynamoDB
- Languages: Kotlin or Python
- Frameworks: Spring (Boot) and ktor
- Runtime: AWS Fargate or AWS Lambda functions
- CI/CD: CircleCI or GitHub Actions
Work in the Monetization squad
Migrating welcome offer emails database
komoot was sending out welcome offer emails to users who joined. That offer consisted of a ~60% discount on their "World Pack" product, which allows users to navigate offline and download map data of the entire world. The original implementation of this was roughly 5 years old and very inflexible. As the Monetization squad wanted to extend the offer to also support the subscription-based "komoot Premium" there was some work needed to make this possible. This was also my onboarding project at komoot, to familiarize myself with the main codebase and the central, monolithic core.
As part of this change, I migrated the live data from the existing storage in MySQL to a more scalable, DynamoDB-based storage. This involved an ongoing data replication with a dual-write strategy, paired with a background job moving the existing data. I also implemented sending different emails depending on user type and feature flags.
Mass mail sending
For general newsletter sending, I developed a new mass mailing system. The existing one was very simple and relied on loading all necessary data into memory, which was now no longer possible due to the sheer size of the user base. It also had other technical problems, so we decided not to fix it but to replace it. Since personalized email sending and templating were already built as an in-house solution, it was easier to just add mass-mailing on top instead of transitioning to an external vendor.
The system worked by loading data from an Athena export of the relevant user data and then using an SQS queue to invoke a Lambda function to send out the emails. All tied together by an AWS Step function for management and coupled to a simple UI so that people from the brand and other squads could send newsletters as a self-service.
Dynamic Promotions
In the past, komoot always struggled with sales campaigns. Usually, those campaigns would contain different offers for new users, users who had already purchased a one-time product, and people with expired subscriptions. The root of the problem was that there were multiple places where logic was implemented with regard to which offer a particular user got: the purchase backend, the campaign email sending, and then also in each of the clients. Sometimes, those criteria were not quite lining up for edge cases, and there were changes over time (e.g., a subscription ran out shortly after/before sending an offer email). Additionally, most of the logic was hardcoded and also had to be hand-changed from campaign to campaign since we also usually did changes and ran A/B tests.
Given that we were usually sending out between 12 and 20 million emails per campaign, even a very small fraction of these issues would result in hundreds of questions to our support regarding prices being not what we promised in a specific email, which then also required manual work to make the promised prices work for users who were really insisting.
We also had two entirely different concepts of promotions available to users. One was the aforementioned sales campaigns, which would happen on a schedule determined by us. But users were also getting individualized offers for upselling or as win-back offers on subscription cancellation.
"Dynamic Promotions" was designed to address those problems once and for all. The core idea was to provide an explicit configuration (instead of code) for any promotion we wanted to run. That would then be evaluated once for each user, and all decisions would be made atomically, persisted, and then seen as the source of truth for every other decision to be made. It worked by:
- providing a JSON-based configuration detailing the entire campaign or promotion
- gathering all the required user details to make a decision
- persisting that decision
- generating and scheduling all future communication (e.g. emails or push notifications)
This operation would either run as a batch job for all users or be triggered by events (e.g. "If the user purchases a maps package, offer them a discounted premium subscription for 2 weeks and send two emails"). The promotions would also contain details on the in-app communication, which was provided as an API to all clients so they could display messaging accordingly.
The entire system was built around some simple Lambda functions, DynamoDB for storage, and a pretty large AWS Step Function for processing all users and events in a common way. We also built in various testing capabilities, like a dry-run mode to validate entire campaigns or a testing CLI for our QA team to test individual promotions even without the need to execute the required user actions.
The system worked remarkably well and was over time adapted and expanded to more use cases and is still the main driver for promotions at komoot.
Handover to me
A few months after I joined, the other backend developer in the squad had to leave the company for personal reasons. While this would unfortunately leave me as the sole backend developer in the squad, we quickly figured out a plan for a good handover. For this, we sat together and assembled a list of all repositories, features, and documentation related to the ownership of the Monetization squad. Over a couple of months, I then dedicated multiple hours a week to study the code and docs in detail. Each week, we would come together, and I would walk through all the open questions. As a result of this, I then improved the code or docs in question by refactoring them, adding more code comments, or (re)writing documentation.
This process proved very effective, so I was able to take over the sole developer role in the squad without feeling I had big knowledge gaps. The improved documentation also proofed really useful when a new developer joined the Monetization squad since later on.
A/B tests
In the Monetization squad, we obviously had the goal to improve revenue. For this reason, we ran many A/B tests over the years, most of them requiring some form of support from the backend. Some noticeable tests we did are:
- Insurance removal: We experimented how to remove the bike insurance from the komoot premium subscription offering before actually implementing it.
- Different shop display: Depending on various factors, we experimented with showing the user different products as the first, big thing on the "shop" page. Either the user was shown the premium product first or the maps products.
- Price tests: We experimented with various prices for the subscription product.
Sales campaigns
At komoot, we ran various sales campaigns over the year. Usually, we would do a short one for the new year, one in summer during peak season, and then another one in early autumn. The campaigns were always involving different price points, user selections, and communication styles. Before we introduced the "Dynamic Promotions" system, we would often have to change or adjust backend logic to support the various ideas that the PM and designer came up with.
Insurance removal
The premium offering of komoot included bike insurance (backed by the German insurer AXA) at no extra cost. While the offer was always included in each subscription, users had to do some manual steps to activate it, most importantly provide their personal address since that was required by AXA. For this to work seamlessly, there existed a relatively complicated two-way sync between our applications and an AXA API.
In 2022, the decision was made to remove the offering from the premium subscription. This was relatively complicated because we had to make sure the offering was no longer included in new and renewing subscriptions while also making sure it would continue to work for any existing subscription that was created before a specific cut-off date. Because of that, the final removal of the code could only happen a full year after we stopped the offering.
Supporting new countries and prices
komoot classified the countries where we operated into different tiers. Tier 1 countries had full localization into the native languages and also prices were localized into the respective local currencies. In 2022, komoot added support for Poland, Brazil, Japan, and South Korea to the list of Tier 1 countries, so the monetization features all needed to support this. This was a particularly interesting endeavor since, while komoot never made the mistake of storing monetary values as floating-point numbers, all code did assume that all monetary values are stored in minor currency units (e.g., cents) and that every currency has 100 minor currency units for each major currency unit. An assumption that is not true for South Korean Won and Japanese Yen. That required a bunch of refactoring to make everything work properly.
Free experience and moving feature behind a paywall
In 2024, we wanted to make certain features a paid feature for new users. komoot generally tried to avoid taking things away, so this project involved figuring out where the various checks were made and adjusting them so they would continue to work for existing users but require a valid subscription for new users.
Paired with that, we also added the capabilities for a "free experience" for those features where new users could use them for free for a while but then are presented with a paywall and a limited-time offer for a subscription.
Smaller projects
Apart from the already mentioned projects in the Monetization squad, I was also involved in various smaller projects:
- Improving business events to the analytics team to add more information.
- Lots and lots of bug fixes.
- Enabling komoot team members to buy premium vouchers at a discounted price for family and friends.
- VAT and price-related changes.
- Automated refund process for subscriptions in our customer support backend with the click of a button.
Work in the backend team
While my primary role was inside the Monetization squad, we also had time to work on non-product-related things in the backend team itself. This was usually either done on "Quality Monday" or as part of the quarterly team OKR weeks where we tackle more technical topics that did not fit into the squads' mission. Some noteworthy examples of this are:
Hiring
In 2023, I also joined the hiring group for the backend team. Our hiring process involved a coding challenge sent to each applicant and then 2 separate interviews with 2 people each. The first, technical interview would focus on the technical capabilities, while the second was more focused on product and feature development. I was involved in reviewing challenge submissions from applicants and evaluating them against a set catalog of criteria and questions. I also was part of the group of people who handled the first, technical interview.
After each round of interviews, we four people would come together and make a group decision on whether or not we would make the candidate an offer.
Cookiecutter template
To shorten the time that is needed to spin up a new microservice or lambda function within the backend team, I implemented a Cookiecutter template repository for both use cases. This was based on an existing, simple template repository that would just replace placeholders, but that required a lot of manual work until the new stack could first be deployed.
I implemented two variations that also used a shared part to have a generator that could fully create two kinds of commonly used repositories:
- A lambda function with options support for SQS and DynamoDB
- An ECS Fargate-based service using ktor
Both templates were ready-to-use after generation, so they could be directly deployed (albeit without any functionality). I also added automated integration testing to the template repository that made sure that all possible variations would generate a valid project. The integration test also really deployed it into a dedicated AWS account for verification and called the resulting Lambda/ECS service.
Fargate migration of monolith
The central monolith of komoot had been running on plain EC2 instances for a long time. The scaling and deployment was managed via boxfuse. We decided to migrate it to an ECS Fargate service to be able to run more, smaller instances and to scale up and down faster, as well as reducing operation costs slightly.
This project involved setting up a new Fargate service for the monolith, implementing the autoscaling, migrating all metrics and alarms, and was completed without any downtime or user impact within a month.
On-call processes
I improved the processes around our on-call scheduling in multiple ways. I wrote a utility in Rust that would automatically detect upcoming conflicts between the on-call rotation and vacations entered in our employee management software, Bob. Those would then automatically be sent to the users which caused the conflict so they could take care of finding someone to swap with.
Late in 2024, we also introduced compensation for being on-call. For each day being on-call, you would be attributed time-off. These days could either be taken as paid time off or, if not taken, would automatically be paid out after 3 months. I implemented some Python-based code around this to fully automate the process of keeping track of earned time per user and also sending them over to payroll for payout.
"Backend-hub" documentation
The backend team had various documents scattered all over the place. From onboarding and generic setup instructions over on-call handbooks to other non-system-specific documentation. Most of it was in the form of Google Docs files, but then there were also presentations, README files, and various other resources.
I took the time to set up a dedicated hub for all backend-related documentation into a dedicated GitHub repository that is generating an intranet-accessible, MkDocs-based set of pages that can easily be navigated and browsed. Over time, I migrated over all the critical documentation together with the team.
API test migrations and improvements
komoot was originally using the Robot Framework for API-based integration tests. Over time, those became hard to scale, so years before I joined, the decision was made that new tests would be written as plain Python-based tests. I took the initiative to migrate most of the still-existing Robot tests over to the Python tests so we could benefit from better parallelization and also save the additional step in our CI pipeline. Most of the work was done in my first month, partly to familiarize myself with the existing API and functionalities, while the remainder was cleaned up over the years.
I also spent time on-and-off to stabilize the existing API tests by adding retry logic, fixing race conditions, and some odd bugs that always existed but only resulted in sometimes flaky tests.
Quality Mondays
At komoot, each Monday was dedicated to non-critical bug fixes and minor improvements inside the backend code. Each Monday, we would gather together in a Zoom call to look at bug reports (already prepped by our QA team) and metrics-related warnings from the previous week and try to solve them (or push them down into the product squads). The assignment of bugs was done by ourselves, so over the years, I worked on almost all parts of komoot in one way or another.
Work in the "Developer Productivity" squad
The "Developer Productivity" squad was formed as an initiative from within the backend team in late 2024. We all wanted more time to be spent on technical tasks that would benefit everyone. To facilitate this need, we formed this new squad with two developers as a mid-term experiment to see how viable that idea is.
Increase pipeline speed
The first task we tackled was an effort into the pipeline speed of our core monolith. It was quite a large application, so it had a huge number of unit, integration, and API tests. Running this pipeline for a fresh pull request would take over 45 minutes, while a simple production deployment was almost 30 minutes. Since a lot of time was spent working on this codebase by multiple developers, each minute reduced in the CI step would greatly improve overall iteration speed.
We spent some time making the general build faster by cutting off unnecessary steps, introducing more parallelism, and generally speeding up individual steps.
Another chunk of time was spent on making the per-branch stacks deployment faster. It originally was using database snapshots to create the two main databases for the application, which took a long time since the snapshots were quite large. We solved this by instead using empty databases and then introducing test fixtures to set up the database schema and content.
Overall, our efforts brought down the production deployment to 18 minutes and the branch-stack creation to roughly 22 minutes.
Feature flagging
My last task at komoot was implementing a feature flagging and experimentation platform for all applications and clients. Prior to this, we only had an in-house experimentation platform for A/B tests, and the backend had some remote feature flagging. We wanted to unify the feature flagging and experimentation on one platform and also provide a common, remote feature flagging solution to all backend services, the web frontend, and mobile apps.
For this, we deployed GrowthBook to our AWS account and integrated it with our data warehouse and event pipeline. I also added the integration to all relevant backend services, as well as providing support and documentation for the client-side integration.
Sadly, this project was never fully completed since in March 2025 komoot was acquired by Bending Spoons, which stopped all current projects and let go of many developers.