Catalogue architecture and search
Category structure and filters built around how buyers specify parts, with search tuned for product codes, partial codes and the wrong spellings people actually type.
Build & Measure
Storefronts built for trade buyers.
Contract pricing, quantity breaks and a checkout a purchasing manager can finish in under a minute. Consumer store patterns do not survive contact with a four thousand line catalogue and negotiated terms.
- Checkout for returning buyers
- Two steps
- Catalogue scale
- Defined during discovery
- Performance budget
- LCP under 1.3 s
- Typical build window
- Eight to fourteen weeks
What the engagement covers
Catalogue, pricing, checkout and the systems behind them.
A trade store is mostly an integration problem wearing a design. If stock and pricing are wrong, no amount of layout work will save the order.
Contract pricing and quantity breaks
Customer-specific pricing shown on the product card, with volume tiers visible before anything enters the basket. No logging in twice to find out what something costs.
Checkout and repeat ordering
Saved delivery profiles, purchase order references, reorder from history and bulk entry by product code. Most trade orders are a variation of a previous one.
Payments and invoicing terms
Card, transfer and account-based purchasing on agreed credit terms, with EU VAT handling and reverse charge applied correctly on cross-border orders.
ERP and stock integration
Live stock, lead times and pricing pulled from your system of record, with a defined fallback when the connection drops so the store degrades rather than lies.
Merchandising and analytics
Product-level reporting on search terms with no results, abandoned baskets by category and margin by customer segment, instrumented as part of the build.
Why this works
Four rules taken from trade buying, not retail.
A purchasing manager placing a repeat order is not shopping. They are completing a task under time pressure, and every persuasion technique borrowed from consumer retail gets in their way.
-
Trade pricing belongs on the product card
When contract prices appear only at the final checkout step, buyers cannot verify terms while browsing. Our design standard surfaces customer pricing and quantity breaks at catalogue level, then validates the effect against the client's baseline.
-
Repeat orders are the whole business
In distribution, the majority of revenue is reordering. We build for that first: order history, saved profiles, bulk entry by code and one-click repeat. Optimising first-time purchase flows while ignoring reorder is how stores end up with high traffic and flat revenue.
-
Search is the primary navigation
Above roughly two thousand products, buyers stop browsing categories and start typing codes. Search that fails on a partial code or a transposed digit sends the order to a competitor, so we test it against your real search logs rather than assumptions.
-
Stock accuracy beats every persuasion tactic
One order shipped short costs more trust than a year of interface improvements can rebuild. Integration and its failure modes are designed before any layout work begins, because this is the part that actually decides whether buyers come back.
What you get
Standards we accept in the contract.
These are delivery standards and example acceptance criteria, not historical outcomes. Commercial targets are set against the client's current baseline during the store review.
Baseline set
Average order value target
Current order value is documented before release; the signed scope defines the improvement target and measurement window.
Two steps
Checkout acceptance criterion
Known buyers move from basket to confirmation in two screens once delivery and purchase-order details are available.
1.3 s
Largest contentful paint
Performance budget for category and product templates, tested at the agreed catalogue scale on mid-range mobile hardware.
Two steps
Checkout for known buyers
Basket to confirmation in two screens once a delivery profile and purchase order reference exist on the account.
The detail
Process, team and integrations.
The integration review comes first and is quoted separately. Pricing a commerce build before anyone has seen how your ERP exposes stock and customer pricing produces a number that will not survive week three.
Discuss a build- Discovery
- Catalogue audit, pricing rules mapping, integration review
- Team assigned
- Front-end developer, integrations engineer, UX specialist
- Platforms
- Headless commerce, or a new front end on your existing platform
- Integrations
- ERP, stock, payment gateways, invoicing and credit terms
- Testing
- Real-device checkout runs, load testing at full catalogue scale
- Handover
- Repository, integration documentation, 30 days support
Questions we are asked first
Before you send a brief.
If your question is not here, write to info@bari-buti.com and you will get a direct answer from the engineer who would build it.
Yes, and it is usually the largest single task. Trade catalogues carry years of inconsistent attributes, duplicate codes and images at mixed quality. We audit and normalise during discovery and tell you honestly which parts need a decision from your product team, because guessing at technical attributes creates returns.
That is the core requirement of a trade store. Pricing resolves per account against your ERP rules, including negotiated rates, volume tiers and promotional overrides, and it is cached carefully so the catalogue stays fast without ever showing one customer another customer's terms.
Anything with an API or a reliable scheduled export, which covers most systems in use including older on-premise installations. The integration review establishes what your system can actually expose and how often. Where it cannot support live stock, we design a synchronisation window and show that clearly to the buyer rather than pretending.
VAT number validation at account level, reverse charge applied where it is due, and rates resolved by destination and product classification. We work to the rules your accountants confirm rather than a plugin's defaults, because getting this wrong is expensive in a way an interface bug never is.
Often yes, and it is usually cheaper. Replacing only the front end while your existing platform continues to handle orders and stock removes most of the risk of a full migration. The review states plainly whether your platform can support contract pricing and a two-step checkout, or whether it is the actual constraint.
Works well with
The disciplines that compound this one.
A store is a machine for converting demand. These three create the demand and prove which part of the machine is earning.
Next step
Give us a buyer login, and we will place an order the way your customers do.
The store review walks your real checkout on real hardware, then reports where orders are being lost and what each fix is worth in order value.