Many years ago I walked into a successful local restaurant and asked the owners if they needed or wanted help with their website. Turns out my timing was good because their last guy had moved on and they needed help. So I took over the website for The Schwarma Co. I had been running it for quite a while, and then Covid hit. I watched them struggle to stay open, like all restaurants. That’s when I seriously started looking for an online ordering system for restaurants.

What is required for a restaurant online ordering system?

Restaurants have very specific needs when it comes to online ordering — you can’t simply use any ecommerce solution. For starters, restaurant menus always give people options when ordering. They also offer extras or “upsells” like chips and cooldrinks. So when adding menu items, you need to accommodate infinite options, with their pricing effects too. And it can get seriously complex, as I learned with The Schwarma Co.

Then there are the orders themselves. You need to handle both takeaway (collection) and delivery. And delivery can be complex. Some restaurants charge for delivery, others make it free over a certain amount. Deliveries might even have to be scheduled. And they certainly all have a maximum delivery radius! This requires a robust ordering system.

Lastly, there’s the actual order receiving at the restaurant. Every business uses a different POS system, and either integration is expensive or it’s simply not an option. So we needed something system-agnostic. This is the main reason we developed our own mobile app to handle orders and printing. Something we could offer for free, which connects to a printer you can buy off Takealot. Something restaurants could set up and manage themselves.

The challenges of building an online ordering system like Resto

Finding the right software was the first step. For me it had to be WordPress-based and open source, so I could adapt it to my needs. I found the perfect solution with WooCommerce and a couple of other choice plugins. But even that wasn’t enough, because nothing is perfect. A few amazing custom WP functions later and voilà — a complete online ordering system for restaurants.

Luckily I had a trusting client in The Schwarma Co, and after Covid they saw the benefit of having an online ordering system in place. So I got to test it with them. Setting up the software was a bit of a challenge, but this is what I do, so it was fairly easy. The next challenge was getting orders to auto-print at the restaurant. After extensive searching I found a guy selling a device that would auto-print the orders. I convinced my client to buy one.

We got a Raspberry Pi device with a paired Bluetooth thermal printer. It came with instructions which I managed to figure out, and soon we had it connected to the Wi-Fi. The right order email address was set up, and it started working.

This was great — until it stopped working. Then I discovered the real issue: support. To get help I had to reach someone in Romania, and then network the Pi device so he could connect to my PC to fix it. First time it broke he fixed it quickly. Second time, the flash drive had fried (I didn’t even know that was possible until then). I had to prepare a new mini SD card and let him reconnect to set everything up again. What a mission.

That experience taught me a few things. I needed to manage the device myself, and since I didn’t understand Linux, Raspberry Pi wasn’t a good option. Another issue with Pi devices is visibility — you need to connect them to a monitor just to see what’s going on. I had to bring it back to my office, hook it up to my HD monitor (normally used for my security cameras), and use a mini keyboard to interface with it. Not a great solution. I needed something I could manage more easily.

So I worked out how to re-create what this guy had done on the Pi, but on a small Windows laptop. In simple terms, I used an email client called Thunderbird with two add-ons: FiltaQuilla and PrintNG. Orders were sent by email to a specific mailbox. Thunderbird checked for new emails every minute. A FiltaQuilla filter looked for a specific string in the subject line, and if it matched, it automatically printed the email content using PrintNG. The laptop was Bluetooth-paired with a thermal printer set as the default.

I set this up for The Schwarma Co and it worked, but we discovered several issues. Luckily my client was understanding and let me refine the system on their live orders.

An almost perfect online ordering system

This is where Resto was born. The system was ready to roll out to more clients — but I quickly realized a new problem. If you supply a device and it has issues, people expect you to fix it. I started getting regular support calls, and it became clear this wasn’t scalable long term. I needed something better — something I could give to clients for free, that they could install and manage themselves. Something bulletproof (as if that really exists). The solution was obvious: a mobile app.

So I built the first version of the Resto mobile app (with a ton of help from ChatGPT, to be fair). It was a simple Android app that connected to a Resto shop and its locations (if multiple). It checked for new orders every 30 seconds, and if it found one, it would auto-print via a paired Bluetooth thermal printer and play a sound. Super simple — and it worked. I went around replacing laptops with Android tablets, and suddenly I stopped getting support calls.

The app worked, but wasn’t perfect. My client gave me a list of improvements, and the codebase needed upgrades. My dev team in India helped refine it. But another issue came up. As we added more restaurants, each device was hitting the API every 30 seconds. On the same server, this added up quickly. That’s when version 3 began.

Resto version 3

This version is different. Now, when you install and set up the app, it registers itself on our web app with its associated restaurant (and location if applicable). We use a webhook to send order info from the shop to our web app. The web app then pushes a notification to the device saying: a new order with ID xxx has been received. The app then calls the shop API to fetch the order details and auto-prints it (with a loud notification sound).

This all happens almost instantly. So instead of an API call every 30 seconds, we only make calls when needed. Much more efficient use of server resources. But is it truly bulletproof?

Is there a foolproof online ordering system for restaurants?

That’s the million-dollar question! I want to say yes — but after extensive live testing, I can only claim about 99% effectiveness. Occasionally, an order doesn’t print. But it’s not a code error. If it were, it wouldn’t work most of the time. The reality is that this process relies on many moving parts, and there are lots of places where something can go wrong. One connection times out and the whole process breaks.

Of course, we build in redundancy and loops to catch missed orders, but the truth is: with so many different parts interacting, things will go wrong — usually at the worst possible time. Still, I can say we’re very close to perfect. It has taken time and a lot of trial and error, but the system is now reliable enough that every client tells us it’s the best thing they’ve added to their restaurant operations.

Online ordering suits today’s customers. It also frees up the restaurant phone for what it’s really meant for: solving problems, not taking orders. I’m proud of what we’ve built with Resto, and I know it adds value to restaurants everywhere. From case studies, I can show that our system directly helps increase takeaway orders.

This is the story so far. I hope you’ll join us on the journey — together we can grow your restaurant sales.

Looking forward to meeting you,
Douglas Hoseck
Owner, Founder & Developer of Resto