The two-year project codenamed “GroundUp App” represented the most Go Bold initiative in Mercari’s history up to that point. The project saw Mercari dedicating much labor, knowledge, and time to fully update the frontend of the Mercari service, but where did the idea for this mammoth project come from?

In this article, Ryo Aoyama (@ryo-aoyama), Tech Lead for the iOS Engineer Team, and Anthony Allan Conda (@allan.conda), Tech Lead for the Android Engineer Team, look back on the GroundUp App project.

Eliminating the Tech Debt Accumulated Through Rapid Growth

──Could you start by telling us how you got started working on GroundUp App?

Aoyama：Mercari had expanded extremely quickly, like no other company in Japan before it. That meant that our code had ballooned as well. We were facing a mountain of tech debt that had accumulated during that growth. There’s an expression in software development: “a big ball of mud.” We were well on our way to that point. Although we kept trying to eliminate this debt of course, we would find that in gradually refactoring, the creation of one component would necessitate the creation of another. It was difficult to make progress. But the things we wanted to do as a tech company kept growing. We ultimately made the big decision to remake everything from the ground up.

Ryo Aoyama (@ryo-aoyama)

──In a previous interview, I believe Ken Wakasa (Mercari CTO) said that you wanted to avoid rewriting the software if possible.

Aoyama： I think there were differing ideas from an engineering perspective. While rewriting software is always a last resort of course, unlike with the backend microservices, it’s difficult to judge the scope of impact refactoring will have on the mobile app when we ultimately release the full source code publicly. We believed that in order to challenge ourselves to rise to the next level as a tech company, we would need to recreate the current app from scratch and build a strong foundation.

Allan：The project was already underway by the time I joined, but it was still in the early stages. There were a ton of things we wanted to do and even more that we needed to do. There was a lot of remaining legacy code, and it was difficult to maintain and add new features. While, as Ryo said, refactoring was one option, there were both upsides and downsides to that approach. Taking all factors into account, we decided to rebuild from scratch.

Aoyama：The project also aimed to clarify the scope of the individual units we planned to break the project down into. That way we could do a phased rebuild in the future if needed and understand how long it would take to fully rebuild the app.

About 20 Times More Difficult?! The Pains of Rebuilding from Scratch

──Could you remind us about the development structure for each of the teams?

Aoyama：The project itself launched in the latter half of 2019, although I still hadn’t joined the company at the time, and Allan was not yet involved with the project. Development on the Android side started in January 2020, while iOS started in April of that same year.

The company worked on development using the “camp” system, whereby engineers with high specialization in particular areas—for example, engineers who specialize in the listing feature domain—can come together and commit to development goals. I think the system makes it clear which engineer you should talk to when you want to discuss a specific feature.

Allan：Exactly. Each camp is made up of iOS engineers, Android engineers, web engineers, backend engineers, QA, designers, and PMs, with each of these teams taking ownership of their own area in driving the project forward. We pushed forward development by holding scrums every two weeks, whereupon we would estimate tasks for the following week. At least, that was the case with most camps. Each one operates autonomously, with each free to choose its own working style.

Conda Anthony Allan（@allan.conda）

──Prior to starting work on the project, how did you sort through the many issues comprising this “big ball of mud”?

Aoyama：The survey to identify these issues was conducted before I joined the company, so they were already laid out by the time I arrived. Still, the issues were rather commonplace issues, like the build being behind schedule or tests being difficult to write. This is why, in an attempt to fix these issues, we introduced sustainable mechanisms to ensure quality.

Rebuilding something from scratch is already 10–20 times more difficult than making a new service from scratch. Rather than focusing on specific issues, it felt more like we were trying to improve the service overall. That’s because there was no change to the features or UX we provide to users.

But since we so rarely have an opportunity like this as engineers—an opportunity to rebuild a service as big as Mercari from scratch—we knew we would have to preempt as many possibilities as we could.

──Were there any bottlenecks in rebuilding from scratch?

Allan：Given that the tools we were using at the time were so old, we decided to introduce the latest, stable technologies to ensure that we maintained productivity. Onboarding members to these technologies took some time, but ultimately we were able to smoothly incorporate them into the project.

Aoyama： I was thinking the same thing. Both iOS and Android had a tech stack that I would struggle to say was production ready, so there were many requirements that necessitated unsupported features be completely rebuilt. It was really tough.

iOS had also readily adopted new build tools, infrastructure, and other technologies, but with so little precedent for us to draw upon, new members struggled to lead themselves to the right answer.

──To shift gears a little: Do you have any rules when it comes to development?

Aoyama：Prior to starting the full rebuild, we totally revamped our development style and established rules optimized to our organization. At the same time, we prepared guidelines from the outset about the organizational functions that, while not directly related to development, engineers should still keep in mind, like UX and error handling. We recommended that basically all engineers use those guidelines in their dev work.

When it came to coding, we tried not to set any strict rules, but we did ask engineers to make sure that code could be checked mechanically. We build mechanisms that would use linters, formatters, or other tools to automatically warn engineers if their coding style didn’t align with this rule.

Allan： We tried to set up a feedback cycle for Android. Specifically, that meant trying to solicit opinions and suggestions from engineers during their onboarding, in meetings during their first week. In the initial stages, I also made guidelines regarding coding and error handling, and I asked new members to give me as much feedback as possible about them.

It’s been about a year since the start of the project, but things have gradually improved, and we have a pretty good cycle in place.

Evolving the User Experience Without Changing a Thing: iOS and Android Accomplishments

──What work on the GroundUp App project best represents the project as a whole?

Aoyama：As far as work shared between iOS and Android, there were four big tasks. The first was the adoption of a new design system. In order to more suitably support the increasingly sophisticated UI requirements, we completely rebuilt the design system for GroundUp.

The second was dark mode support. We had long discussed the topic of dark mode not only as a way to improve accessibility, but as a feature we should implement in order to optimize the service to match the user’s preferences or environment. We were finally able to support it by fully implementing the new design system on all screens as part of GroundUp App. Although we are as of yet unable to offer dark mode on Merpay and some other services at this time, we expect to make it available in the near future.

The third task was internationalization. That is, English support. More than half of our engineers are English speakers, so we introduced English support in-house so that developers could properly conduct dogfooding. Of course, we also want to make the English version available to users down the road.

The fourth task was improving accessibility. While we did have some support on our existing app, we didn’t have a perfect integrated flow when it came to searching for an item, checking the price, logging in, purchasing the item—the complete user journey. This is the part that we had to redesign from scratch so that any user, regardless of their particular characteristics, could use our service.

Especially when it came to accessibility, we heard more users saying that while they had only used the web version up until now, they had started using the app after the update. There still aren’t many good methods to mechanically verify accessibility in the mobile domain in particular. That’s why we were so happy to see engineers creating tools to help validate accessibility alongside the launch of GroundUp, with both engineers and QA teams paying more attention to the topic.

Allan：We’d been working up until now to improve the product without breaking the UX. Although we changed to a declarative UI, improved error handling, and established shared API to name a few improvements, we focused on edge cases in particular, since we hadn’t really done anything to address them up to this point.

Aoyama：Speaking specifically about iOS, the GroundUp App project lifecycle had us remake components using a new framework called SwiftUI. (Android used Jetpack Compose.) This tech will likely become standard practice in the years ahead, so it made sense to adopt this framework now as an investment in the future.

There was also the matter of the build being delayed, a problem frequently noted by just about every mobile engineer. We used a tool called Bazel to build a mechanism whereby the results of each build would be saved to the cloud for reuse the next time someone starts working on a build.

While there are limits to what we can achieve with standard tech, Bazel is a comprehensive, highly versatile tool that only becomes more convenient to use the more developers you have. Its design greatly reduces the likelihood of common problems, like when a feature works on your own PC, but not on other PCs.

The best thing about Bazel is how many options it gives you for breaking features down into modular units. If your service is well-designed, then those units can be the same units you target for the rebuild, as I mentioned in the beginning of this interview. There were previously between 20 and 30 modules, but with GroundUp App, we’ve broken the features up into over 800 separate modules. We hope to continue to break these down even more granularly going forward.

Allan：For Android, we were able to cut down the total code by around half by using the Jetpack library’s Jetpack Compose toolkit. This helped us improve dark mode, internationalization, and accessibility.

──What has GroundUp changed about the Mercari UX?

Aoyama：Our basic goal with GroundUp was actually to avoid changing the user experience. While I do think that it resulted in a more comfortable user experience for users in need of accessibility options, ideally we want to provide the same kind of experience as before.

Allan：We definitely ended up with a more complete design using design system 3.0, but as Ryo said, we thought it was important to provide users with the same experience that they had enjoyed previously.

Two-and-a-Half Years of Work: What Lies at the End of This “Go Bold” Project

──I feel like this project is really emblematic of Mercari’s “Go Bold” value.

Aoyama：そTruly. I think every part of it was Go Bold. (laughs) Rebuilding everything from scratch entails some risk, but I think it was very “Go Bold” to keep plugging at it for two and a half years.

Not only the engineers on the project but everyone—from the PMs to the EMs to the other members—was aligned to give their all towards improving the product rather than just leaving existing mechanisms as-is. You might even say the project was too “Go Bold” in that respect.

Allan：Couldn’t agree more. I don’t think there’s ever been a more “Go Bold” initiative. (laughs) It was extremely difficult and risky to try rebuilding the service without altering the original UX, but I think that we were able to rise to this challenge by collaborating not only within camps, but across camps as well.

──GHaving finished the massive GroundUp App project, what are you planning to take on next at Mercari? And to help you with that challenge, what kind of people are you looking for?

Aoyama： I talked about the “big ball of mud” concept earlier, but Mercari was destined to accumulate this kind of technical debt given the unprecedented speed at which we grew. More than a project where we adopted the latest technologies, the Groundup App project was about disentangling this technical spaghetti and adopting technologies that would likely become the future standard.

It might be better to say that we were solving the issues brought on in development of the old app, or issues which all mobile app development eventually faces. At the end of the day though, the struggles we endured to solve the many problems with dev productivity using outdated tech resulted in growth at the personal and team levels.

I think that now, following the release of the GroundUp App, we are finally in the position to take on more cutting-edge tech. The way we used to deal with feature development, you might find yourself looking at code that was written countless years earlier, but at least it was fairly straightforward. Now, we are not only working to provide features, but also challenging ourselves to adopt new technologies. I think that we’re entering an even more interesting phase of Mercari’s growth, where we will continue to grow the service though our high technological capability.

I think that this phase will bring many opportunities for engineers who are interested in using the advanced tech to improve productivity and engineers who can contribute to the design system and accelerate work to improve UI/UX development. Technical challenges are a shortcut to growth for an engineer, so I expect that this next phase will present the absolute best development experience for engineers.

Allan： Undoubtedly, our current situation will empower engineers to take on the toughest challenges. That is, I think that this current dev work will make working at Mercari an enjoyable experience. I want their feedback as well, to help us further improve our development structure and maintain flexibility when it comes to our architecture.

Talking specifically about Android, we ultimately want to offer support for TVs, smartwatches, etc. given the wide variety of Android-equipped devices out there.

──Last, I wanted to ask: What do you both value most about your work?

Aoyama： I’m a pretty modest engineer, but if I had to name what’s most important to me, I would say I value long-term vision and the ability to imagine the worst-case scenario. While the most popular tech nowadays will work fine for the next 1–2 years, most of it won’t last in the long-term, so I try to think about things from a long-term perspective. I also think that as a leader, you have to be positive. But engineers have to be able to imagine the worst outcomes, as well. The worst outcome is more likely than you think. (laughs)

Allan：In my case, it’s teamwork. We have a lot of challenges, but we also have a lot of talented engineers. By taking others’ opinions into account, we can work to improve things substantially. I want to listen for opinions not only from my own team, but while keeping an eye on the company as a whole.