← Back to projects
Product case study · B2B2C · Mobile · EMEA & SEA
One Core, Fifty Brands
A ground-up revamp of a consumer EV charging app — every major flow redesigned, session start
cut to auto-charge, and a plug-and-play architecture so 45–50 separately branded App Store
and Play Store builds share one stable core.
20%+fewer UX support tickets
~0.5s → msload on key interactions
~5%lower crash rate
45–50branded client apps
Problem
The old app had been patched together over time. The UI was inconsistent — different features
looked like they'd been built by different teams with no shared system. The frontend made
too many API calls, so several features loaded in around 0.5 seconds per interaction
in a context where users are standing at a charger expecting instant feedback.
Any small product change required a full app update across every client's separate build,
triggering App Store and Play Store review cycles simultaneously — risk multiplied across
45–50 deployments at once.
App store reviews and support calls flagged the same themes: too slow, session kept stopping,
too many steps to start a charge. The problems were structural, not cosmetic.
Solution
A ground-up revamp: every major flow redesigned, a simplified design system, performance
fixes sequenced first, and a configurable plug-and-play core so each client's branded
version became a configuration exercise — logo, colors, flow variables — on a stable
codebase instead of a fork from a patchy base.
Design finalization ran 2 months; the first application shipped at 3 months.
Both iOS and Android, separate codebases.
Session start · Trip planning · Cost-before-charge · Auto-charge · Configurable white-label core
The trigger
Multiple enterprise clients escalated with consistent feedback: the app felt glitchy, slow,
and incoherent — and it was affecting their brand, not just ours. That made it a
business priority, not just a product backlog item.
How I approached it
Before designing anything, I mapped the real problem. I read App Store and Play Store reviews,
categorized support ticket themes, ran user interviews, and sat on client feedback calls.
01 · Discover
Evidence
Reviews, tickets, interviews, client calls — top three pains by volume.
02 · Prioritize
Impact × effort
Session reliability and load time first; deeper flows second.
03 · Redesign
Every major flow
Onboarding through support — one coherent design system.
04 · Platformize
Configurable core
Separate configuration from code for 45–50 branded builds.
Top pain points by volume: session start reliability, speed, and too many steps
to charge.
What changed
Every major flow was redesigned end to end:
Flows rebuilt
- Onboarding — cleaner first-run experience across white-label variants.
- Charger discovery & home — faster, less cluttered entry to charging.
- Session start — introduced auto-charge to cut steps from arrival to active session.
- Active charging screen — clearer session state while the user waits.
- Trip planning — charger reliability signals, user reviews, amenities, estimated SoC at arrival.
- Payments & receipts — cost estimate before starting, not only after.
- Support — in-app ticket creation tied to session context.
Features added
- Auto-charge flow (fewer taps from charger to session)
- Revenue clarity — upfront cost estimate
- Coupon support, sign-up and referral bonuses
- Marketing content surface
- Push notifications for session events
- Simplified design system — consistent components, less visual noise
Key decision — configurable core
The most consequential decision was not a screen layout. It was making the interface
configurable as plug-and-play.
| Before | After |
|---|
| Each client build = fork + rebuild from patchy base |
Stable core + per-client configuration (logo, colors, flows) |
| New client = engineering project |
New client = configuration exercise with predictable timeline |
| Eng effort consumed by white-label customization |
Eng effort returned to core product quality |
App Store and Play Store still require separate builds per client — that doesn't go away.
But separating configuration from code made each deployment dramatically shorter and lower-risk.
Outcomes
User & support
UX-related support tickets↓ at least 20%
Load time (key interactions)~0.5s → ms
Crash rate↓ ~5%, stable baseline
MAU post-launch+2–5% initial uptick
Platform & clients
Enterprise escalations on app qualityStopped
New client onboardingConfig, not rebuild
Platform MAU50K+ across deployments
Revamp's growth roleStemmed churn pressure
The 50K+ MAU figure reflects platform scale across all client deployments. The revamp's
contribution was stopping the churn pressure from a deteriorating experience — not a
step-change in growth.
Reflection
What I'd do differently
The 2-month design phase was tight for a product serving 45–50 client configurations.
Edge cases in how the configurable system handled different geographies surfaced
post-launch — I would have tested across the full range of client configs, not just
primary deployments.
I would also have included subscription management in initial scope. It surfaced
in discovery but was deprioritized on effort — in hindsight it mattered more to repeat
users than the estimate suggested.
What it taught me
When you build a product that 45–50 other products depend on, a UI revamp is a
platform decision. Every change is multiplied.
The discipline of deciding what belongs in the core versus what gets configured per
client is a different PM muscle than shipping a single consumer app — and it's the one
that made this revamp stick.