Mobile App / Expo & React Native

One account.
Two clients. Zero drift.

The mobile build is not a companion app with its own data — it is the same marketplace, on the same Supabase backend, rendering from the same design tokens. The design problem was not what to build. It was how to make two codebases stay honest with each other while giving each platform the ergonomics it deserves.

RoleProduct Design & Build
Timeline2026
CategoryE-commerce / Cross-Platform
TypeExpo · React Native · NativeWind
View All 9 Screens Read Case Study
Bargain Rani Mobile interface
9
Screens Designed
1
Shared Backend
2
Typefaces
100%
Token Parity
The problem
Most products ship a second client and let it drift — a colour here, a spacing there, until the brand quietly becomes two brands.
The approach
Make divergence structurally difficult. One Supabase backend, mirrored token files, and native patterns only where the phone genuinely wins.
The outcome
A marketplace where cart and wishlist are identical across web and mobile, and the bargain flow is rebuilt around the thumb.
9
Screens shipped
1
Shared backend
100%
Token parity
5
Tab destinations

01 — The Problem

Two clients drift.
That is the default outcome.

Most products that ship web and mobile end up with two design systems wearing the same logo. A colour gets nudged on one platform, a spacing scale diverges, a feature lands on web and waits two sprints for mobile. The user notices before the team does — and on a marketplace built on trust, an inconsistency reads as carelessness about everything else.

01
Token drift
Hand-copied hex values diverge the moment either side iterates. The brand slowly becomes two brands that almost match.
02
State drift
A cart that lives separately per client turns switching device into losing work — fatal for a marketplace where browsing and buying happen at different moments.
03
Platform mimicry
Copying the web layout onto a phone produces a cramped website. Copying platform defaults instead throws away the brand entirely.
04
Negotiation ergonomics
A bargaining interaction designed for a mouse does not survive a thumb on a moving bus.

05 — Solution Exploration

Three decisions about
staying honest.

Every one of these traded short-term speed for the property that matters most on a cross-platform marketplace: the two clients cannot quietly become different products.

Decision 01
Shared backend or its own?
Problem
A separate mobile backend ships faster and avoids coupling two release cycles.
Option A
Give mobile its own API surface and reconcile state later.
Option B
One Supabase project, one account, one cart, read by both clients. (Chosen)
Chosen
Shared backend — mobile and web read identical rows in real time.
A marketplace where the cart differs by device is a marketplace that loses the sale. The coupling cost is real; the alternative is a reconciliation problem that never fully goes away.
Decision 02
Platform-native look or shared system?
Problem
React Native pulls hard toward Material and Cupertino defaults.
Option A
Adopt platform defaults — familiar, cheap, and what the framework wants.
Option B
Carry the editorial system across intact, token for token. (Chosen)
Chosen
Shared design system; native only for navigation patterns and gestures.
The warm ivory, Cormorant and gold are the entire reason the brand does not read as a discount site. Trading that for platform defaults would have saved a week and cost the positioning.
Decision 03
Where does bargaining live on a phone?
Problem
The web presents negotiation in a modal beside the product.
Option A
Port the modal — consistent with web and less work.
Option B
Give it a full screen with a drag slider and one send action. (Chosen)
Chosen
Full-screen negotiation built around the thumb, not the cursor.
Bargaining is the emotional peak of the product. Compressing it into a modal on a 390-point screen makes the most important moment feel like an interruption rather than an event.

06 — Final Solution

The same marketplace,
rebuilt for the thumb.

Five things carry the mobile build. Each one either preserves parity with web or earns its difference by being genuinely better on a phone.

📱
One account, both clients
Sign in once; cart, wishlist and orders are identical on web and mobile in real time.
Problem
Separate per-client state turns switching device into losing work.
Approach
Shared Supabase rows rather than synchronised local stores.
User Benefit
She browses on the phone and checks out on the laptop without losing anything.
Business Benefit
Removes a drop-off point that most marketplaces simply accept.
⚡
Thumb-first bargaining
A full-screen negotiation with a drag slider, live savings readout and a single send action.
Problem
A negotiation UI designed for a cursor is unusable one-handed.
Approach
The product's emotional peak given a whole screen and a gesture rather than a form.
User Benefit
She can negotiate in seconds, one-handed, without precision tapping.
Business Benefit
Makes the differentiating feature feel native rather than ported.
🔖
Account-level wishlist
Hearting a product saves it to the account, not the device.
Problem
Device-local favourites vanish on reinstall and never reach the other client.
Approach
Wishlist stored server-side and surfaced identically on both platforms.
User Benefit
Her saved items follow her, including to a new phone.
Business Benefit
Wishlist data becomes a demand signal sellers can act on.
🏪
Seller path on mobile
Opening a shop takes three fields, with the role upgrade executed server-side.
Problem
Small sellers work from phones, but seller tooling is usually desktop-only.
Approach
Full seller onboarding treated as a first-class mobile flow.
User Benefit
She can start selling from the device she already photographs stock on.
Business Benefit
Unlocks supply growth from the channel sellers actually use.
🎨
Token-for-token parity
Cormorant Garamond, Jost, ivory, jade and gold — mirrored exactly from the web tokens.
Problem
Hand-copied styling diverges the moment either platform iterates.
Approach
Mirrored token files that can be diffed against the web source in review.
User Benefit
The brand feels like one product regardless of where she opens it.
Business Benefit
A brand change is a two-file edit rather than a cross-team project.

07 — Design System & Scalability

Mirrored tokens,
native motion.

The mobile design system is not a reinterpretation of the web system — it is the same system, declared in the idiom React Native understands. What changes is layout, navigation and gesture; what never changes is colour, type and voice.

Palette
Ivory#FAFAF8
Parchment#F5F0E8
Jade#1A3C2A
Gold#C9A84C
Saffron#C46B50
Ink#14231A
Typography
Cormorant Garamond
Display serif — headings, prices, the bargain figure
Jost
Geometric sans — body, UI, labels and buttons
Mirrored token files
lib/colors.ts and lib/fonts.ts restate the web's globals.css values verbatim. Because they mirror rather than approximate, a reviewer can diff them and see drift immediately.
Navigation, natively
Bottom tabs with five destinations, a persistent live ticker in the header and thumb-zone primary actions — patterns that have no web equivalent, rendered entirely in the shared visual language.
Shared copy, shared voice
Product names, guarantees and seller replies are the same strings on both clients. Voice consistency does as much for brand coherence as colour does.

08 — Outcomes & Impact

Two clients,
one product.

The mobile build reaches feature parity on everything that matters for browsing, negotiating and selling, while diverging deliberately where the phone can do better.

9
Screens Shipped
Home through seller onboarding, all against the live shared backend.
1
Backend
One Supabase project; cart and wishlist are shared rows, not synced copies.
100%
Token Parity
Every colour and typeface mirrored from the web source of truth.
5
Tab Destinations
Native bottom navigation with thumb-reachable primary actions.

09 — Key Learnings

What This Project Taught Me

Learning 01
Parity is architecture, not diligence
Asking two teams to keep clients aligned is a process that fails silently. Sharing the backend and mirroring token files makes divergence something you have to do on purpose.
Learning 02
Share meaning, not layout
Colour, type and copy carry the brand and must be identical. Navigation and gesture carry platform expectation and must not be. Confusing the two produces either a cramped website or a generic app.
Learning 03
Give the peak moment room
Porting the bargain modal would have been consistent and wrong. The most emotionally loaded interaction in a product deserves the space to feel like an event, even when that breaks cross-platform symmetry.
Learning 04
Sellers are mobile users first
It is easy to treat seller tooling as a desktop concern. The people listing handloom from a phone are exactly the supply this marketplace depends on, and designing for them last would have throttled growth.
The long version Research, personas, flows
& the thinking underneath 3 sections · the reasoning behind every decision above

Reflection

"The temptation with a second client is to treat it as a port — same screens, smaller. I did the opposite and asked what the phone is genuinely better at. Browsing and haggling turned out to be phone-native activities; checkout largely was not. That reframing is why the cart is shared rather than duplicated: she is supposed to start on the phone and finish wherever she likes, and the architecture should make that free instead of impressive."
— Rupesh Chavan, Lead Product Designer
"Mirroring the token files felt redundant while I was writing them — the same hex values typed a second time in a different syntax. It is the cheapest insurance in the project. Two months later anyone can diff those files against the web source and see instantly whether the brand has started to drift. Consistency you can verify beats consistency you have to trust."
On making drift visible instead of preventable

Explore the Project

See the whole thing

Every screen below is captured from the running Expo build on device, against the same live Supabase backend the web app uses.

View All 9 Screens All Projects Bargain Rani Web