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.

- 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.
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.
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.
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.
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
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.
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
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
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.
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.
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.
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.
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
| Player | Live bidding | Deal audit trail | Escrowed payment | Integrated QC | Floor vocabulary | Logistics-centric |
|---|---|---|---|---|---|---|
| WhatsApp groups (status quo) | Chat | ✗ | ✗ | ✗ | ✓ | ✗ |
| IndiaMART / Udaan | ✗ | Partial | Partial | ✗ | ✗ | ✗ |
| Generic auction platforms | ✓ | ✓ | Partial | ✗ | ✗ | ✗ |
| ERP / inventory tools | ✗ | Internal | ✗ | Partial | ✗ | ✗ |
| 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.
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.
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.
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.
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.
- 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.
- 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.
- 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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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.
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 screens03 · Seller Flow
3 screens04 · Buyer Flow
4 screens05 · Logistics Flow
3 screens06 · Alerts & Settings
2 screens07 · Seller Hub
7 screens08 · Seller · Market Offers
3 screens09 · Seller · Reports
1 screens10 · Seller · Catalogue Price Lists
4 screens11 · Buyer · Market Offers
5 screens12 · Buyer · My Buying Bids
3 screens13 · Buyer · My WTB Requests
6 screens14 · Buyer · My Confirmed Orders
8 screens15 · Buyer · Market WTB
1 screens16 · Logistics · Stock Verification
4 screens17 · Logistics · Confirmed Deals
6 screens18 · Seller · Order Status
6 screens19 · Admin · Dashboard
1 screens20 · Admin · User Management
4 screens21 · Admin · Deal Management
2 screens22 · Admin · Payment Management
3 screens24 · Payments & Subscriptions (All Roles)
4 screensOutcomes
- 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.
Next case study
All work →Currently viewing: Nexora