Building a custom B2B ecommerce portal for a UAE wholesale business using the MERN stack

Home / Case studies / B2B ecommerce portal for a UAE wholesale business

B2B ecommerce development is a different job from building a shop. In this wholesale ecommerce case study from the UAE, the client already had demand, established trade customers and agreed prices. What it did not have was a way for those customers to buy online without a phone call. Orders arrived by email, WhatsApp and phone, prices were checked against a spreadsheet, and the same quotation was rewritten every few weeks for the same buyer.

Tomsher's Dubai-based team built a custom B2B ordering portal on the MERN stack, MongoDB, Express.js, React and Node.js, designed around how wholesale customers actually buy and how the sales team manages their accounts. This B2B ecommerce development case study explains the requirement, the wholesale ordering portal that was delivered, and what changed for buyers and staff. The client is not named, and all screenshots are anonymised.

B2B ecommerce portal project at a glance

The challenge, wholesale orders managed manually

A wholesale ecommerce website in the UAE has to fit an ordering process that already exists, and this one was entirely manual. The business was handling roughly 430 trade orders a month this way. Discovery sessions with the sales and accounts teams produced five clear problems.

• Orders arriving through several channels. Email, WhatsApp, phone calls and occasional walk-ins, with no single place where an order officially existed.
• Manual price checks on every order. Agreed prices for 160 accounts sat in spreadsheets outside the ordering process, so no order could be confirmed until someone looked them up, taking about six minutes per order.
• Incomplete order details. Messages arrived without pack sizes, variant codes, delivery addresses or purchase order references, so confirming one order took several replies.
• Repeated quotation work. Around 70 quotation requests a month came in, many of them repeats from the same buyers, and each was rebuilt from scratch with a median turnaround of two working days.
• No self-service for buyers. A customer who wanted to reorder last month's pallet had to ask someone to look up what last month's pallet contained.

None of this was a technology failure. It was a process that worked at a smaller size and stopped scaling, which is the usual reason a distributor portal project starts.

Understanding the wholesale buying process

Wholesale ecommerce development starts with rules, not screens. Before any design work, the team documented how the business already traded, because the portal had to encode that rather than replace it.

• Account approval. Who qualifies as a trade customer, what the business needs before an account is activated, and who inside the company approves it.
• Pricing arrangements. Which customers are on negotiated prices, which sit on tier or volume pricing, and how special prices on specific lines are recorded.
• Order quantities. Minimum order values, minimum order quantities per product, pack sizes and multiples that cannot be broken.
• Buying steps. What a buyer does before placing an order, including internal approval, a quotation and a purchase order reference.
• Payment and terms. Which accounts pay on invoice against credit terms and which pay up front.
• Sales ownership. Which salesperson owns which account, since quotations and order queries route to them.

That document became the specification. Every rule in it is enforced in the portal, which is the reason the sales team trusts the totals it produces.

Why MERN suited this B2B portal development project

MERN stack B2B portal development suited this project because almost none of the functionality was standard. Customer-specific pricing, pack-size logic, quotation workflows and role-based account access are business rules, and they had to be modelled exactly, not approximated with plugins.

Custom MERN ecommerce development gave the team one data model for accounts, prices and orders, and one set of APIs shared by the buyer portal and the staff screens, so a price is resolved by the same logic wherever it appears. Using the MERN stack does not by itself make a portal fast, scalable or search-friendly, so those qualities came from how the application, the queries and the interfaces were built.

Business accounts and customer-specific pricing

B2B ecommerce customer-specific pricing was the feature that made the portal usable as a wholesale pricing portal rather than a public shop with a login.

• Approved accounts only. Trade pricing is visible only after a customer's account has been approved and the user has signed in. Unauthenticated visitors see products and information, never account prices.
• Account roles. A company account can hold several users, with roles that separate a buyer who places orders from a viewer who only reviews, and an account owner who manages users.
• Price resolution order. A special price agreed on a specific product is applied first, then the account's negotiated price list, then its pricing tier, then the standard trade price. The rule is applied server side, so the price shown, the price in the cart and the price on the order are always the same number.
• Prices tied to the account, not the session. Every user on an account sees that account's pricing, and switching device or browser changes nothing.
• Payment terms shown where relevant. Accounts on credit terms see their terms at checkout, and accounts without them are directed to payment.

Keeping negotiated prices behind authentication mattered commercially as much as technically. Wholesale pricing is competitive information, and no account price is retrievable without a signed-in, approved user.

Bulk ordering and repeat purchases

Bulk ordering in ecommerce works nothing like a consumer basket. A wholesale buyer usually knows the codes, orders in pack multiples and repeats last month's order with small changes, so the portal was built for speed rather than browsing.

• SKU quick entry. A buyer who knows the codes types them with quantities and builds a full basket in one screen, without opening a product page.
• Pack size and minimum order quantity rules. Quantities snap to valid multiples, minimums are enforced per product, and the cart explains why a quantity changed instead of silently correcting it.
• Quantity price breaks. Where a price improves at a quantity threshold, the break is shown on the product and applied in the cart.
• Repeat ordering from history. Any previous order can be reordered in one action, then edited, which covers the most common wholesale purchase pattern.
• Saved lists. Buyers keep standing lists of the products they order regularly and load them into a basket.
• Purchase order reference at checkout. The buyer's own purchase order number is captured with the order and carried onto the confirmation, so accounts can match it later.

Wholesale order automation here is not about removing the salesperson. It is about removing the five messages needed to agree what was already agreed.

Quotation requests and sales follow-up

A B2B ecommerce quotation system was essential, because a large share of wholesale buying starts as a request rather than an order. The RFQ functionality follows five steps.

1. The buyer submits a request. From a basket, a saved list or a blank form, with quantities, delivery requirements and notes attached.
2. It reaches the account's salesperson. The request appears in the staff dashboard, assigned to the person who owns that account, with the customer's history visible beside it.
3. Sales prepares the quotation. Prices can be adjusted line by line within the rules, with validity dates and delivery terms added.
4. The buyer reviews it in the portal. The quotation is visible in the customer's account rather than buried in an email thread, with its status and expiry shown.
5. Accepted quotations become orders. The buyer converts an accepted quotation into an order at the quoted prices, with the purchase order reference added at that point.

Because quotations and orders share one data model, a repeat request does not start from a blank page. The salesperson opens the previous quotation for that account and works from it.

A simpler experience for buyers and staff

The portal replaced a manual process on both sides. This is the practical difference.

Testing and project outcomes

B2B ecommerce website development is judged on whether the numbers are right, so testing concentrated on pricing, permissions and quantities rather than appearance alone.

• Pricing verification. Account and special prices were tested across sample accounts, with the price on the product page, in the cart, on the quotation and on the final order compared line by line.
• Permission testing. Each role was tested for what it can see and do, including confirming that no account pricing is reachable without an approved, signed-in user.
• Quantity rule testing. Pack multiples, minimum order quantities and price breaks were tested at and around each threshold.
• Order total checks. Line totals, discounts, delivery charges and VAT were reconciled against the finance team's expected figures before launch.
• Quotation lifecycle testing. Requests, revisions, expiry and conversion to order were run end to end.
• Staff walkthroughs. The sales and accounts teams worked live orders and quotations in staging before go-live.

What changed operationally is straightforward. Orders now arrive in one place, already priced and validated, with the buyer's purchase order reference attached. Quotations sit in the customer's account with a status and an expiry date instead of in an inbox. Repeat orders are placed by the buyer rather than assembled by the sales team. And every account's pricing lives in the portal, applied by one rule, rather than in a spreadsheet that only two people could read.

The figures below compare the 90 days before launch with days 91 to 180 after launch, once accounts had been onboarded.

Order volume and customer mix were broadly comparable across the two periods, and no pricing changes were made during the second period. Phone and email orders continue for a minority of accounts, which was expected rather than a failure of adoption.

Planning a similar B2B ecommerce portal

B2B ecommerce development in Dubai starts with a scoping conversation rather than a proposal. To assess a wholesale ordering portal, we need to know how your trade accounts are approved, how pricing is agreed and recorded, the order quantity rules you apply, whether quotations are part of your process, how payment terms work, and which systems hold your products, stock and orders today.

From that, we map the rules the portal has to enforce and the screens your sales team needs, then build it as a custom application. Our B2B portal development service covers wholesale and distributor portals, custom ecommerce development in Dubai covers the storefront side, and the application and API layer is built by our web application development team. Where prices, stock or invoices live in an ERP, our guide to ecommerce ERP integration explains how that connection is scoped.