HR.

Case II: Nexora · B2B Electronics Trading OS

Nexora

A ₹100M-a-month electronics trading business runs entirely on WhatsApp groups. Nexora moves the whole floor onto one transparent platform: sellers, buyers, logistics, and the owner's oversight.

Nexora Buyer Hub on a MacBook: My Buying Bids with live, filled, paused and expired bids, statuses and validity windows
Industry
B2B marketplace · SaaS
Role
Lead Product Designer · 0→1
Duration
Ongoing · 2026
Year
2026

Project overview

Four roles, one deal, zero ambiguity: a multi-role SaaS designed 0→1 for a trading floor that had never had software.

An operating system for a working trading floor. Sellers list stock, buyers bid, and logistics, the trust anchor of the whole business, holds the inventory, runs quality checks, handles payments, and fulfils. I designed the full multi-role SaaS: four role-scoped workspaces, 92 light-theme screens (with a dark counterpart), on one tokenized design system.

My role

Lead Product Designer, research, system, 4 role workspaces

Team

Business owner + ops stakeholders; sole designer

Timeline

2026 · ongoing

Tools

Figma · FigJam · Design tokens · Light + dark themes

Problem statement

A ₹100M business you can't see into.

This is not a startup looking for a market, it's a well-established trade doing roughly ₹100M a month, and every rupee of it moves offline. Sellers, buyers, traders, and the logistics partner meet in WhatsApp groups: sellers post stock lists, buyers bid in the thread, and the winning deal leaves the chat entirely, payment, quality check, and delivery are all settled one-to-one, on trust.

The logistics partner is the quiet centre of the whole operation. It warehouses every seller's stock, runs the quality checks, collects and releases payments, and fulfils the orders. Yet none of that work is visible anywhere, it lives in chat scrollback, phone calls, and paper.

For the business owner this means zero oversight of a nine-figure monthly flow: no deal history, no price discovery, no audit trail when a dispute lands. Solving it mattered because the business had outgrown the medium it runs on, and every competitor is one WhatsApp export away from its entire market.

Business goals

Digitize the floor without slowing it down.

I.

Make every deal auditable

The owner's core ask: see the business. Every listing, bid, QC result, payment, and release recorded on one ledger, transparency for the owner and every stakeholder in the chain.

II.

Keep WhatsApp-speed

The floor works because it's fast. If listing stock or placing a bid takes longer on the platform than in the group chat, traders go back to the group chat. Zero-training adoption was a hard business requirement.

III.

Formalize payments through logistics

Payments already flow through the logistics partner informally. The platform makes that role official, escrow-style holding, payment proofs, verified release, turning the riskiest offline step into the most trusted online one.

IV.

Open a platform revenue line

Once deals run through the system, the business can monetize the rails: subscriptions and wallet-funded fees (designed as the Payments & Subscriptions module) instead of skimming margin from chat-brokered deals.

User research

Two weeks inside the WhatsApp floor.

The market already existed, the research job was ethnographic. I sat inside the trading groups, traced real deals from listing to delivery, and interviewed every role in the chain about where deals stall, die, or turn into disputes. The deal-lifecycle map that came out of it became the platform's information architecture.

Methodology, Lean UX

HypothesizeBuildMeasureLearn

The build ran on Lean UX: each module started as a hypothesis about floor behaviour ('traders will bid in a structured form IF it's faster than typing in the group'), was mocked at low fidelity, walked through with real traders on their own deals, and only then designed at hi-fi. The WTB board and the escrow flow both changed shape in that loop.

How I ran it

3

Groups shadowed

Two weeks embedded in live WhatsApp trading groups, reading every listing, bid, and dispute as it happened.

20

Deals traced

End-to-end reconstructions from WTS post to delivery, timestamps, drop-offs, and where money actually moved.

11

Interviews

4 sellers, 3 buyers, 2 logistics operators, the owner, and a broker, every role in the chain.

1

Lifecycle map

List → bid → negotiate → confirm → QC → pay → release, with failure points marked, the IA's backbone.

What the research surfaced

7 / 20

traced deals stalled or died between 'winning bid' and payment, exactly the stretch that lived in private chats with no record.

100%

of disputes reconstructed came down to memory-vs-memory: no shared record of what was agreed, at what price, in which condition.

~40 min

average logistics time per deal spent manually cross-referencing chats, notebooks, and payment screenshots.

0

traders willing to adopt anything slower than the group chat, speed parity became a hard design constraint, not a nice-to-have.

User personas

The three roles that make the floor.

Drawn from the interviews and the shadowed deals, one persona per role in the chain, because each experiences the same deal from a different side of the trust gap.

RS

Rafiq Sheikh

38 · Electronics wholesaler · The volume seller

My stock is in their warehouse and my money is in their promise. All I hold is a chat thread.

Goals

  • Move lots fast at a fair clearing price
  • Know QC status and payment timing without calling
  • Reach buyers beyond his two groups

Frustrations

  • Zero visibility once stock is handed over
  • Bids scattered across threads and DMs
  • Disputes settled by relationship, not record

Behaviours

  • Posts WTS lists to multiple groups at 10am sharp
  • Prices from memory of last week's deals
  • Keeps his real ledger in a paper notebook
KM

Kiran Mehta

31 · Reseller-trader · The margin hunter

The lot I want is always 200 messages up in a group I checked an hour late.

Goals

  • Catch the right lot before the group does
  • Verified condition before committing lakhs
  • A bid history he can learn from

Frustrations

  • No price discovery, every negotiation starts from zero
  • Screenshots as receipts
  • QC promises that surface after payment

Behaviours

  • Monitors four groups in parallel all day
  • Bids conservatively on unverified stock
  • Pays only through the logistics partner he trusts
SP

Suresh Patil

45 · Logistics operations head · The trust anchor

Every deal in this market runs through my warehouse, and my memory.

Goals

  • Run intake, QC, payment, and dispatch without dropped balls
  • Prove his team's work when disputes land
  • Scale past the ceiling of his own attention

Frustrations

  • The whole trust layer tracked in notebooks
  • Blamed for delays caused by missing information
  • Every escalation lands on his phone

Behaviours

  • Reconciles chats to stock registers every evening
  • Photographs QC results 'just in case'
  • Is the de-facto escrow for the entire floor

User problems

Four roles, four versions of the same blindness.

Sellers

Stock leaves, then silence

Once stock is handed to the warehouse, sellers lose sight of it, QC status, whether it sold, when payment lands. Their ledger is a chat thread and a phone call.

Buyers

Bids buried in scrollback

Offers live in fast-moving group threads: no price history, no bid status, no proof of what was agreed. Winning a lot means screenshotting messages as your only receipt.

Logistics

The whole trust layer, run by hand

Stock intake, QC verdicts, payment collection, releases, dispatches, tracked across notebooks and chats for every seller and every deal. One missed message becomes a dispute.

Owner

A business run on faith

No dashboard, no deal pipeline, no user accountability. Disputes settle on relationships, and the true state of a ₹100M/month operation lives in other people's phones.

Market research

The market was already there, I studied how it behaves.

This wasn't a demand question, the trade exists and thrives. The research job was to map how the floor actually works before moving it: shadowing the WhatsApp groups, tracing real deals end-to-end, and interviewing each role about where deals stall or die. The deal lifecycle that came out of it, list, bid, negotiate, confirm, QC, pay, release, became the backbone of the entire IA.

Two findings shaped the design more than anything else. First, the floor has its own vocabulary, WTS and WTB lots, bids and counter-bids, stock grades, and any interface that renamed those concepts would read as foreign. Second, generic B2B marketplace patterns don't fit: marketplaces assume buyer and seller settle fulfilment between themselves, while here logistics is the market's trust anchor, it holds the stock, certifies the quality, and moves the money. The platform had to be designed around that role, not bolt it on.

Competitive analysis

PlayerLive biddingDeal audit trailEscrowed paymentIntegrated QCFloor vocabularyLogistics-centric
WhatsApp groups (status quo)Chat
IndiaMART / UdaanPartialPartial
Generic auction platformsPartial
ERP / inventory toolsInternalPartial
Nexorathis project

The status quo wins on vocabulary and speed; platforms win on records. Nothing offered both, which is why the floor never migrated, and why Nexora keeps the group-chat rituals on top of a ledger.

Constraints

The box the design had to fit.

I.

Traders, not SaaS natives

Users are electronics traders who live in WhatsApp, not web apps. Every flow had to survive the 'is this faster than the group chat?' test, familiar vocabulary, dense tables, one-modal actions.

II.

The business can't stop to migrate

₹100M a month doesn't pause for onboarding. The platform runs alongside the groups during transition, so flows like invited accounts, references, and application review were designed for gradual, trust-based enrolment.

III.

Every deal must route through logistics

QC, payment, and release are logistics' jobs, by design, not by feature. No flow could let buyer and seller settle around the platform, or the transparency promise collapses.

IV.

Indian payments reality

Bank transfers with screenshots, not card rails. The payment flows are built around proof uploads and manual verification, designed honestly for how money actually moves here.

Design strategy

Three rules I designed every screen against.

  1. I.

    Keep the floor's vocabulary.

    WTS lots, WTB requests, bids, counters, stock grades, the platform speaks exactly the language the WhatsApp groups already speak. Adoption is a rename away from failure.

  2. II.

    Make the ledger visible.

    Every deal is a stepper, QC → payment → release, and every role sees the same truth from their own side. Transparency isn't a report the owner pulls; it's the interface everyone works in.

  3. III.

    Logistics is the spine, not a service.

    The IA routes every confirmed deal through the logistics workspace, stock verification, payment confirmation, release. The platform's trust model is the business's trust model, formalized.

Information architecture

Four workspaces, one deal ledger.

One platform, four role-scoped workspaces, seller, buyer, logistics, admin, sharing a single design system and a single source of truth for every deal. Two artifacts below: the sitemap of the full platform, and the lifecycle a deal travels from listing to release.

Sitemap

Role-scoped workspaces on one platform.

Each role gets its own sidebar and workspace, but every deal lives on the shared ledger. Verified onboarding gates the whole system. Click any node to inspect.

User flow

List → bid → confirm → QC → pay → release.

The deal lifecycle, exactly as the floor runs it, with logistics holding the middle. Hit play to watch a deal travel end-to-end.

Step I / VIII

Currently inspecting

Seller lists a WTS lot

From catalogue and price lists, brand, model, grade, quantity, asking price. What used to be a WhatsApp message becomes a structured, searchable lot.

Next: Post WTS lot

Process, AI-assisted workflow

How this was built, end to end.

The same loop I run on every project, tuned to Nexora: start from the problem statement the business brings, let ChatGPT compile the prompts, let Claude do the heavy lifting, and keep every judgment call human.

ChatGPTClaudeFigmaStorybookNotion
  1. I.
    Notion

    Read the business, understand the problem

    The business prospect came with the problem statement ready: a ₹100M-a-month electronics trading operation running deals on WhatsApp and memory, with no system of record. I read it until I understood how the money actually moved.

  2. II.
    ChatGPT

    ChatGPT engineers the prompt

    I described that problem statement to ChatGPT and got back a .md prompt written for Claude Code: roles, deal lifecycle, flows, constraints. ChatGPT turns my product thinking into a spec Claude can execute without drift.

  3. III.
    Claude

    Wireframes in Claude Code

    Claude Code turned ChatGPT's prompt into working wireframes. One goal only: validate the flows and the screens for sellers, buyers, traders, and logistics.

  4. IV.
    Notion

    Playtest with real users and the business owners

    I playtested the wireframes with the business owners and the people actually running deals, and iterated until the structure held.

  5. V.
    ClaudeFigma

    Color system, tokens, typography

    Then the NEXORA brand color became a color system inside Figma, built with Claude over the Figma MCP: tokens first, typography next.

  6. VI.
    ChatGPTClaudeFigma

    Component library in Figma

    The validated wireframes defined the component list. With a prompt from ChatGPT, Claude built the complete component library in Figma.

  7. VII.
    ChatGPTClaudeFigma

    Hi-fi screens, my judgment calls

    Claude composed the 92 light-theme hi-fi screens from the library, prompted again by ChatGPT. Visual design and the user journey were my calls: playtest, iterate, sign off.

  8. VIII.
    Storybook

    Storybook, then handoff

    After sign-off, the entire component library went into Storybook as the single source of truth, then over to the devs.

Key design decisions

Why the platform works the way it does.

I.

Route every confirmed deal through a shared three-step ledger: QC → payment → release

Why

Deals died offline because each step lived in a different chat. The logistics partner already performs these steps, the design's job was to make them the deal's single spine.

Impact

Buyer, seller, logistics, and admin all watch the same stepper on the same deal. Disputes stop being memory contests; the owner reads the whole pipeline at a glance.

II.

Keep WTS / WTB as first-class objects, not 'listings' and 'requests'

Why

The floor already thinks in Want-to-Sell lots and Want-to-Buy requests. Renaming the trade's own vocabulary would make the platform feel like software instead of their market.

Impact

Traders read the interface the way they read the group chat, zero retraining, and the WTB board turned passive scrollback into a searchable demand signal sellers can act on.

III.

Replace chat bidding with structured offers and a negotiation workspace

Why

Bids in threads have no status, no history, and no accountability, the exact opacity the owner needed gone.

Impact

Every bid carries price, quantity, condition, and expiry; counters happen in a workspace with an audit trail. Price discovery becomes data the business owns.

IV.

Design payments as escrow-with-proof, not checkout

Why

Money moves by bank transfer and screenshot here. Pretending otherwise would have made the payment module decorative.

Impact

Buyers upload proof, logistics verifies and holds, release happens only after QC clears, the riskiest offline step became the platform's most trusted flow.

V.

One design system, four sidebars

Why

Four roles could have meant four products and four mental models, unmaintainable for a solo designer and confusing for users who hold multiple roles.

Impact

Role-scoped navigation over shared components: 92 light screens (and their dark counterparts) shipped consistent, and a trader who is also a seller never relearns the interface.

Final designs

92 screens across four roles.

The light-theme surface, sectioned exactly as in the design file, auth and verified onboarding, seller hub, buyer workspace, logistics control, admin console, and payments. Pick a section on the left; click any screen to enlarge.

92 screens · 22 sections · Web app · 1440×1024

01 · Auth · Login & Onboarding (All Roles)

12 screens

03 · Seller Flow

3 screens

04 · Buyer Flow

4 screens

05 · Logistics Flow

3 screens

06 · Alerts & Settings

2 screens

07 · Seller Hub

7 screens

08 · Seller · Market Offers

3 screens

09 · Seller · Reports

1 screens

10 · Seller · Catalogue Price Lists

4 screens

11 · Buyer · Market Offers

5 screens

12 · Buyer · My Buying Bids

3 screens

13 · Buyer · My WTB Requests

6 screens

14 · Buyer · My Confirmed Orders

8 screens

15 · Buyer · Market WTB

1 screens

16 · Logistics · Stock Verification

4 screens

17 · Logistics · Confirmed Deals

6 screens

18 · Seller · Order Status

6 screens

19 · Admin · Dashboard

1 screens

20 · Admin · User Management

4 screens

21 · Admin · Deal Management

2 screens

22 · Admin · Payment Management

3 screens

24 · Payments & Subscriptions (All Roles)

4 screens

Outcomes

92 screens
The full light-theme platform, 22 sectioned flows across auth, seller, buyer, logistics, admin, and payments, with a dark theme designed in parallel.
4 roles, 1 ledger
Seller, buyer, logistics, and admin each get a scoped workspace, but every deal runs on one shared QC → payment → release spine.
₹100M/mo
The monthly flow the platform is designed to make transparent, every bid, verdict, and payment auditable for the owner and every stakeholder.

Reflection

Digitize the ritual, not just the transaction.

What went well:leading with the floor's own vocabulary. The moment stakeholders saw their WTS lots, grades, and bids on screen, instead of generic marketplace language, the conversation changed from “will traders use this?” to “when can my group get on?”

What I'd improve:I'd bring the owner's analytics forward. The admin dashboard came late in the sequence, but oversight was the founding motivation, designing the owner's view first would have sharpened what every other role needed to record.

The lesson: when a business already works, the design job isn't to reinvent it, it's to move its rituals somewhere transparent without breaking their speed. The WhatsApp group was never the problem; the invisibility was.

More work

Keep looking.

Currently viewing: Nexora