Lunch Automation for Developers: The Story of Kebab Wars

I enjoy dark rooms, dark themes and dark humor. 🧛‍♀️ Kebab enthusiast. 🥙 Physical therapy expert 🤕(🏍, ⚽, 🏂)

In Mews we often use phrases like bring hotels to the 21st century or join the revolution of the hospitality industry. One of our T-shirts has the catchphrase Automate this!. What differentiates Mews from most other companies is the way we truly mean what we say. Even internally. Hell, mostly internally. We often automate even in the most bizarre ways. One of these examples is the dev lunch group.

The problem

Back when I joined Mews (March 2018), there were only about 30 people in the Prague office. The usual lunch routine would be just groups of colleagues going to a restaurant nearby. As time went on, developers tended to favor getting their meals brought to them. However, our colleagues were not quite happy being thought of as mere delivery boys and girls to the devs.

Ordr time

So we experimented with services for delivering food, but the queue time around lunch was unbearable. Then we tried a cool company called Ordr. It was fairly simple: they have 2 meals and you get them within 15 minutes of ordering. The food tasted OK, a little worse than an average meal from a restaurant. The prices were a little above average. The portions were generally OK, sometimes a little below what we hoped for. But the delivery time and simplicity of ordering was far beyond anything else.

Some people complained about the quality of meals. Eventually they managed to persuade others to get a meal from the restaurant instead.

People don’t want to be lunch carriers for nothing… ⛔

Back to basics

So we picked a designated delivery boy among ourselves every day. There was no system. We just discussed which restaurant’s menu looked the best,  found out who hadn’t gone for lunch in awhile, and then that person went. As you can imagine, that’s a lot of talking  every day and we were being quite disruptive on many days. And while that annoyed some people in the office, that was not the biggest problem for me. The biggest problem for me was that we did not keep track of who was the delivery boy each day. And one time, a certain developer (coincidentally the same one raising the most complaints about the quality of food) refused to go, saying that he had some really important work to do. He also promised to go by the end of the week, which he never did. That made us realize that we need a system. And so I made one.

The glorious dev lunch system

We have a list of restaurants rated by points which are correlated to the distance of the restaurant and the type of food items ordered. The idea is that you pay the amount of points to the person that brought you lunch. Soup is considered half meal. So you want to choose a popular restaurant with a lot of points to get as many points per trip as possible.

The individual with the least amount of points is `assigned` to go for lunch. You can try to swap with someone or convince people to go instead of you but, in the end, that would only put your points total deeper into the negative. It is a point system built on peer pressure.

A system you can trust

While it doesn’t seem like a big change from what it was before, this creates an ecosystem that is completely objective and fair. You have no obligation to go for lunch when your points are low. It’s just that nobody will bring you lunch since you don’t return the favor. There is no talking your way out of it.

This new system meant that there was pretty much no further need for discussion. The person with the least amount of points created a slack thread with the name of the restaurant and the time and everybody just slacks what they want. Zero confusion, zero debates, zero noise.

Our system doesn’t handle money. For that we use an app called ‘Settle up’. It basically keeps track of who owes how much to whom. so the person who went for lunch paid and then put it inside this app.

Current problems

Manual steps

The technical implementation of this is a google sheet, where one sheet is keeping the historical data and the other sheets create the current lunch. I don’t want other people editing the history, so the main sheet is protected. Then I wrote a script for transferring the current lunch into the ‘totals’ sheet.

Main Sheet:

Fill today’s lunch sheet:

It is still necessary for some manual steps to be in place. These include:

  1. If someone forgets to fill in the sheet on time, I manually have to transfer the data to the corresponding column.
  2. Adding a new week to the table. I could script that, but it’s not worth the time.
  3. Adding new people.
  4. After every lunch, I have to click the Pizza Go Home button.

The reason for these is that the sheet is protected. Only #4 is actually a result of a bug in the google sheets scripts, because it crashes even just reading the values.


As you can see, this isn’t very scalable. We have a second person who is allowed to edit the protected sheet in case I’m not available, but ideally we wouldn’t need admin authorization.

There is also only one fillable form whose data will be transferred onto the main sheet. So if the previous lunch has not been transferred yet, you won’t be able to fill your lunch into the form. This makes having multiple lunches on the same day not so easy.

Issues we had and how we solved them


Just like any system, it only works if people believe it works. If multiple people stop using it, you get used to not putting the data in. So vacation seasons, special diets, or just home-made meals could potentially kill it. There was a time when there were only 3 of us using this system as all the other people started some sort of lunch box diet. This of course happened right after I was injured and had a huge negative point value. You can see in the main sheet above that my average points for delivery is severely lower than other people.

Inactive users

Another thing that can cause problems are inactive people. It’s natural to stop using a service, however, sometimes it’s the people in red numbers. Then a situation can happen when the 8th highest person is supposed to go for lunch. That can cause some doubts about the purpose of the system.

So I split the table into 2 parts. Above are the active users and below are  the inactive ones, so we don’t lose their info but they don’t pollute the ranking. This simple tweak suddenly changes perception of the whole system from `It doesn’t seem to work` to `yeah, makes sense`.

Fairness and trust

This fall we had an influx of newcomers to the development team and for some reason a lot of them like kebab (a food I’m quite passionate about). This resulted in an overflow of kebab lunches – sometimes more than once every week. Part of that is because I was again injured so every Wednesday I stopped there on my way from therapy and got kebab for people.

However, this meant that on some days it became a problem to form groups for the people not interested in kebabs. So technically it’s the same problem as the first one (Usage), except these people actually use the system. These people would then just go get food for themselves, thus they lose some points and then they have to go for lunch more than they would have to. Which might in the end make them not trust the system and stop using it altogether.

There are many types of glorious kebab! 🥙 


The third crisis we had was about money. As was stated above, the lunch system doesn’t solve the money issue. If you go to more expensive restaurants than others, you can get into a situation where you have a lot of points but other people owe you money. The whole settle up app is based on trusting that you can ask that person to pay their debt.

However some developers don’t like talking to people. Apparently not even other developers. They’d rather just stop using the system instead because the system “obviously doesn’t work” (still the same guy).

The God

So in a sense this experiment has proven some economical concepts for me. In order to make people believe in a system, I had to become an authority, guaranteeing that people will be forced to go in case they don’t have enough points. I also had to guarantee that everybody will get their money. So I am collecting the debt from everyone now and distributing the money to prevent anybody collecting debt that would make other people lose trust in the system. Thus I have reintroduced the concept of money. If you think about it, money also works only as long as everyone believes it does. Since I am the authority, I might as well just launch a cryptocurrency.

I’ll finish with a funny story. Our colleague Daria (read more about her here) actually believed for awhile that we didn’t use money at all and we only had the points. She thought it was awesome. When I found out, I explained the use of ‘Settle up’ to her. We realized that she was supposed to get around 3 thousand CZK from people she’d bought lunch for.

Future steps – LunchTime app

So what’s next? An app where you would apply for a specific lunch and everything is automatically stored in DB. If possible it would automatically charge your credit card. But at least store the money. You could see your history, you could rate a meal. We could even use AI to predict the meals you’d want. But that’s a bit too far out of reach. 😄

Maybe a cryptocurrency that would aggregate points and money into one. Then people could just go to restaurants only for profit.

Now, looking at the context of your company, what more can you automate? Feel like automating stuff with us? Apply here!

Photo © Natalia Bubochkina.

I enjoy dark rooms, dark themes and dark humor. 🧛‍♀️ Kebab enthusiast. 🥙 Physical therapy expert 🤕(🏍, ⚽, 🏂)

More About &