Project Description Project Description

Project Description

The project analyzed in this case study is a mobile application for a Danish food delivery company operating on a national scale. The platform also has a web version closely connected with the mobile app and duplicates its functionality. The company’s network includes thousands of Danish restaurants and counting. Founded in 2012, our clients have focused on collaborating with local restaurants and diners, making takeaway highly accessible for the community.

Implementing the right technical decisions enabled successful scaling to become a nationwide Denmark food delivery and unite thousands of Danish restaurants under one hood.

  • flag Denmark
  • flag Food delivery


We started working on this platform back in 2019. At that time, our customer's main problem was failing to manage a quickly rising amount of orders they began to receive.

The software our client has been using over the years started to degrade for many reasons:

  • Maintenance had become a nightmare as the system lacked monitoring. It was hard to understand what was happening and impossible to foresee an issue before it hit the system.
  • Food delivery has become popular these days, and increasing order numbers loaded the system up to its capacity. Instead of benefiting from an increased income, we suffered from downtimes, memory issues, and long-lasting response times.
  • The software itself has grown old, and to cope with modern use-cases, it needed a complete upgrade and redesign of some old-fashioned approaches.

The used tech stack was: Python 2.7, Django 1.2, Flask, HTML, CSS, JavaScript, Backbone.

To get rid of the legacy code and skyrocket the app's performance, we've decided to make the following changes: Python 3.8, Django 2.0, REST, PostgreSQL, AWS (S3, Cloud Watch, Lambda, SNS, SQS), HTML, CSS, JavaScript, ReactJS, NextJS.

Business needs image

Solutions Solutions

It took around six weeks to analyze the project properly. Even though some of the main issues were obvious, we conducted detailed research that showed us weak spots hidden deeply in the code and the app's architecture.

Project duration:
  • flag 2020-present
Team composition:
  • 2 senior Xamarin engineers
    flag javascript
  • 4 back end developers
    flag Python
    flag Django
  • flag Python 3.8
  • flag Django 2.0
  • flag REST
  • flag PostgreSQL
  • flag HTML
  • flag CSS
  • flag javascript
  • flag ReactJs
  • flag
  • flag AWS
  • flag S3
  • flag Cloud Watch
  • flag Cloud Watch
  • flag SNS
  • flag SQS

Initial Tech Upgrade

While analyzing libraries and frameworks, we have identified that the Django framework would drop support of the version we are using in just a few months. So the roadmap has been built as follows:

- Removing unused code to make the upgrade easier. The project has been in development for many years and has accumulated some amount of obsolete code.

- Fixing existing issues so they do not bother us during the upgrade.

- Performing a complex upgrade of the underlying framework and all of its dependencies. This part took us two months of work and more than one million edits.

We delivered it ahead of time to make sure we could validate the upgraded version and promote it to production before the current version support drops.

Fixing Flaws in the Platform's Design

Food delivery was not as popular back in 2012 when the first order landed in the system, so it wasn't designed to cope with the load we get nowadays, as it should be able to process thousands of orders per hour.

We have broken down the data flow in the system and added a series of improvements that gave us the desired performance.

Here is what we did:

- Implemented caching for long-running operations and heavy calculated data.
- Switched to fast solutions, like MongoDB and memcached.
- Introduced queues for long-running tasks, reducing the load on the order processing queue.

Getting Monitoring Back on Track

It was hard to maintain this project as it lacked key data to track the performance. We could only tell that something was wrong when the system halted, and we had a critical issue to fix. However, with proper monitoring, we could see it coming and prevent it without any downtime.

The proposed solution was to use Amazon Cloud Watch, which gave us new possibilities:

  • Store all logs in one place.
  • Query them using Cloud Watch Insights, an excellent analysis tool.
  • Use metric KPIs to notify the team when something is off.


Working on a complex upgrade and redesign while keeping the platform fully functional is a challenge itself. Naturally, we had to address all possible problems like code compatibility while migrating from Python 2.7 to Python 3.8, running the Python upgrade in parallel with the ongoing development, as well as making sure there were no conflicts between Python and the libraries we used. Apart from that, the app used an old version of the 3rd-party service for invoicing.

Python Upgrade

While switching to a newer version of Python, you have to keep in mind that even though most of your code will work well, critical syntaxis-related bugs are inevitable. There was a difference between how we used the updated Django 2.0 and how the previous version of Django 1.2 was used on the project, so we were extra careful while merging. The main challenge here is that there is lots and lots of code, and you have to process all the amount to know where and which changes you have to make.

Combining the Python Upgrade with the Ongoing Development

A living and quickly developing business cannot have the luxury of putting the platform on hold for a technical upgrade. We had a team working on Python migration, but there were also teams focusing on the ongoing development, and we had to keep up with them as well. Receiving the new code and merging it takes patience, preciseness, and maximum attention to detail when overlooking even a minor code conflict can start a chain of system breakdowns.


We have lots of libraries used on this project, and all of them have regular version upgrades. Each library version supports a certain version of Python and a certain version of Django. And you have to make sure that all the libraries are mutually compatible with each other. In the context of Python upgrade, the core challenge was to ensure that we make appropriate changes in each updated lib’s code, so it works adequately and correctly with Python 3.8 and Django 2.0. Which was quite a number of dependencies to look after, to be honest.

Dealing with Invoicing

The impressively complex logic behind the invoicing process was written many years ago, and it is integrated with an old version of the Economics Service. At this moment, Economics has released newer and better versions, but the project is tied up to the older one with much more limited functionality. With a little help of brainstorming and creativity, we came up with writing some custom code to combine this current Economics version with the upgraded libraries.

Results Results

It took around six weeks to analyze the project properly. Even though some of the main issues were obvious, we conducted detailed research that showed us weak spots hidden deeply in the code and the app's architecture.

Increased Order Flow & Restaurants Network

Helping the platform process the snowballing amount of orders that landed into the system was one of our top priorities throughout the whole upgrade. If we talk numbers, the order flow has increased up to 40%. The peak amount of orders we used to receive on New Year’s eve, is now a regular workload that is processed without any crashes. Collaborating with a stable and convenient platform is lucrative for many restaurants, diners, virtual kitchens, and other food service providers. No wonder the app network started and continues to grow, operating now on a national scale.

Usability and User Experience

Consistent and thoughtfully implemented application upgrade removed crashing, errors in order processing and speeded up order flow as a whole. The change was immediately noticed by the users leaving positive feedback on their ordering experience and leading to more and more people relying on Hungry to deliver meals on a daily basis.


Platform maintenance has transformed completely. Now we see all the logs (and it wasn’t always that way), we know exactly what is happening to our product at all times, and this allows us to fix bugs sooner than anyone even reports them. Supporting the app is now much easier, and effective maintenance was the thing the app used to lack but always needed.


You may also likeYou may also like