If you sell to trade customers and still take orders by email, phone and a PDF price list, the answer is not a normal online store with a password on the front. A B2B store is a different piece of software: prices differ per customer, buying is repeat ordering rather than browsing, and payment often happens after delivery instead of at checkout.
That gap explains a common outcome. A wholesaler launches a store, the reps keep taking orders by email anyway, and everyone concludes the customers just prefer the phone. Usually the customers prefer whichever route is faster, and the store was slower than emailing Dave.
Why a retail store breaks the moment you point it at wholesale
Retail e-commerce assumes a stranger arrives, discovers a product, and pays with a card right now. Almost every one of those assumptions is wrong for trade sales.
Your buyer is not a stranger, they are account 4471 with a negotiated discount. They are not discovering anything, they are ordering the same twelve items they ordered last month. They may not be allowed to pay by card at all, because their company pays on terms against a purchase order. And your prices are frequently not something you want visible to the public or to competitors.
Bolt a login onto a retail store and you get a catalogue that shows one price to everyone, a checkout that demands a credit card, and no way to place a forty-line order without forty separate clicks.
Per-customer pricing is the hard part
This is where most wholesale projects live or die. The requirement is rarely "a discount". It is usually some combination of:
- Price tiers by customer group, such as distributor, dealer and installer.
- Negotiated pricing for specific accounts, on specific products.
- Quantity breaks, where the unit price drops at 10, 50 and 200 units.
- Case packs and minimum order quantities, so nobody can order three of something that ships in boxes of twenty four.
Before you scope anything, export what you actually have today. In many businesses the "price list" turns out to be a spreadsheet with several years of exceptions in it, and a few arrangements that live only in a sales rep's memory. Untangling that is real work, and it is better done before the build than during it.
Your buyers are reordering, not shopping
A trade buyer already knows the part numbers. Making them browse a category tree is the single fastest way to send them back to email.
What actually gets used:
- Quick order by SKU. A box where they type or paste part numbers and quantities, and it builds the order.
- Order history and one-click reorder. Most wholesale orders are a variation of a previous one.
- Saved lists. Standing kits, seasonal orders, per-jobsite lists.
- CSV or spreadsheet upload for the larger accounts who assemble orders in Excel anyway.
None of this is glamorous and all of it is the actual product. If placing a repeat order takes longer than writing the email, the portal will lose.
What about quotes and approvals?
Plenty of B2B sales are not a straight checkout. The buyer needs a price before committing, or someone else has to approve the spend.
Two features cover most of it. A request-a-quote flow, where a cart becomes a quote your team prices and returns, and the customer accepts it into an order. And multi-user company accounts, where a company has several logins with different rights, so a junior buyer can build a cart while a manager approves and submits it.
If you sell configured or made-to-order goods, the quote flow matters more than the catalogue. Get that path right first.
Purchase orders and payment terms
If your customers buy on terms, checkout has to accept that. In practice that means a PO number field carried through to the invoice, an option to place the order on account rather than paying immediately, and credit limits that your system respects instead of a rep noticing later.
This is usually the detail that decides whether finance supports the project. Bring your bookkeeper or controller into the scoping conversation early, not at launch.
Does it have to be custom?
Not necessarily, and starting custom is often the expensive mistake.
Shopify has a native B2B feature set covering company accounts and per-company price lists, but it is not included on every plan tier, so check what your plan actually gives you before assuming. Several other platforms cover the same ground. A custom build earns its keep when your pricing logic, product configuration or system integration is genuinely unusual, not merely detailed.
The honest test is the same one in Shopify versus a page builder versus a custom build: start from what your business actually requires, and only pay for custom where a platform cannot bend that far. We built NorvexTools as a B2B Shopify store rather than from scratch for exactly that reason.
The part that quietly costs the most: your existing systems
The store is rarely the expensive half. The expensive half is connecting it to the systems already running your business.
Stock levels have to come from somewhere real, or you will sell things you do not have. Orders should land in your accounting or ERP system without anyone retyping them. Customers and their pricing need to stay in sync in one direction, so there is a single source of truth rather than two drifting copies.
Ask one question early and answer it properly: which system owns each piece of data? If inventory lives in your ERP, the store reads it and never edits it. Deciding this at the start prevents most of the mess that shows up six months in.
Two other things save pain later. Trade customers often work on slow office connections and warehouse tablets, so the site needs to be genuinely fast, not just fast on your laptop. And if you sell into Quebec or to federal buyers, decide about French at the start rather than retrofitting it across a whole catalogue.
What it costs
B2B and e-commerce builds start at $2,900 CAD and run to $25,000 and beyond depending on scope. The spread is wide because the range covers everything from a straightforward catalogue with tiered pricing up to a portal with contract pricing, quote workflows, approvals and a live ERP integration.
What moves you up that range is almost never design. It is the number of pricing rules, the complexity of the quote and approval path, and how many systems have to talk to each other. If you want the general picture of what drives web project pricing, the cost breakdown covers it, and the pricing page shows the current ranges.
Where to start
Do not begin with the platform. Begin with one page of notes answering four things: how many distinct prices can one product have, what a typical repeat order looks like, whether customers pay at checkout or on terms, and which system holds your inventory today.
Most of the cost and most of the risk in a wholesale build is decided by those four answers. A studio that quotes you before asking them is guessing.
If you already have a store that your trade customers are not using, send it to us and we will tell you what is sending them back to email, whether or not you work with us.