Rui Costa:

Hi, everyone. Welcome to the App Performance Cafe, a podcast on mobile app performance.  My name is Rui and our guest for today is Hendro from Bukalapak. Bukalapak is an eCommerce and mobile application from Indonesia. Hendro and I, as we will see, we'll go into the challenges of building the super app - so an app that has many, many features - and then we will dive into the differences and particular challenges that you face in a market like Indonesia, with respect to user connectivity, user expectations, and user concerns in terms of performance and app engagement. Hope you enjoy it. Don't forget to follow us on the usual podcast platforms like Apple podcasts or Spotify.

Episode Start

Hi everyone. Welcome to the App Performance Cafe. My name is Rui and today I have the pleasure to have here with me Hendro from Bukalapak. Hendro, thank you so much for joining us today. Can you please share with the audience a little bit about yourself, what you do and what brings you here today? 

Hendro Riyadi:

Yes. Thanks Rui for the invite and also the timing over there - it 's already midnight. That shows your passion to make this thing work really well. Thanks again. Yeah, my name is Hendro. I'm a VP of product in Bukalapak. Bukalapak is a marketplace eCommerce in Indonesia - Jakarta to be exact. And we were founded in 2010, so it's been about 10 years now and growing. Before moving to Indonesia, I was in the US for many years, initially as a Quality Assurance and also Customer Service agent, and then moved into software engineering: working in full stack from backend, front end, mobile device as well, and moved into Product Management. And a lot of my experience focusing on the small business technology. So I worked with Intuit, I work also with GoDaddy, but the last gig was working a little bit different. It was in AI NLP machine learning space. Moved to Bukalapak in 2018. Yeah, it's been running two years at the moment. 

Rui Costa:

Quite a journey, I would say.

Hendro Riyadi:

Yes, absolutely. 

Rui Costa:

Quite a holistic journey. That's one of the reasons why I originally invited you because I believe one of the challenges around performance is precisely don't look at performance as just as lines of code or infrastructure. It's a lot more than that and you have a way, much wider perspective on that. And  I have to say that, yes, it's midnight here in Portugal, but it's 6 AM to Hendro so we are both ...  so thank you for that.

Hendro Riyadi:

You're welcome.

Rui Costa:

So I always like to start with a question about why should we care about mobile app performance, but maybe in this case, it's also interesting to learn from you a little bit, to give the context to the conversation a little bit: what's Bukalapak? What are the goals? What's the landscape of what you guys are doing? And then from there we take it to the challenges that we face. 

Hendro Riyadi:

Sure, yes. I have worked more than a decade in Silicon Valley and then moved to Indonesia. Emerging markets are very, very exciting. It has also some limitations. It is exciting because Indonesia is a rapidly growing population and in terms of the economy growth as well - very, very well. A lot of ... as with emerging markets, the rate of middle class usually ... one of the trends that we see here in Indonesia, again as with any other country as well. There's a study that there is an expectation to reach about 135 million by 2030 in terms of the middle class ---- . So yeah, it's very exciting to work in the consumer facing applications because of that.  But it also has challenges too, right? Such as the infrastructure, the network connectivity, the income level - although it's growing, but it's still probably smaller than developed markets. 

Rui Costa:

Of course, yeah. So you see that you mentioned two challenges there. So, devices: that's something you have to take into account. So maybe focusing on the fact that the user base has maybe lower-end devices. is that accurate? 

Hendro Riyadi:

Yeah, absolutely. So we, for example, for our application because many users are still using old devices, we are still  supporting Android Jellybean that was launched back then in 2012 or 2013, if I'm not mistaken.

Rui Costa:

Yeah, I believe so.

Hendro Riyadi:

And that's an old device. And the second one: the mobile penetration in Indonesia is actually very high. However, the internet connectivity could be flaky. A lot of people even - you know  the concept of pre-paid in Indonesia is more common because it's more cost-efficient. But there's also the option to do postpaid, but in general, I think people use prepaid which is cheaper. As a result, it provides a lower bandwidth in terms of internet connections. And they rely on like a lot of us rely on their connections a lot. Even to the point where you may not have an internet connection at home, you're relying on tethering in from your phone and things. Even in this pandemic, working from home, some of my team members that report to me, a couple of them have been relying on 4G connections because they don't have the wifi connection at home. So you could imagine someone who works in technology may just still rely on the tethering at home instead of the solid WiFi connection, like the T1 connection like in the US. 

Rui Costa:

Yeah, so that poses big, big challenges with respect to when you try to bring, I would say an eCommerce application, but I believe you are way more than that. So when you're trying to bring this application into the market, the fact that the core of your user base relies on cellular connectivity with probably some, as you said sleepy connectivity, brings definitely challenges with respect to how you build an app. How do you think of the app from a wide variety of perspectives. Can you share a little bit on that? Like what were, and are, the challenges that you face with respect to that and how do you tackle that?

Hendro Riyadi:

Well, it's also interesting for us. We have five unicorns in Indonesia: One in ride hailing, two in commerce, one in travel, the other one is payment space - and all of us have turned to be a super application. Which is a little bit different than in the US, usually the vertical ... let's say  Twitter is very vertical oriented, LinkedIn, very vertical oriented, but we have become a super application. Even the same thing, I think in China, some of the giant tech companies turn into a super application. Now, as a result, you have a higher application size, that we as an eCommerce marketplace in Indonesia, we not only sell physical products, but we also sell virtual products like phone credit, or prepaid or a data packet, internet connections. And we sell the ability for someone to pay their electricity bill, their water bill, gas bill, and so on. Internet connection at home - we also provide the way for them to pay through us. We also sell mutual funds. We believe people get mutual funds from us, buying stocks, mutual funds - gold as well. 

Rui Costa:

Really?! Wow!

Hendro Riyadi:

Yeah. Video streaming, travel and things like that -  it's very common, the hotel, the flights. So yeah, we have so many features in our applications. And also what's interesting, if I look at the payment modules we have - we are supporting so many payments capabilities from what is obvious within the US like credit cards, but our credit card penetration is actually very low. But bank transfer, cash on delivery, and you have the ability to pay to the 7/11 over here, the retail store, you bring the cash in, physical cash in, and pay that invoice over there. So there are at least 10 to 15 modules that are our payment types that we support. And there are so many banks, yeah. So the opposite with the internet, right? You have this SaS getting bigger, bigger, bigger, and the internet connection is limited, so that creates a hindrance for people to download your applications. For example in iOS, I believe if you hit that 200 megabytes, then you wouldn't be able to download the application over the data plan, you have to use the WiFi. Now, the challenge is that, like I mentioned even some of our tech company employees, they don't  have the WiFi connection at home, so they use the tethering. So that definitely presents a challenge for us.

Rui Costa:

Yeah, of course. So with such a diversity - so basically what you just mentioned is you support so many different features - that's why you call it a super app, right? With so many use cases, and then also combine that with the fact that connectivity is an issue and bandwidth is an issue, data plans are a limitation. And as you said, it takes you into building this in terms of size - big, big app. And as you just mentioned, but then in the end, if I have to download - say 300 megabyte or 400 megabyte application through cellular connection that will probably kill my data plan, right? As you mentioned, it can even be the case that my whole connection is through my data plan: so that's a strong limitation. So how do you tackle that? So how do you make all that happen in the same application, and at the same time, tackle the severe limitations that you may have with respect to connectivity?

Hendro Riyadi:

Yes, we are very conscious with our application size and also, the application size to some extent also helps improving the application performance. So we measure that a lot and we are doing things that are probably a little bit unconventional. For example, I mentioned initially about the payment modules, the type of payment modules, payment types that we have to support in this environment. There is a library of payment that is quite decent, about two megabytes. But then we have to do a few things to even cut that further. So we have to look at the library and even do some little bit tweaking, even removing parts of the library that just don't make sense. And we have to do that quite frequently.

If we build a mobile application then, we are expecting it to be highly responsive, right? So that customers would have a great experience using that. Usually a native application is more responsive than a mobile view or web view applications. But with the number of features that we have, the more we use the native, the more we have these features built on the native, then the application size will just going to be bigger and bigger. And what we're doing is that we have to make tradeoffs. We have to make guidelines in the company by looking at existing features and also new features. 

We have about 50 products squads in the company and quite a number of new features that we built as well. And we have to be careful on not having everything as a native application. So what we're doing at the moment is to look at our existing features, we were created this plan, how we look at some features which are not, there are some criteria, like one of them being the features that are not core to the eCommerce experience of our product then lets convert that. Move them away from the native experience but bring them into - two things that we look at, whether it's a mobile web experience embedded into our applications or this concept in Android, they have for dynamic delivery. So when let's say a feature that not many people use, we make that feature not part of the bundle, the default bundle: our APK, but when somebody clicks that feature and launches that feature, then it will just going to be dynamically downloaded, delivered into your phone. So we use that as well. At least we could save space initially, only when people really want to use it, then they can go get those things downloaded.

Rui Costa:

Yes, so basically we're trading off speed or responsiveness for a size. 

Hendro Riyadi:

Yes.

Rui Costa:

Interesting.  So when you do this … so basically what you're saying is that, if I understood correctly, what's core in your business, which is the marketplace, you keep it native - so that it has optimal performance with that regard. But the remainder, you make it a web embedded, web view or this progress content delivery to the application so that you do not make that into the APK of the app. So, how did you handle the difference in terms of experience? Because on one side I'm doing, I'm using the marketplace, which is all very fast and responsive, and then I jumped into this web view. So how do you first, how do you decide what goes where? So what is native, what is not native? And then how do you handle this jump and what's the kind of the user expectation, in respect to that?

Hendro Riyadi:

Sure. Yeah, great questions. We build the guidelines and rolling out these guidelines as well, is a work in progress. But for the most part, I think we look at the number of visits, as one of the factors. If you have very high active users, then we're okay for this type of product to be on the native side. But if you have low to medium visits, then we expect, okay, can you make it as a dynamic delivery or a web view concept? And second is like you mentioned just now with the core experience, it's something that is on the main page, just right there without clicking to the second level and things, then usually we say, okay, that's okay to do it on the native one. And there's also the need for that performance, right? Native is usually more responsive, and therefore, if you have the need to make it really fast, then that's okay. Let's say, marketplace checkout and you need to have it fast. Otherwise it will just frustrate, it will create frustration for people, you know, having slow ability of checking out.

But then there are other things that we probably don't need to have that kind of like very quick and things. Let's say promotional pages, right? Loading, and we do a lot of vouchers, and when the vouchers slowed it, then it doesn't need to be native than maybe like a web view is okay. If your feature requires some native access or operating system access then there is some limitation. If we go to the web view side versus we go to native -  we also look into that. What else?

The cycle of the release - that's also very interesting. There is actually a benefit if you go to the web view so that the cycle of release you can handle that better, faster. 

Rui Costa:

So you can roll it out way much faster and test it out, way much faster. 

Hendro Riyadi:

Yes, yes - testing this part. Makes sense also for the testing, a lot of our RNVP we use the web view so that we can really sit, test it, tweak it. If it's approved, proven to be successful or there's some good track record feature will be a successful feature then it's okay for us to convert it to active native applications.

Rui Costa:

So it's like this testing based to see what sticks and what users want. And then if you get real traction, you'll just make the decision. All right. So this does pay off the price of size in terms of application size to put it the native side. So can you  give us a few examples of what you have, non-native as like, features that you put there, you already mentioned vouchers - but do you have other features on that?

Hendro Riyadi:

Yeah. What is also interesting about us becoming a super app is that we also put a lot of games. And with games, people are engaged. They're more engaged in playing games with us then they get points and things so they can use it to purchase more items with us. 

Rui Costa:

Oh, interesting! So you do games within your application?

Hendro Riyadi:

Yeah.

Rui Costa:

That people are playing them around and you can actually get points so that you can play them off for discounts on the marketplace. Wow, that's interesting. Oh, wow. That has to be a very big app do that. 

Hendro Riyadi:

Yes. It becomes really big. It becomes a big app and with these games - again, the games are okay. I mean, it's not like games, it's not like the sports game has to be real time, but this is like flash  games. So it's okay to make it as a web view. That's kinda like our guidelines now. For new games also, we do it as a web view and we also have like the Wheel of Fortune type of games where, you know, roll it and then you get this voucher, you get this cash back and so on and so forth. 

So that one and the other one I talked about, we have a feature for people to buy and sell motorcycles and cars. So that's at the moment it's still in web dynamic delivery or web view. I actually a bit forgotten about that, and the mutual fund and the gold stuff as well, in the dynamic delivery or web view. What else? We have some of our virtual products that really kind of towards the end, in terms of the use case, let's say where virtual products or services that sell with internet data packet for cell phones, that's already in native because a lot of people depend on that. But as far as the other side of digital products, let's say with some of our internet providers, the lower end ones, then we think about "Hey let's put into web view or dynamic delivery."

And we have the ability as well for people to give donations to their nonprofit organization that they would like to contribute. That's also part of the web view or dynamic delivery. Like searching, listing, checking out, you know - those kinds of stuff - payment is native.

Rui Costa:

The core eCommerce stuff -  I would say.

Hendro Riyadi:

Yes.

Rui Costa:

Wow. Well Hendro thank you so much. As you probably heard in the previous episodes, I always like to tease the guests with a last question of: if you cross someone on the street or on an elevator that is, or will be, working on mobile apps and performance -what would be your like very short recommendations for these people? What will be the key takeaways from what you shared your experience when considering mobile apps and performance of mobile apps?

Hendro Riyadi:

Right. One being focusing on the customers and also the environment where the customers are. People might it have a different need in terms of, or in terms of performance, what it means for them. It could be where someone cares so much about paying the data cost versus someone who has unlimited data plans, whatsoever. And to also think about whether your customers have always have the latest and greatest of the cell phone devices, maybe two years old maximum. And that's how it's like in the US we have the two years contract and then you can change and go to the next contract and things. But with us, as I mentioned, we're still supporting the Jellybean 2012, 2013 - and so also focus on that. And through that, then some of your responses or strategy will be different. 

An example is we build because of the internet connections, we build in our network layer, the ability to give an option to retry up to five times, which could be a little bit strange in the USA. Why do you have to try five times then? Why don't you just do like twice and it's okay -guaranteed it's going to be working out. We also, due to this internet connection and we’re also still using kind of like these flash screens though from the guidelines from Android or iOS, mention to not using trend that much. But then again, with us, it's using, we get a higher engagement because when you have flash screen, at least people can see, "Hey, there's new page coming up". 

There's also - we just had a conversation about this  with some of our performance engineer about loading indicators right? The  progress bar, loading indicator to me, I feel like,  "Hey, if we could do a countdown -  it's even better than not having the countdown". But with the countdown there is the exact time, right? It's usually possible that we can measure this exact time if it's an internal process for us. But then if it's involving the network latency and things, then it's not in our control. Sometimes the network is down. The countdown I think we have to use it very carefully. Otherwise we will create that false impression, "Hey, countdown's stopped, why is it still not coming up.?" So we maybe relying on the less sophisticated progress bar or the loading indicator, the spinning wheels, if it works to some extent. 

So yeah, knowing that, that the environment, where the customers are, what they care about, what they need -  it will help  create a strategy that works for your applications. And the second one, probably to measure it a lot. Measure it a lot in the company and make it feasible so that people that are simply focusing on releasing the product and launch it and that's it - bye bye, and move on to the next product. Like we could create a sense of accountability, " Hey, your product is slowing our performance by this much. And you have to fix it, or we put a hold on this one, we're not going to launch it". 

That's one  one of my initiatives that I'm working on as well in a company, how we could create a benchmark. Like you have to hit, if you're doing a web view or a web native application, then we're creating this benchmark. You have to hit this score. If not, we're not launching it, right? Maybe like lose it by a couple of points or so, maybe that's okay. But then if we're way off, then we're not launching it. 

Rui Costa:

Yeah, it's interesting because another guest in the previous episode also talks about something related to that, which is this concept of performance budgets. Which basically it's looking at performance from, taking performance as a feature. So as you just described, like if you failed to hit that specific target, then you don't launch it doesn't work. It doesn't go live. So, that's actually very, very interesting. And it was also very, for me thinking about this different perspective. People tend to think about performance only as speed or responsiveness, but application size, the behavior with connectivity or slacky connectivity - it's also very something that you should be always aware of when you're thinking about it. Hendro, thank you so much for this early morning, late night in my case, call. It was a true pleasure and thank you all for listening and see you next week. 

Hope you have enjoyed the conversation. I will leave in the episode description, the links for Hendro's  LinkedIn, as well as Hendro’s Medium account, so that you can follow what he has been working on.

Don't forget to follow us on the usual podcast platforms like Apple podcasts and Spotify. And do reach out, send us an email or drop us a tweet or message or something like that. we'll be glad to hear from you - see you next week!