Sometimes It’s Worth Building from Scratch! — A Flink Netlight Success Story
Software-as-a-Service (SaaS) solutions have a simple but powerful premise: Why reinvent the wheel? Or, why build your own Delivery Platform when others have figured out the problem already and can make it available to you for a fair price tag? This article is about Flink, a Berlin-based grocery delivery startup, and its journey from hyper-growth using SaaS solutions, the bold decision to build its delivery platform new, and the lessons learned on the way.
What is Flink?
Imagine this: You’re at home, scrolling through your phone when you suddenly realize you’re out of groceries. You don’t have time to run to the store. What if you could have groceries delivered to your doorstep in minutes?
That’s where Flink SE comes in, a German on-demand online grocery store that brings everyday items directly to customers through its fleet of riders on bikes.
However, Flink was not alone. In the midst of the pandemic, London-based Dija and Weezy, France’s Cajoo, and Berlin-based Gorillas emerged, all focused on fast delivery of fresh food and groceries to customers. This gave rise to a new industry: Quick Commerce. And just like the delivery itself, the technical systems supporting it needed to be built quickly. One of the most challenging aspects of Quick Commerce is the Last Mile to the customer.
The Last Mile Challenge
To establish an efficient digital Last Mile Platform, several components are necessary. At the core is the dispatching system that tracks all activities at the delivery hub (i.e. dark store/warehouse) and provides real-time updates to customers and Flink staff. This system is responsible for dispatching orders to pickers and assigning trips to riders. Each trip may consist of multiple orders, categorized based on their delivery locations to improve rider efficiency.
Riders require a convenient mobile solution that they can carry with them to know where to deliver each order. A mobile app with features such as order management, routing, account management, and the ability to call customers in case of unclear delivery destinations is the logical choice.
Each Flink delivery hub has a manager overseeing operations. This manager needs an overview of the current order queue to be picked up and delivered by bike, as well as information about the location and status of all delivery riders. To manage the order dispatching flow and ensure a swift process, a hub-specific dashboard is necessary to visualize this information.
With these three core components in place, an efficient last-mile business can be operated.
Developing these components requires time — a luxury Flink did not have, with competitors sprouting up rapidly. Fortunately, others had figured out the last-mile delivery to the customer already!
Delivery as a Service
Instead of building multiple backend and frontend components yourself, one can buy end-to-end software setups as white-label solutions from a third party. Great! Why reinvent the quite literal wheel to the customer — when others have done this already?
Of course, not everything comes out of the box. You still need to make sure that incoming orders are sent to the third-party and proxy updates on the delivery to the end customer. But instead of having multiple different services with their own matured business logic you will need just a few simple integration services.
The integration services were spawned quickly and the race to attract the most customers could continue. Things were good for a little while, but soon the other side of the coin of buying third-party services was showing.
Limits
In the beginning Flink was a growing company and it was all about creating core functionality — things that any delivery service needs: How to transport items from point A to B in a fast way. However, with increasing maturity, Flink developed more specialized needs. For example: How to deliver to points A, B, and C using the same rider, optimizing the routing between the different points while keeping the promise to the individual customers. SaaSs typically have multiple clients and therefore care about important universal use cases but not about the difficult but impactful narrow ones. At Flink, we realized that more and more of our features tested the limits of what third parties had to offer.
Another big issue that became clearer the longer the SaaS solution was in place. We had no way to counter outages at the SaaS provider. When incidents happened engineers could do nothing more than wait and hope for the SaaS company to resolve the issue as quickly as possible. Long delays in product deliveries can result in significant financial consequences, making this situation particularly challenging.
Last but not least, most SaaS solutions are paid by usage. With a growing end-customer base and increasing order volumes, the costs increased as well.
All these points combined made it clear that we had to look out for alternative solutions to the Last Mile challenge.
Make it New
Flink took the decision to build the Last Mile Domain from scratch. For that, the team went to the drawing board to figure out which parts needed to be built and which parts were already available to them.
Flink had already built up a strong platform team for creating a developer self-service system to easily set up new frontend and backend services on top of a Kubernetes cluster running on the Google Cloud Platform (GCP). This enabled teams to quickly spin up new services and focus on implementing business logic rather than having to deal with questions of infrastructure or continuous integration and deployment.
The problem field was divided into the following four areas: Rider Management, Fleet Management, Order Fulfillment, and (Order) Dispatching and mapped to development teams.
Rider Management Team is responsible for everything around the Rider, from managing user accounts to tracking their status (e.g. available, en-route, etc.) as well as distributing tips given by customers.
The Fleet Management Team handles the organization of the bikes, which includes features like; locking, unlocking, and maintenance scheduling.
The Order Fulfillment Team owns the entire flow from the order being picked up by the rider to being delivered to the customer. This includes different topics like order assignment, routing, customer communication, and location tracking.
The Dispatching Team implements the leading system to register incoming orders, bundling them into trips and sending them to the fulfillment system.
Furthermore, since the last-mile process is a flow of orders it was natural to opt for an event-driven approach. For all event messaging, we used GCP’s Pub/Sub, allowing teams to easily publish typesafe gRPC messages and subscribe to them with multiple different services. Enabling fast and parallel development on the bases of well-defined schemas.
Go-Live
Working in two weeks sprints and in constant exchange, the teams moved closer and closer to the planned go-live day. There were two things that helped teams to stay aligned. First, weekly syncs by engineering and product leads, making sure that action items on the roadmap are matching the progress of the other teams.
Second, a strong QA team started testing from early iterations and made sure that none of the existing features using the third party were missed.
Lastly, it was time to take the final step, testing the app on production in a real hub. The day of the go-live was full of existing, last-minute bug fixes and lots of joy and celebration — definitely worth an article on its own. In the end, we kept the hub running on the new last-mile platform for the rest of the day and beyond.
After that, we gradually rolled out the system first in one city and then over the period of a week globally in over 200 hubs. In the end, from the project kickoff to the rollout in all hubs (200+) in four countries it took only five months.
Last Thoughts
Using a third-party Delivery Platform allowed Flink to stay in the race of Quick Commerce competitors in the heated pandemic years. However, SaaS solutions can be a bottleneck in terms of the pace and customizability of your product features. Additionally, with a growing user base, the costs of SaaS can grow excessively. As a result, Flink took the decision to in-house their Last Mile Platform, despite a high initial investment. In the end, it was an investment well-placed. The in-housing project laid the foundation of a new engineering domain within Flink and planted the seed of a new engineering culture that has spread to other domains since. It also unlocked a new set of features that are only possible when owning the complete Last Mile process end to end. In software engineering, we are used to making incremental improvements to existing systems. However, sometimes the bold move is needed. Throw the old out and make it new!
Last bust not least, I would like to extend my sincere appreciation to Jonas TM and Daniel Zibion for their collaborative efforts in bringing this article to life.
