Goxo: The pandemic adventure, a story of technological transformation

Before we begin, a small disclaimer: this series of posts is based on real events from my professional career, set four years ago in a very, very distant technological landscape. Get ready for an uncensored look at the technical decision-making process, where the past meets the present and many lessons await. Buckle up for an unforgettable journey!

It all began at a Christmas dinner in November 2019, where the team of collaborators from the then social network Goxo gathered to say goodbye to a year full of challenges and learning. Those learnings led to the conclusion that we had to transition from being a social network for “foodies” to becoming a white-label platform for restaurant digitization, or as we liked to summarize it, the Shopify for restaurants.

But a key piece was missing. The first step to achieving this value proposition was to have a home delivery module via a logistics provider, so I spent Christmas 2019 developing a small piece of software that did just that, a set of methods that, when invoked in a specific order, would get a restaurant’s order to a customer’s home.

Over time, Goxo’s new value proposition came to have four main pillars to help restaurants grow their online businesses:

1. Digitization of direct channels for restaurants personalized with their own brand image, i.e., a website and a mobile app with their adapted look and feel.
2. A complete home delivery service.
3. A platform to understand your business data through digital channels, with a series of dashboards and tools that allowed restaurants to retain their customers, improve their sales (e.g., upsell), and personalize the service for their users.
4. A set of niche marketplaces where several restaurants with common characteristics were aggregated, for example, those housed in the same shopping center.

With the new module in production, we started to gain our first customers and saw light at the end of the tunnel. After much effort, we managed to monetize our project. However, March 2020 arrived, bringing with it the COVID-19 crisis that forced all restaurants to close their physical locations, and therefore, their main sources of revenue. But, surprise! Those who had their digital channel available could continue to serve their customers. The digital channel had become the only way for their business to survive amid such uncertainty.

Due to this event, our sales skyrocketed massively. In my product classes, we often talk about product market fit, and I like to summarize it with this capture, that hockey stick-shaped graph where you go from 0 to 100 in hours.

This massive success also forced us to scale accordingly from a technological standpoint. Remember that from a technical point of view in Goxo’s value proposition, for each customer we had to:

1. Generate a website with the customer’s brand image in less than 24 hours.
2. Do the same but in the form of a mobile application for Android and iOS.
3. Add a flexible dedicated infrastructure with its own domain for this customer.

The technological starting point I had inherited for historical reasons from other collaborators was a bit disheartening:

1. Infrastructure: 2 virtual machines hosted in GCP, one with the database (MongoDB) and the other with about 15 MERN microservices. There wasn’t even a pre-production environment, no tests, and continuous integration and delivery processes were non-existent. Additionally, there was a single mobile application from the Goxo social network that needed refactoring.
2. Team: an expert consultant in mobile application development and myself, who at that time was primarily working in the strategy department of Orange, but that’s a story for another day.

Given this situation, here is my first lesson I want to share.

In technology, you have to prepare to feel completely incompetent but still be functional.

We were faced with a series of technological challenges that were difficult to tackle: how were we going to…?

1. Scale the database and microservices.
2. Scale our capacity and our skills.
3. Productivize the mobile applications.
4. Create web applications as similar as possible to the mobile ones.
5. Scale the administration and billing processes.
6. Exploit the data.

In this entry, I will not explain how we solved all the challenges, but I will give some brief insights on how we tackled some. In future entries of the series, I will continue to discuss the most relevant ones. However, if you are curious or want to comment on any of the challenges, please write to me.

Let’s start with how we tackled the first challenge, scaling the database and microservices. Like any good problem, this one had a multi-causal basis, which we approached from several fronts.

First, increasing the team’s bandwidth. Since we didn’t have much money, we decided to look for a part-time DevOps person to help us about 10 hours a week. This was a success because I learned a lot from this person, and it allowed us to retain knowledge within the organization, as well as laying the foundations for good DevOps practices.

We jointly established a platform modernization plan, and as part of that plan, we decided to containerize the workloads to run them on a managed Kubernetes (GKE) service that would give us the flexibility and granularity needed to focus on delivering platform value. The technology itself allowed us to have templates for deploying various services, using components like Helm charts, the kustomize artifact, etc. But above all, what made the difference was a good organization of the various pieces in the file structure. I’m omitting some technical details to simplify the text, but if you’re interested, please write to me.

We did this migration to GKE relatively quickly; in just under two months, we had at least the basics working. However, we were not exempt from problems along the way. A big mistake we made was not addressing the scalability of the database much earlier in the modernization process because we thought it would withstand the service escalation (or at least that’s what our monitoring tools told us). Basically, what happened is that the database machine died. I remember perfectly that it was on Mother’s Day, in the middle of dinner service, and we spent several hours relaunching the system, which had an impact on our customers and, by extension, on our bottom line, specifically a 10,000 euro impact.

Another lesson I learned from this adventure is that a decision is not good or bad based on its outcome, but on the decision-making process itself. I still believe that the decision to do the migration the way we did it was the right one. Now, in hindsight, I might have paid more attention to the database, but I think doing it the way we did allowed us to have an understanding of the other pieces that later enabled us to recreate the database in a short time.

The next challenge I would like to discuss is scaling our capabilities and knowledge. In this regard, we used a small round of funding (FFF) to hire a small development team:

• A mobile developer for React Native.
• Two senior full stack developers.
• Two junior front enders.
• A UX/UI designer.
• Increased DevOps hours.

We also went to universities and bootcamps to hire some interns.

The important thing about this challenge is not the composition of the team itself, which obviously has to reflect the needs and strategy of the company, but how, with a limited budget, to hire talent and do super-fast onboarding because every minute counted.

To do this, it was essential to establish an attractive employee value proposition. In our case, we leveraged remote work quite a bit to hire workers around Spain with very competitive skills at competitive prices.

We achieved onboarding speed by combining a good knowledge base, in the form of a wiki we made with Notion, and spending part of my time helping to make onboarding smoother during the first few weeks.

The lesson I learned in this aspect is that you have to give the team autonomy, encourage their way of working by providing them with tools that improve their knowledge of the problem and allow them to learn, and give them a purpose to achieve within the organization.

In summary, in this journey through the transformation of Goxo, from a social network for foodies to an integrated platform for restaurant digitization, I have recounted some of the challenges and lessons learned in technical and strategic decision-making about the company’s future. The COVID pandemic played a crucial role by forcing restaurants to rely on digital channels, which boosted Goxo’s growth. Technological scalability and building an agile and well-prepared team were essential to seize this opportunity. It’s important to understand that in technology, the decision-making process and adaptability are as important as the final result.

In the next entry, I will focus on how we tackled the challenge of scaling mobile applications, especially their continuous integration and deployment. We will also see a thinking framework for analyzing challenges and proposing solutions, using the example of how we developed the web application by cloning the mobile application’s user experience.

I hope you enjoyed this entry. See you in the next one, see you next week!