Last week we talked about the pandemic adventure at Goxo, where we saw how important it was to embrace uncertainty to be functional in situations where everything is yet to be built. We also discussed the importance of having a good decision-making mechanism and that there is an element of luck in almost everything we do. Finally, we emphasized that a technology and product team needs to have autonomy to work their magic and that, in all of this, your mission as a leader is to provide them with that compass in the form of a purpose towards where the organization’s vision is headed.
In this new entry, I will discuss how we solved some of the scalability challenges of the business from a technological point of view, especially related to scaling the creation of mobile applications. Let’s get to it!
Productivizing Mobile Applications#
The first challenge we faced as we gained clients was “productivizing” mobile applications. Remember that for each client we had to deliver an iOS application and an Android application with the client’s personalized branding in less than 24 hours. The long-term vision was to have a self-service mechanism in the form of a web portal so that the client could configure this personalized branding: primary and secondary colors, splash image when opening the application, etc., and once selected, a mechanism would trigger the upload of the applications to the Apple and Android app stores respectively.
Challenge of Programming Languages#
To tackle the issue of programming languages, the accumulated knowledge from our time as a social network was very useful, where the mobile application had been created with React Native as a cross-platform framework that allowed us to develop a single codebase and then compile it for each platform. In the end, our application did not need to use the latest capabilities of the phones it ran on, so we could afford to use this type of framework which, not being native, always lags a bit behind in terms of exploiting all the features of the device in question.
Application Template and Automation#
To address distribution, we needed to achieve a first milestone, which was to have a kind of white label application template, in our case Goxo brand, and with a small configuration (not development, as the idea was that this could be done by a person without technical knowledge) we would have the personalized application for the client. We achieved this by digitizing the process of changing the necessary configuration files and generating the different versions of the image files in the right place so that when uploading the applications to the platform stores, everything was where it needed to be. Thus, the concept of “application churros maker” (Apologies for the Spanglish translation) was born, where basically over the application repository, we applied a script that dressed the application with the client’s personalized branding.
Automating the App Store Upload Process#
Therefore, the next milestone we had to reach was to ensure that the upload process to the application stores was also automatic. The challenge here was that each platform requires following a procedure, usually with its own IDE, in which a package (let’s say a file) containing the application is generated and must be signed before being uploaded to the respective store. In the case of iOS, all this must be done with an Apple computer running XCode, which is the IDE for developing applications for Apple devices, and from where you do all that procedure. This involves the time of a person in synchronous mode in front of the computer doing these procedures, normally we could take about 45 minutes in total for this process. A small note for product managers: a KPI we aimed to optimize at Goxo was precisely this time to marketplace, the time it took us to prepare an application for the client, as it was crucial for us because it was correlated with the time to cash. The sooner we put the application on the app marketplace, the sooner the client would start receiving orders and, by extension, we would start making money. To tackle this challenge, we used a technology called Fastlane, which allowed us to create scripts that took care of the asynchronous process of uploading the application to both app stores, freeing this person from having to do the process for each client.
Evolution and CI/CD#
But the scalability challenge did not end there. So far we have solved the problem of client onboarding, but we all know that applications evolve. New features need to be added, bugs need to be fixed, and with the application encapsulated and placed in a showcase like the app store, each new update, each new version of the application, forces you to re-upload the update for all clients, duplicated, one for each platform. Calculating for 50 clients, let’s say it takes us 20 minutes with the previous scripts to update the two applications. We are talking about 1000 minutes, about 17 hours of execution time, so we had to find ways to parallelize this update mechanism. Bitrise came to the rescue for this. This platform allowed us to create a set of CI/CD pipelines to solve this problem. Basically, you establish a series of atomic steps to be executed in certain contexts to carry out the upload to the Apple and Google platforms. It has very useful features, such as caching compilation dependencies, among other things.
Final Reflection#
Some of you might wonder why not avoid all this hassle by making a web application, parameterizing the URL to customize for the client, and doing a simple webview in the app. It could have been an option at a given time once we had the web application with feature parity (in fact, that was the idea), but that would “only” simplify the scripts (and feature development), but you would have the same scalability problem in distribution, because each application has its own registration within the app stores of the mobile platforms.
So, after all this evolution, what is the main takeaway from this entry? It is that you have to think long-term and execute short-term, putting steps in place that allow you to build that vision in the right direction, the famous “thinking big, start small”.
That’s it for today’s entry. I hope you enjoyed it. Have you faced these distribution challenges? How have you solved them? Write to me and tell me.