Rebuilding a Boring Mall App · A+
Work Type
Mobile App
Website
Date
Jan - May 2025
Total Time
5 Months
TL;DR
Led the transformation of a mall app into a multi-feature superapp for Ambarrukmo Mall
Designed a ticketing flow that handled 1,000+ concurrent users within minutes, out of a 25,000-user base (~4% event conversion rate)
Built an efficient ticketing flow for peak traffic moments
Zero complaints during the high-pressure "Tour de Ambarrukmo" ticket war
Background & Context
A+ started as a mall app that quite boring and untrusted. It had a loyalty program, some promos and ticketing, but none of it added up to a reason to keep it installed. Meanwhile, the mall's biggest annual event, Tour de Ambarrukmo, was quietly becoming a liability: every year, ticket release turned into a slow performance and app crashes.
I came in to lead the product through a five-month rebuild, and the real brief wasn't "redesign the app." It was to build something that works for a lazy Tuesday scroll and survives the one morning a year when 1,000 people try to break it at the same time.
Problems
Where It Started Falling Apart
The old app treated "get a ticket to the flagship event" as roughly the same kind of task. same flow, same architecture. That's fine when nothing's on the line. It's not fine when a ticket window opens and thousands of people hit the same button in the same ten minutes.
Every past ticket war told the same story multi-step forms, no clear priority on what mattered in the moment, slow registration and a system that had never been asked to hold that much weight at once. Complaints piled up. Trust in the app eroded a little more each year.
Key Problems:
Frustrated users competing for limited tickets
Lost trust in the platform
High risk of system failure during the most important event
Boring App without any interesting things
Objectives
Turn the app into a super app, not separated with many apps
Support multiple use cases without becoming cluttered
handle high-speed, high-stress ticketing without breaking
Constraint
During the brainstorming phase, we faced challenge
The design phase presented a unique set of challenges. The senior client had very specific and unique tastes, requesting an elegant design with gold as the primary color and strictly benchmarking the Marina Bay Sands application. This required navigating a meticulous design process with numerous revisions until the client's stylistic preferences were met. Additionally, the ticketing flow had to be fast to accommodate ticket war.
Solutions
The single biggest change didn't happen inside the ticket window at all, it happened before it. I moved the form, all the personal details and registration data the old app used to collect the moment the war started, to a pre-fill step people could complete days ahead of time. By the time the actual release hit, there was nothing left to type. The three steps that remained were just: open the app, confirm you're ready, claim the ticket.
That's the difference between a flow that's fast because it's short, and a flow that's fast because the slow part already happened somewhere else. Underneath it, the engineering team built for a load spike we knew was coming, not one we hoped wouldn't happen.
When Tour de Ambarrukmo went live, 1,000+ people claimed tickets within minutes, out of a base of 25,000 registered users. No app crash. No complaint thread. For a flow that had failed publicly every year before this, that's the headline. here's the interfaces of A+
Key Decision
pre-fill registration step that make the registration faster
Streamlined the ticketing flow to just 5 steps from 9
Optimized for fast decision-making
Designed to reduce hesitation at every point
How I Knew It Worked
Success here couldn't just mean "the UI looks cleaner." It had to mean the flow survived contact with 1,000+ real people trying to do the same thing at once, and that people stuck around after the adrenaline of the event wore off. So I tracked it on two layers at once, the UX layer and the business layer, because one without the other tells half a story.
On the UX side ticketing dropped from a sprawling multi-step form to 5 steps, and it held up under real load, not just in a Figma prototype. here is what we got after the launch:
The system stayed at 100% uptime through the ticket war
Backing up what "zero complaints" only implied.
Post-launch, the app was sitting at a 4.65 rating from 212 reviews, enough of a sample to trust it wasn't just a handful of enthusiastic friends leaving five stars.
On the business side: 1,000+ tickets claimed out of 25,000 registered users gave a real, if rough, conversion rate of ~4% for the event, the first time this event ever had a number attached to it at all.
More telling is what happened after: 10,000 monthly active users, which is 40% of the entire registered base still opening the app once the ticket war was over.
Of those active users, 75% stuck around month over month, and 2,000 of them, or 20% of active users, actively used a feature beyond ticketing — loyalty, directory, or promos.
That's the number that mattered most to me: it meant the superapp bet paid off. People weren't just installing it for one event and deleting it after.
The two layers reinforced each other. A fast flow with bad reliability still fails. Solid infrastructure behind a confusing flow still fails. The win was getting both to hold at the same time, under real pressure, and then watching that trust carry into everyday use.
Conclusion
The redesigned application was tested for the first time during the Tour de Ambarrukmo ticket war, and it was a massive success. The system flawlessly managed over 1,000 concurrent users registering for the event within just a few minutes, out of a total user base of over 25,000. There were zero customer complaints regarding the process, and user reviews on both the Play Store and App Store reflected the good of customer satisfaction with the app's performance and design.
