Janarayson

Seven years of Hargapedia

Retrospective7 min read

Hargapedia started with a simple idea: find the cheapest price and show people where to get it. Seven years, four generations and over 1.3 million users later, here's a look back at what we built.

It’s been seven years since Hargapedia first appeared in the app stores. Today, it has over 1.3 million users and tracks more than 40,000 products across 42 retail chains and some 800 online stores.

I’ve written about many of the features and technical decisions over the years, but never really about the whole thing. Looking back at the four generations of the app, it’s quite a different product from the one we started building in 2017.

And quite a lot changed for me along the way too.

Where it started

Before Hargapedia, Intrack had spent years doing market research for FMCG companies, collecting prices and promotions from retailers. Hargapedia was its first consumer-facing product, built around a straightforward idea: tell people where they could find a product at the cheapest price and how to get there.

There were just two of us building it, Ow and me. We were the original pair from Nerd Attack, and by then we were working at Hermiso, a venture builder started by our former boss, Swee Yeong. Intrack was one of the companies Hermiso had invested in. Both of us had worked for Swee Yeong years earlier at Pacmee, so we had quite a bit of history together.

I handled the UI/UX design and frontend development. With only two people, that meant designing every screen and then building it myself, right down to the individual components.

Later, I took on the CTO role as well. The architecture and technical decisions became my responsibility, but I never really stopped being the main frontend guy. I still spent a lot of my time designing screens and writing the code behind them.

Four generations of the app

The first Hargapedia launched in January 2018. It was fairly basic: a search box, product categories and pages showing prices from different retailers. You could look up a product and see where it was cheapest, which was what we’d set out to do.

Before the year ended, we released Hargapedia 2.0. We moved to React Native and redesigned the home screen around a stack of cards that our marketing team could manage through the CMS. That gave them more control over what appeared in the app without having to involve the developers for every change.

Hargapedia 3.0 came during the MCO in 2020. It was another major redesign, introducing pull-out screens and dedicated Deals and Vouchers tabs.

Between those releases, we kept adding things.

The price history graph let people see how prices had changed over time. We added a 21-day check-in and member-get-member programme to encourage people to come back. Custom products gave the marketing team a reusable template, while a separate portal allowed smaller retailers to publish their own prices.

Later, we added product ratings and sentiments, shrinkflation labels, HargaPoints, and eventually the A, B and C price grades with their vertical Price Meter. Even the introduction to those grades got its own animated video in three languages.

Most of these features have their own articles on this site.

The fourth generation arrived in July 2024. By then, we were still working with the React Native project we’d started in 2018, carrying years of components, navigation changes and workarounds.

Rather than keep upgrading it, we started a fresh project and rebuilt the app screen by screen. The goal was to preserve the experience people already knew while replacing the ageing code underneath.

Of the four generations, that was the hardest to build. Getting the Vision Camera module working with React Native’s new architecture was particularly difficult.

It took us around five months, but the replacement eventually went out as an ordinary app update. Most people probably wouldn’t have realised they were using an entirely new React Native project.

Growing pains

Our first users were mostly mothers with young children and babies. The most popular categories were things like diapers and milk formula. Over time, that changed, and we started seeing a broader mix of users.

By the end of 2018, we were approaching a quarter of a million downloads. We passed the million-download mark in 2021.

That growth also brought a different set of engineering problems.

Traffic wasn’t evenly spread throughout the year. Festive periods, especially Chinese New Year, would push daily active users into the tens of thousands. We’d have to prepare the infrastructure ahead of those periods, scaling things up to handle the additional load.

After a few years, we got used to the pattern. We knew when the busy periods were coming and could plan around them.

Then the double-day sales became another part of the calendar. Events like 11.11 brought their own traffic spikes, and the database was usually the part that took the hardest hit.

The Huawei detour

One of the more unusual projects we took on was building a separate version of Hargapedia for Huawei.

After the US trade ban in 2019, newer Huawei phones began shipping without Google’s apps and services. Huawei was pushing its AppGallery as an alternative to the Play Store, and in 2020 we built a version of Hargapedia for it.

That turned out to be one of our most challenging platform-specific builds.

Our Android app had been built around Google’s ecosystem. We relied on Google for authentication, push notifications and other services, so supporting Huawei wasn’t as simple as producing another APK.

We had to replace the Google-dependent parts of the stack. Google sign-in became Huawei ID, and push notifications used OneSignal rather than Firebase.

It wasn’t a straightforward migration, and we ended up maintaining a separate build for Huawei devices for several years.

When we rebuilt Hargapedia in 2024, we decided not to carry that version forward. There wasn’t enough demand to justify continuing to support it.

What I’d do differently

After seven years, there are a few technical decisions I still stand by, and a few I’d approach differently.

I’d still choose React Native.

For a small team supporting both iOS and Android, having one codebase made sense. It let us build and maintain features across both platforms without having separate development teams. Even after dealing with years of upgrades and eventually rebuilding the entire app, I’d make that choice again.

Firebase is a different story.

We relied heavily on it, and over time that left us quite tied to its ecosystem. The Huawei work was one example of how much of our Android setup depended on Google services, although Firebase lock-in was a broader concern.

If I were starting another product from scratch, I’d be much more careful about that dependency. I’d prefer an architecture where the underlying services could be moved without having to rethink so much of the application.

Firebase gave us things we needed when we were a small team trying to get a product out. I just wouldn’t want to find myself quite so dependent on one provider again.

On the business side, Hargapedia remained free for consumers throughout. Paid partnerships were what kept the product going, and I’ll leave that part of the story there.

The people who built it

One thing I’m particularly happy about is the engineering team we built along the way.

Believe it or not, many of our engineers joined us straight out of university. They stayed for an average of around four years, which gave us time to work together and watch each other develop.

We had a team that was comfortable learning things on its own, experimenting with new technologies and trying things that were still bleeding edge.

Everyone grew technically during those years, myself included. I liked that we could try things, figure out what worked and learn from what didn’t. That’s a large part of what makes engineering enjoyable for me.

Nine people in a small office, most of them seated around desks with monitors, two in blue Hargapedia 2.0 t-shirts
The team in the office around the time of Hargapedia 2.0, in 2018.

There are things I wish we’d had more room to explore. AI is one of them. Towards the later years, I could see opportunities to build new B2B products on top of the data and infrastructure we already had, but we didn’t get very far with that.

That’s partly where I’m heading next. I’m leaving to build an AI financial chatbot, and to work with AI a lot more.

Still, seven years is a long time to spend on one product. It started with just Ow and me trying to build a useful price comparison app, and there’s a whole team and a lot of work behind it now.