Having the product ready did not mean the restaurant was ready

On September 24, we brought Restoman to Bibi’s, our first client.

After years of developing, testing and presenting the project, we were going to see it work in a real business. But that first night, we could not use it as we had hoped.

A specific workflow

We were not going to implement everything Restoman could do at once. Bibi’s would use it for takeaway: the customer orders from the web menu, pays through Mercado Pago and picks up when the kitchen has the order ready.

You can explore Bibi’s menu.

It was a specific workflow: order, payment, kitchen and pickup. The launch had to show that this worked at the restaurant, not just in our tests.

What surfaced that night

We were at Bibi’s throughout the implementation. While the staff prepared the kitchen to welcome customers, we were finishing the details of the restaurant’s setup.

The bugs surfaced when Bibi’s manager tried to sign up. At that moment, the API went down for the first time, before any customers had placed orders. We did not have a confirmed cause. We fixed the bugs that surfaced during the implementation right there at the restaurant.

But the obstacle that first night was not just technical.

Bibi’s was going to accept only Mercado Pago. The restaurant’s account was not connected yet; it was connected later that night. Without that step, we could not complete the workflow we had come to set up.

Having the integration in the product was not the same as having payments ready for that restaurant.

The launch was part of the product too

Until then, we had made many decisions by imagining how a restaurant would work. At Bibi’s, we began to encounter the actual conditions of one.

It was not enough to have the menu, checkout and kitchen screen. We needed to arrive with accounts created, permissions set correctly, payments connected and the complete workflow tested on the devices the staff would use.

For the next restaurant, that needs to happen before launch day:

• Connect and test the payment method.
• Prepare accounts for the people who will operate the system.
• Test the kitchen screen on the actual device.
• Complete an order from start to finish, including pickup.
• Decide who responds if something fails.

This is not a list of new features. It is what makes the features we have already built usable.

What I took away from that night is that seeing something work once is not enough. We need to arrive with everything thoroughly tested, think through what could fail at each step and have a plan for how to keep going if it does.

Even then, something can break. Being prepared also means having the tools, access and knowledge to fix it on the spot, rather than starting to figure out what to do when the restaurant already needs to operate.

Bibi’s was our first client, but also the first place where we had to learn that difference: the product does not end when it works on our computer. It has to be able to start working on the restaurant’s.