B2B Commerce Platform for a Building-Materials Supplier

A building-materials supplier was taking trade orders by phone and WhatsApp — mis-heard quantities, no order history, and a sales team transcribing instead of selling. We built a B2B ordering platform for contractors rather than casual shoppers: a trade catalogue with specifications, account-based pricing, rapid re-ordering from history, and order workflows routed to the right depot — integrated with existing processes rather than replacing them. Here is why consumer e-commerce patterns fail in trade.

The challenge

Trade ordering looks like retail e-commerce and behaves nothing like it. A contractor does not browse. They order the same twelve SKUs repeatedly, in bulk, against a negotiated price list, on credit terms, to a site that is not their billing address. Consumer templates assume one price for everyone, payment at checkout, one delivery address and a shopper who needs persuading. Every one of those is wrong here.

Our approach

We started from the account, not the product. In a trade platform the account is the primary object: it carries the price list, credit terms, delivery addresses, authorised users and order history. Price is not a property of a product; it is a function of the product and the account viewing it, and getting that into the data model early is what makes everything downstream tractable. Second, re-ordering had to be the fastest path in the system, usable from a phone on site in under a minute. Third, the platform feeds existing depot, stock and credit processes clean structured data rather than replacing operations the warehouse already trusted.

Architecture and key decisions

Engineering effort belongs in account, pricing and fulfilment logic — not in re-implementing solved checkout problems. That principle runs through our custom application development work.

How we sequenced the work

Catalogue data first, because it is always the long pole: trade product data lives across a legacy system, several spreadsheets and two long-serving heads. Then accounts and pricing, since nothing is testable until a logged-in contractor sees their own price. Then ordering, depot routing and re-ordering. Then a pilot with a few frequent, tolerant customers before opening to the wider account base.

What to look for if you're commissioning this

Ask how account-specific pricing is modelled before you ask about design. If the answer involves discount codes bolted onto a retail platform, they will hit a wall at contract pricing. Ask how depot routing handles stock split across locations, and who maintains the catalogue afterwards. Be honest about your product data: inconsistent specifications are the project's real cost centre. And insist on integration with working processes rather than replacement — forcing warehouse and finance teams to change guarantees quiet non-adoption. Our build vs buy tool compares platform routes; e-commerce management covers the ongoing side.

Typical cost and timeline

General ranges for this class of work, not this client's figures. A focused trade platform — accounts, pricing, catalogue, ordering, re-order — typically runs three to five months. Add multi-depot routing, credit-limit enforcement and ERP integration and six to nine months is realistic. Data cleanup often consumes a fifth to a third of total effort. See our app cost estimator and pricing.

The outcome

Trade customers order at any hour without a phone call. Errors from verbal orders are gone, because quantities and codes are entered once by the person who wants them. The sales team spends its time on new accounts instead of transcription.

Frequently asked questions

Why can't I just use a standard e-commerce platform for trade sales?

You can start there, but standard platforms assume one public price, payment at checkout and a browsing shopper. Trade needs account-specific pricing, credit terms, multiple delivery addresses, authorised buyers per account and repeat ordering as the primary flow. Retrofitting those works for simple cases and gets expensive as contract pricing and fulfilment rules become realistic.

How do you handle customer-specific pricing without exposing other customers' rates?

Prices are resolved server-side against the authenticated account and never assembled in the browser, and price lists are scoped so a request can only return rates that account is entitled to see. Anonymous visitors see nothing or an indicative list price, depending on commercial preference. Leaked contract pricing damages negotiating positions, so this is a commercial control as much as a technical one.

Do I need ERP integration from day one?

Usually not, and insisting on it early is a common way to stall a project. A first release can run on scheduled synchronisation for stock and pricing plus structured order exports into the existing process. Real-time bidirectional integration is worth doing once the platform carries meaningful volume and the operational patterns are proven, rather than as a launch prerequisite.

How long does the product data work actually take?

Longer than anyone expects. Trade catalogues hold thousands of SKUs with inconsistent naming, missing specifications and pack quantities that exist only as tribal knowledge. Reconciling that commonly consumes a fifth to a third of total project effort, so it needs a named owner and its own workstream rather than being treated as an assumption.

If you sell to trade buyers and still take orders by phone, book a free 30-minute technical session via our contact page. For senior technical oversight rather than a build quote, start with fractional CTO.