StyleMatch

Founding Product Designer

Research · Systems · UI · Frontend

The systems that let an Indian vendor sell to the USA.

StyleMatch connects Indian ethnic-wear vendors to US customers who buy sight-unseen. As founding designer I owned the vendor and admin experience end to end, from research and system design to UI and the frontend for the core flow, and designed the platform to earn trust across that gap while scaling without a person in the loop.

  • The context

    Vendors think like textile traders; customers shop like US e-commerce buyers; neither can see the other.

  • The problem I owned

    Be the bridge between them, and a bridge you can’t staff by hand. So the real question was rarely the screen; it was the system behind it.

  • The work

    A flagship automated market-price benchmark, plus the vendor listing system, an admin completion layer, and natural-language search.

  • Outcomes

    • +67% listing speed
    • Verification gate
    • Umbrella taxonomy
    • Search dimensions
    • Pricing intelligence · concept

Context & how I worked

Every hard problem traced back to the same gap.

A vendor in India names a product like a stock-register entry and shoots it on a phone, a customer in the USA shops by occasion and aesthetic, sight-unseen. As the only designer, I worked close to both edges, interviewing vendors and watching them list, pairing with the founding engineers on what was feasible and what it would cost, and building the core vendor flow in the frontend myself.

Most of the design happened in what we tried first and killed not the screens we kept.

Flagship · Pricing intelligence

Concept · validated architecture + working prototype

Show every vendor where their price stands, automatically

Shipping, margin, and commission inflate every price, and vendors in India couldn’t see the US market they were pricing against. Before designing anything, I tested the obvious shortcut against the real formula.

The two ways to price

  • Full formulaaccurate

    Price + real shipping, then vendor margin + platform commission. Accurate, but only as good as the shipping input.

  • Flat 75% shortcutprice × 1.75

    One multiplier, every product. Simple, but blind to shipping and garment weight.

Why the shortcut died

Killed before build

The flat markup is only right at a single crossover point

The two methods agree in one narrow band, around price ≈ 6× shipping. Below it, the flat markup undercharges and loses money on shipping. Above it, it overprices and kills competitiveness.

Killing it exposed the real question: what market price do we even compare against?

The reframe

Every system needs a match key. Amazon’s is the barcode, trivial, because its goods are standardised. Ethnic wear has none, and no two pieces are alike. So the match key had to be the product image itself.

Price the type, not the item

The architecture

Don’t research every product, classify it, then price the class. Each new upload teaches the system, so the knowledge base builds itself.

  1. Extract attributes

    A model reads the vendor’s title, description and photo, and emits structured tags: garment, fabric, work level, occasion, tier.

  2. Cache-first

    Seen this type before? Return the saved range instantly. Most uploads are variations on types we already know.

  3. On a miss, ask the market

    Send the image + attributes to a Google Shopping API, geo-targeted to the US, and pull real comparable listings, then cache the result.

  4. Fall back gracefully

    Too few matches on a one-off piece? Widen the search, show a broad range, label it low-confidence. Never a fake-precise number.

~$ a few / mo

Feasibility, designed in. The API is called per new product, not per shopper, and cached hard. Real volume lands at a few thousand calls a month. I costed it before designing it, so the concept was buildable, not just presentable.

The vendor system

One screen doing four jobs the trade never asked it to

The vendor portal had to work for someone who sells by showing a piece and closing a deal, not by managing a storefront. Four decisions live on a single page, and each replaced something that broke.

Four jobs, one page

  • Duplicate listing

    One click clones a full listing; the vendor swaps only the photos, the name and the price. The single biggest speed lever.

  • Umbrella taxonomy

    One stable path instead of 30+ saree variants. The description carries the difference.

  • Per-variant pricing

    Each colourway prices independently. Red isn’t navy, and the market doesn’t treat them as one.

  • Live market check

    The flagship pricing benchmark, in the rail, at the moment the price is set.

What we tried first

We started where every marketplace does, CSV upload. It broke fast: ethnic-wear attributes don’t standardise (a saree and a jutti share almost nothing), and CSV needs a row per variant, a kurta in 3 colours × 4 sizes became 12 near-identical rows, with high drop-off. So variants moved inside one product page and watching vendors rebuild the same fields on every listing is where the duplicate button came from.

+67%

Faster listing, per vendor

~3 → 5–6 products an hour after the duplicate button. Measured across the 12–15 vendors who adopted it, each against their own baseline: observed, not a controlled A/B.

Gate & completion layer

Make the platform self-filter, then finish what vendors leave undone

After launch, admins were burning hours on sellers who weren’t serious or couldn’t be verified, a real trust and fraud risk for a US marketplace. The problem wasn’t the review workflow; there was no gate. So I made verification the mandatory first step: a vendor submits a business registration ID the system checks automatically, and only a passing application reaches a human.

Testing surfaced a deeper truth, the challenge was behavioural, not technical. Trade-background vendors left dark photos, empty descriptions, incomplete variants. Rather than force them to behave like US sellers, I made the gate a completion layer.

The system had to be resilient to the reality that some vendors would never fully manage their portal, not dependent on changing it.

The result

Every application a human sees is already a real business, so the queue is smaller and cleaner. And the query flow is collaborative, not punitive: admin and vendor bring a product to standard together.

Craft & build

I didn’t hand it off I built it

I moved into the code and shipped the vendor flow myself then built the design system behind both portals.

  • Shipped the frontend

    Component logic, form behaviour, conditional fields. I built the interactions, because that’s where designed and built quietly drift apart.

  • Built the design system

    Components built once, shared across both portals, with an automated flag that catches drift before it ships, not after.

~30%

Less design-to-dev handoff (est.)

Owning the code removed the explain-every-screen loop.

Impact

0→1 · what the system achieved

A marketplace that runs without a person in the loop

The whole build had one test: could it earn trust across a gap neither side can see across, and scale without an operator hand-holding each listing? At a 0→1 stage, ~20–25 vendors and ~1,000–1,500 live products, here’s what the system actually did.

  • Trust became structural, not manual

    No unverified seller and no half-finished product can reach a US customer. The platform filters and completes by design, instead of relying on an admin to catch it. Trust is a property of the system, not a person’s vigilance.

  • The system compounds as it grows

    Every upload teaches the pricing knowledge base, and the umbrella taxonomy turned a ~weekly engineering task into zero. It gets cheaper and easier to run at scale, not harder: the opposite of a hand-operated marketplace.

  • Real traction, honestly measured

    Not a prototype: 1,000–1,500 live products across the catalogue, and once vendors adopted the duplicate flow they listed markedly faster, an observed gain against their own baseline.

    +67%faster listing, ~3 → 5–6 / hour

What I owned, end to end as founding & only designer

  1. Research
  2. System design
  3. UI
  4. Frontend (core flow)

From interviewing vendors to shipping the code, the vendor and admin experience was mine, front to back.

Reflections

carry forward · still open

What I’d carry forward, and what’s still open

What I’d carry forward

  • Feasibility is a design material

    Designing with the cost and constraints in hand makes a concept credible to engineers, not just pretty in a deck.

  • Study incumbents before inventing

    The sharpest architecture came from asking what a proven system’s equivalent already was, then earning the difference.

  • Watch, don’t just ask

    The decisions that mattered came from behaviour I observed, never from a requirements doc.

  • Design the edges first

    The low-confidence, one-off case is exactly where a system quietly breaks, and where trust is won or lost.

Still open: what I’d validate next

Honest about limits

A 0→1 build leaves real questions unanswered. The strongest parts of this system are also the ones I’d most want to put in front of users next:

  • The “above-market” verdict

    How vendors react when the pricing benchmark tells them they’re priced high, the moment it’s most useful, and most sensitive. I’d test the framing before trusting it.

  • Added-service touchpoints

    Whether vendors fill the optional service fields in honestly, and whether customers even notice them, still needs real usage data before I’d call it solved.

The real question was rarely the screen. It was the system behind it.

Thanks for reading.

A 0→1 marketplace built to earn trust across a gap neither side can see across, and to scale without a person in the loop. Happy to walk through the systems and the trade-offs.

Let's connect