Web Application Rupesh N. Chavan Web Marketplace / Women-First Commerce 2026

Sahi cheez, sahi daam,
poori suraksha.

Bargain Rani is a marketplace built for the Indian woman who has always negotiated in the local market and has never been allowed to online. The obvious product is a haggling game. The one I designed puts trust first and treats bargaining as the hook that gets her through the door, because women do not churn over price, they churn over a wrong-size kurti and a refund that never arrives.

Bargain Rani · interface
RoleProduct Design & Build
Timeline2026
CategoryE-commerce / Marketplace
TypeNext.js 16 · Supabase · TypeScript
47
Curated Products
4
User Roles
12
Screens Designed
1
Shared Backend
02 · Problem Statement

Bargaining is normal offline.
Online it was made shameful.

An Indian woman negotiates without a second thought at a sari shop, a vegetable cart, a jeweller. Move her online and the same instinct is designed out. One fixed price, take it or leave it, and an unspoken message that asking for less is embarrassing. Meanwhile the things that actually decide whether she comes back, will it fit, is it genuine, will a refund arrive, are handled worst of all.

01
Price opacity
Two identical kurtis at ₹899 and ₹1,499 with no way to tell which is fair. The buyer carries all the uncertainty and none of the use.
02
Judgement by design
Asking for a discount online means a coupon-code hunt or a DM to a seller. Both feel like pleading rather than negotiating.
03
Trust deficit
Wrong sizes, fake goods and slow refunds are the real churn drivers. They sit underneath price and no bargaining mechanic fixes them.
04
Safety as an afterthought
For many women a delivery is not neutral. Who sees the order, what the packaging says and who has her number all matter.

The strategic call that shaped everything: bargaining is the hook, trust is the job. If the platform wins the negotiation and loses the return, she never comes back, so the trust infrastructure was specified before the mechanic that gets attention.

01
Make asking feel normal
Negotiation had to read as a first-class, expected action. Presented with the same weight as Buy, never as a discount hunt.
02
Hedge the core hypothesis
Live haggling is an assumption, not a fact. The product needed a second mode that works if the assumption proves wrong.
03
Prove fairness structurally
A claim of a fair price is worthless. It had to be backed by a mechanism the buyer can verify after the fact.
04
Let supply become demand
Any buyer should be able to become a seller in minutes, without that path becoming a security hole.
03 · Research & Benchmarking

What the Rani actually wants

The persona work refused the flattering version. She is not a deal-hunting gamer who wants to haggle for sport, she is time-poor, sceptical from experience, and quietly negotiating everywhere else in her life. Bargaining is only appealing if it costs her nothing when she cannot be bothered.

She has already been burned
Prior bad experiences with sizing and fakes mean trust signals must arrive before the fun does. A discount from a seller she doubts is not a discount.
Negotiation is a skill she has
Offline she reads the seller, opens below her target and settles. The interface should let her use that skill, not teach her a new game.
Not everyone wants to haggle
A meaningful share would rather set a price and walk away. Designing only for live negotiation would have excluded them entirely.
Safety is part of the purchase
Discreet packaging, hidden order history and masked contact details are not edge cases, for some buyers they decide whether the order happens.
04 · Design System

One system,
two clients.

The palette and type ramp are declared once and consumed identically by the Next.js web build and the Expo mobile app. Warm ivory and parchment rather than the marketplace default of stark white; forest emerald and 18k gold to signal considered value rather than discount-bin urgency.

Colour, type, radius and shadow are declared in globals.css for web and mirrored exactly in lib/colors.ts and lib/fonts.ts for mobile. A change to the brand is a change in two files, not two codebases.

Buyer, seller, manager and admin each have distinct entry points, permissions and surfaces. Role transitions are enforced by a database function rather than client-side state.

A ten-step shadow scale including gold and saffron variants gives the interface depth without borders, which keeps the editorial feel intact at density.

Palette
Ivory#FAFAF8
Parchment#F5F0E8
Jade#1A3C2A
Gold#C9A84C
Saffron#C46B50
Ink#14231A
Typography
Cormorant Garamond
Editorial serif, headings, prices and pull quotes
Jost
Geometric sans, body, UI, labels and buttons
Shared tokens
Colour, type, radius and shadow are declared in globals.css for web and mirrored exactly in lib/colors.ts and lib/fonts.ts for mobile. A change to the brand is a change in two files, not two codebases.
Four-role model
Buyer, seller, manager and admin each have distinct entry points, permissions and surfaces. Role transitions are enforced by a database function rather than client-side state.
Layered shadows
A ten-step shadow scale including gold and saffron variants gives the interface depth without borders, which keeps the editorial feel intact at density.

The strategy inverts the obvious order. Trust mechanics are specified and built first; bargaining is layered on top as the thing that makes the platform memorable rather than the thing that makes it work.

01
Establish the guarantee
The Price-Fairness Guarantee, auto-refund if the item sells cheaper within 24 hours, was designed before the bargaining UI, because it is what makes any agreed price defensible.
02
Give sellers a face
Women-Owned verification and named shops turn an anonymous listing into a person you negotiated with. Negotiation without a counterparty is just a form.
03
Design two negotiation modes
Live Bargain for the buyer who enjoys it; Name Your Price for the one who does not. Both are first-class, neither is a fallback.
04
Push authority server-side
Roles, price floors and refunds are enforced in the database, not the client, so the trust promises cannot be bypassed from a browser.
05 · Design Decisions

Three decisions that
shaped the marketplace.

Each of these had a more obvious option that would have shipped faster and demoed better. In every case the chosen path protected the trust promise rather than the pitch.

Decision 01
What is the product actually selling?
Problem. Bargaining is the memorable idea, but memorable is not the same as valuable.
Option A. Lead with the haggling game, it is the differentiator and it demos beautifully.
Option B. Lead with trust; treat bargaining as the hook that earns attention. (Chosen)
Chosen. Trust as Pillar 0, specified and built before the negotiation mechanic.
Women churn on a wrong-size kurti and a slow refund, not on price. A platform that wins the negotiation and loses the return has bought one transaction and lost a customer.
Decision 02
One negotiation mode or two?
Problem. Live haggling assumes she wants to haggle. That is a hypothesis, not a finding.
Option A. Ship live bargaining only, it is the cleaner story and half the build.
Option B. Ship Live Bargain and Name Your Price side by side. (Chosen)
Chosen. Two first-class modes, so the product survives the hypothesis being wrong.
If live negotiation turns out to feel like work rather than play, the single-mode product has no second act. Name Your Price costs one extra screen and de-risks the entire premise.
Decision 03
Where does authority live?
Problem. Any buyer can become a seller, which makes role management a security surface.
Option A. Manage roles in the client, faster to build and easy to iterate on.
Option B. Enforce role changes in a database function, invisible to the browser. (Chosen)
Chosen. Server-side role escalation via a Postgres function; the service key never reaches the client.
The frictionless seller path is the supply-side moat, but a moat that can be escalated from dev tools is a liability. Putting it server-side keeps the path easy and the boundary real.
06 · High-Fidelity Design

A marketplace that
argues for you, fairly.

Five capabilities carry the product. Each one exists to make either the negotiation or the trust behind it legible to a buyer who has been let down before.

01
Live Bargain engine
Real-time negotiation against a seller-set floor price, with counters and accepts resolved server-side.
Problem
Asking for a lower price online normally means hunting coupons or sending a DM.
Approach
A slider and a send button, presented with the same visual weight as Buy.
User Benefit
She negotiates the way she already does offline, without needing to plead.
Business Benefit
The mechanic that makes the platform worth telling a friend about.
02
Name Your Price
An asynchronous alternative: set a price, walk away, get notified if a seller ever meets it.
Problem
A significant share of buyers find live haggling tiring rather than fun.
Approach
The same screen switched to a set-and-forget mode with no live counterparty.
User Benefit
She participates on her own schedule, with zero social pressure.
Business Benefit
Hedges the product's core hypothesis at the cost of one screen.
03
Price-Fairness Guarantee
If an item sells cheaper within 24 hours, the difference is refunded automatically.
Problem
Any agreed price raises the question of whether someone else got a better one.
Approach
A structural promise stated on the product page and again at the moment of winning.
User Benefit
She can stop second-guessing the number she agreed to.
Business Benefit
Converts a marketing claim into a verifiable mechanism.
04
Women-Owned verification
Verified badges and named shops surface who is actually on the other side of the negotiation.
Problem
Anonymous listings make negotiation feel like arguing with a database.
Approach
Seller identity elevated to the product card and carried into the bargain screen.
User Benefit
She is dealing with a named person, which changes the tone of the exchange.
Business Benefit
Gives women-led businesses a discovery advantage that competitors do not offer.
05
Safety by default
Discreet packaging, hidden order history, app lock and masked contact details until dispatch.
Problem
For many buyers a delivery is not a neutral event within their household.
Approach
Privacy controls treated as first-class settings rather than buried toggles.
User Benefit
She decides who knows what she bought, and when.
Business Benefit
Removes a silent purchase blocker that competitors leave unaddressed.
07 · Outcomes

Trust infrastructure,
shipped before the game.

The build is a working marketplace against a live Supabase database. Authenticated pages render real orders, real carts and real seller catalogues rather than fixtures.

47
Products Live
A curated catalogue across apparel, beauty and home, seeded with real imagery.
4
Roles Enforced
Buyer, seller, manager and admin, each guarded server-side.
2
Negotiation Modes
Live Bargain and Name Your Price, both first-class.
24h
Fairness Window
The auto-refund guarantee that makes any agreed price defensible.
08 · What I Learned

What This Project Taught Me

Learning 01
The hook is not the job
Bargaining is what makes the product memorable; sizing, authenticity and refunds are what make it survive. Confusing the two produces a marketplace that demos brilliantly and retains nobody.
Learning 02
Design the hedge for your own premise
The strongest thing I did was assume the central idea might be wrong. Name Your Price cost one screen and means the product still works if live haggling turns out to feel like labour.
Learning 03
Security posture is a design decision
Making any buyer a seller in three fields is a product choice with a security consequence. Moving role escalation into a database function kept the experience frictionless without leaving the door open.
Learning 04
Safety features are purchase features
Discreet packaging and hidden order history read as nice-to-haves on a spec sheet. For a real share of buyers they are the difference between an order placed and an order abandoned.
"I spent the first week designing the bargaining game, because it is the fun part and it is what the idea is named after. Then the persona work made it obvious that I was decorating the hook and ignoring the job. Women do not abandon a marketplace because the price was too high, they abandon it because the kurti did not fit and the refund took three weeks. So I stopped and built the trust layer first. The bargaining is still the reason anyone tells a friend about it. It is just no longer the reason the product works."
Rupesh Chavan, Lead Product Designer
"Adding Name Your Price felt like hedging, and hedging felt like weak conviction. It is the opposite. Committing everything to live haggling would have been a bet that Indian women want to negotiate with a stranger in real time on their phone. I believe that is true for many of them. I do not know it, and the product should not need me to be right."
On designing against your own best idea
09 · Explore the Project

See the whole thing

Every screen below is captured from the running Next.js build against a live Supabase database, so the authenticated pages show real data rather than placeholders.

The problem
An Indian woman negotiates without a second thought at a sari shop. Move her online and the same instinct is designed out as something shameful.
The approach
Make trust Pillar 0 and treat bargaining as the hook. Sizing, authenticity and refunds were specified before the mechanic that gets attention.
The outcome
A marketplace where asking for less is a first-class action, backed by a price-fairness guarantee that makes any agreed number defensible.
47
Products live
4
Roles enforced
2
Negotiation modes
24h
Fairness window
Explore more