Case Study

Alahdeen

B2B Marketplace

From disconnected wholesale channels to a shared B2B marketplace.

Zyvor partnered with Alahdeen to design and build a multi-vendor B2B marketplace where wholesale buyers, suppliers, catalogs, storefronts, leads and quotations could live in one commercial system — across web and mobile.

View Live Product Get in Touch

A stronger commercial foundation.

Buyers discover. Sellers operate. One marketplace.

Industry

B2B Marketplace / Commerce

Services

Product Strategy, Architecture, Design, Web & Mobile Development

Engagement

Product engineering with strong architecture

Timeline

April 2022 – June 2024

Product type

Multi-vendor B2B marketplace

Case study structure

Overview Challenge Strategy Design Solution Development Key Features Outcome Technology

Overview

What this engagement was about.

Product pressure

What the business needed to make true before the next stage of growth.

Delivery path

How strategy, design, and engineering stayed connected through the engagement.

Operating model

The decisions that kept ownership, state, and next actions clear for the team.

Outcome lens

Why the work was sequenced for trust, scale, and a reusable foundation.

Challenge

B2B commerce needed more than a conventional storefront.

Wholesale buying is not a simpler version of retail. Suppliers own catalogs, buyers need discovery and commercial enquiry, and seller operations have to stay connected to the same marketplace data.

Product pressureState gapsNext action

Signal

Marketplace homepage

Context

Marketplace architecture, not only commerce UI.

Buyer-facing marketplace discovery across categories, suppliers, and product areas.

Business problem

The platform had to support multiple suppliers, large product sets, commercial leads and quotations without collapsing into a generic catalog website.

User problem

Buyers needed to find products and suppliers. Sellers needed workflows for storefronts, catalog ownership and marketplace activity.

Operational limitation

Leads, quotations and seller work could not live in email or admin back-office if the marketplace was going to scale.

Product limitation

Traditional eCommerce patterns ignore supplier ownership, quotation states and separated buyer/seller experiences.

What was breaking

The friction points that made the old approach expensive to keep.

Supplier data treated like a static brand label

No shared catalog ownership model

Leads and quotations bolted on too late

Seller operations depending on manual admin work

Web and mobile drifting into separate business logic

Strategy

Treat the marketplace as a commercial domain.

If buyers and sellers could share one catalog and one set of commercial states, the product could grow suppliers, categories and channels without rebuilding the marketplace twice.

Separate buyer discovery from seller operations

Give suppliers real ownership of products and storefronts

Make leads and quotations visible, stateful workflows

Serve web and mobile from reusable APIs

Solution

A collaborative, end-to-end partnership.

Zyvor designed a shared marketplace domain first, then built the buyer and seller surfaces, catalog services and commercial workflows that connect web and mobile.

Discover

Mapped wholesale buyers, suppliers, catalog ownership, leads and quotations as one commercial system.

Define

Shaped the marketplace model: supplier storefronts, product ownership, search and commercial states.

Design

Created distinct buyer and seller experiences over the same catalog and activity model.

Build

Implemented catalog, search, storefronts, leads, quotations, seller mobile and reusable APIs.

Launch / Scale

Validated integrations and release support so supplier and catalog expansion could continue.

Strategy — Key Decisions

Marketplace architecture before storefront polish.

These are the choices that shaped the product — not a gallery of what shipped, but why the work was sequenced this way.

Multi-vendor marketplace model

A conventional storefront cannot represent supplier ownership, competing catalogs or seller operations.

Buyer and seller experience separation

Each side needs a different journey, but they still have to agree on products, leads and quotation state.

Shared product catalog with ownership rules

Search, storefronts and mobile channels only stay consistent if the catalog is a shared service.

Explicit lead and quotation lifecycle

B2B enquiry is a workflow with states, not a contact form attached to a product page.

Reusable web and mobile APIs

Seller mobile and buyer web had to grow from the same commercial logic instead of two codepaths.

Design

Discovery for buyers. Operations for sellers.

Buyers should find products and suppliers quickly. Sellers should manage storefronts, catalog and commercial activity without leaving the marketplace.

The interface should reveal the commercial model: who owns the product, how enquiry works, and what happens after a lead is created.

Category, search and product-detail paths for buyer discovery

Supplier profiles and storefronts as first-class destinations

Quotation and lead surfaces connected to product context

Mobile seller workflows aligned with the same marketplace states

Trust, clarity and accessibility

Supplier identity has to feel real, not like a product filter

Commercial next steps should be visible from the product page

Web and mobile should not disagree on catalog or activity status

Marketplace homepage

Buyer-facing marketplace discovery across categories, suppliers, and product areas.

Search experience

Product search experience connected to the marketplace catalog.

Supplier storefront

Supplier-owned storefront experience inside the shared marketplace model.

Development

From marketplace model to a working commerce platform.

The build used Laravel, Node.js, relational data, catalog/search services, media storage and notification services so web, Android and APIs could share one commercial core.

Commerce stack

Laravel, Node.js, REST APIs and relational data for marketplace operations.

Catalog services

Shared product, category, search and media services across channels.

Seller mobility

Android seller application connected to the same marketplace workflows.

Cloud delivery

Notifications, analytics and cloud deployment to support live marketplace activity.

Key Features

The parts of the system that mattered.

Buyer marketplace

Discovery across categories, suppliers and product areas.

Search & catalog

Shared product catalog with filtering and product detail.

Supplier storefronts

Supplier-owned destinations inside the marketplace.

Leads

Commercial enquiry captured in marketplace context.

Quotations

Explicit quotation lifecycle instead of informal follow-up.

Seller workflows

Operations for catalog, activity and marketplace management.

Seller mobile app

Mobile seller experience connected to the same APIs.

Notifications

Marketplace activity surfaced to the right side of the relationship.

Outcome

A marketplace with room to add suppliers, not another storefront.

Alahdeen established a structured B2B marketplace where buyers could discover products and suppliers while sellers managed activity through connected workflows.

Buyer discovery that fits wholesale

Categories, search, storefronts and product pages work as a marketplace, not a single-brand shop.

Connected seller operations

Sellers can manage marketplace activity instead of relying on disconnected admin work.

Commercial workflows in the product

Leads and quotations are states in the system, not side conversations.

Reusable commerce foundation

Web and mobile share APIs, so catalog and supplier expansion does not require a rebuild.

Technology

Stack used on this product.

The tools that supported delivery — chosen for the product shape, not as a generic stack list.

Laravel

Node.js

REST APIs

Relational Database

Search & Catalog Services

Android Application

Media Storage

Notification Services

Analytics

Cloud Deployment

Key Takeaways

What made this engagement successful.

Design supplier ownership first

B2B marketplaces fail when suppliers are treated as labels on products instead of operators in the system.

Separate the two journeys

Buyer discovery and seller operations need different UX over the same commercial truth.

Make commercial states explicit

Leads and quotations only work when the product can explain what happens next.

Share logic across channels

Web and mobile should reuse catalog and workflow services, not invent parallel marketplaces.

Next step

Have a similar challenge?

If this story feels close to the pressure in your product, the useful next step is a conversation about the problem — not another gallery of screens.