Everyone needs groceries, but not everyone has the time to wander the aisles of their local supermarket tracking down the best brands of sauerkraut. That’s where Flink comes in. Flink is one of the largest third-party delivery services in Europe; an online-only grocer with over 100 warehouse locations in 60 cities across Germany, France, and the Netherlands. If you can get it in person at the supermarket, you can have it brought to your door in minutes by Flink.
Founded in 2020 and having already grown to thousands of employees and 10 million customers, Flink is a massive, rapidly expanding organization. Their iOS and Android teams, however, are lean, with 12 engineers responsible for four apps: one for riders (their name for delivery drivers) and one for customers, both built natively for iOS and Android. With millions of people relying on Flink’s apps to receive deliveries to the right place at the right time (over 90% of their total orders are submitted via mobile), their mobile teams have a lot of responsibility on their shoulders.
“Whenever your week came around and it was your turn to be the release manager, it was a dreaded task that you didn’t want on your own plate — but would feel too guilty to push onto someone else.
Jawad Mashhadiea
Senior Android Engineer
As Flink rapidly grew, it became clear they needed to establish some sort of schedule for releases. It wasn’t feasible to do them every day, so they settled on a biweekly cadence, alternating between Android one week and iOS the next. Timing-wise this worked well for QA, too, as they could alternate their regression tests: iOS one week, Android the next.
But the execution of these biweekly releases was not so simple. The number of steps were enormous, requiring hours of manual work to get done.
Flink set up a release rotation, and to help guide each engineer when their own time arrived, they created a document (well, two docs: one for iOS and one for Android) to act as a runbook for everyone, with a checklist to guide them through all the many, many steps towards release. The idea was simple: when it’s your turn to be the release manager you can just open up the document and go through it step-by-step. But it was not so simple and absolutely no one looked forward to their turn.
“At some point we realized our release runbook just kept growing. There were so many manual steps and communication was not working well, with constant back-and-forth around code freezes, release candidates, regressions, delays, and nearly every other part of the process.”
Andrii Snitsaruk
Staff Mobile Engineer
The release manager wasn’t just checking off a series of technical steps, they also had to manage every single person’s expectations and communicate progress (as well as delays and issues) with not only the mobile engineering team, but also QA, PMs, and leadership — all while attempting to provide the exact right amount of detail so those folks would have the necessary context to do their own work. This required fielding tons of questions while attempting to get back to the actual process of managing the release.
Flink engineers began looking to write their own scripts, hoping to start with small steps like automating the release kick-off. However, even such a seemingly simple task wasn’t easily solvable with the tools available to them.
For example, they needed to kick-off a code freeze every two weeks per app, but their CI tool only supported weekly scheduled builds. This meant that if they wanted to automate the code freeze, they could only write a script that would fire weekly but would only work one time out of two because they needed a bi-weekly code freeze kickoff.
It became quickly apparent that automating their mobile release process would require them to build most things from scratch. This would require a lot of time and resources, something that would perhaps need a separate team to work on full time. With the pace of feature development at Flink, it was clear this wouldn’t be feasible in the near future.
“After reading the book Building Mobile Apps at Scale, I discovered that big companies tend to build their own implementation of release trains. I wondered if there's any SaaS solution that could provide this, but Googling didn't give me any results. (Looking back I think I should have searched better because Runway already existed at that time, it was middle 2021 😄).”
Andrii Snitsaruk
Staff Mobile Engineer
So they couldn’t easily fix things on their own and they also couldn’t just stick with the status quo. Well, they could, but app quality would suffer, engineers would be more stressed out, other teams would feel more left out of the loop, and fewer features would ultimately be shipped. No one would be happy with this status quo.
Each failing script, problem, or other slowdown was accompanied by its own pile of necessary communication to ensure everyone’s now delayed tasks could be properly coordinated. Release managers didn’t just have to deal with the problems, they had to individually reach out to each person who was impacted by any delays and then keep them updated on progress.
For these reasons, their attempts to stand up their own solution did not generate the sort of time savings they needed. Every single release still took anywhere from half a day, to an entire one. With four apps being shipped every two weeks, this meant anywhere from eight to sixteen hours of an engineer’s time every single week was focused on an unnecessarily complicated process instead of on improving Flink.
That’s when Flink discovered Runway.
“From day one when we saw our first Runway demo, we felt convinced that it would solve most of the issues we were seeing. And it has.”
Aya Akl
Staff AQA Engineer
It took only a short trial for Flink’s mobile team to see how much Runway would improve their lives. And they quickly convinced leadership to pay for the platform simply by comparing the cost of up to 800 engineering hours per year to a less expensive, easier solution.
“Once we started using Runway, so much time was given back to us. We now spend that time on feature development, we spend it wiping out tech debt, we spend it on work that is directly beneficial to Flink instead of getting bogged down on tasks that can be automated.”
Jawad Mashhadiea
Senior Android Engineer
A complex and dreaded release process became a simple one.
With the press of a few buttons (or none at all), Runway handles:
“As a release pilot, you're literally barely even involved anymore. All that extra work is just gone, and the time is given back to you and your development work.”
Jawad Mashhadiea
Senior Android Engineer
On top of doing away with virtually all of the individual, tedious steps previously taken by release managers, Runway has also simplified:
Communication with each and every stakeholder. No more jumping around a dozen or more Slack conversations trying to keep each person informed of exactly what they need to know — instead, whoever is managing the release can simply hit a button in Runway to ping any relevant person about where things are currently at and whether anything is needed from them.
Onboarding. Previously, new folks would have to suffer through learning and then attempting to recall every step of the process — and more experienced team members would have to invest their own time educating and assisting. Now, team members can be part of the release pilot rotation almost from day one.
What does this all add up to? Hundreds of hours saved from unnecessary work, while engineers, QA managers, and product folks get to keep their sanity.
“If we didn’t have Runway, I guess I would quit. (Joking!) But seriously, it would take us back to where we were a year ago: desperately needing to figure out a way to fix things ourselves. We’d be in trouble.”
Sergio Liñares
Senior Android Engineer
