What was actually wrong
Scruffs needed an ecommerce platform that could carry trade account ordering, repeat purchase patterns and operational reporting expected by a Builders & trade business.
Order flow, stock and customer data crossed several back-office systems, so integration boundaries and operational handoffs likely shaped how the platform was built.
Trade buyers and account customers needed account-based pricing, repeat ordering and visibility of their own purchase history without friction.
The commerce layer had to sit cleanly alongside ERP, without turning every operational dependency into a launch risk.
Account-led ordering and self-serve buying had to live on the same stack without one audience compromising the other.
A new commerce surface had to land cleanly inside an operating business, not as a standalone project.
The platform change also depended on product information being structured, enriched and governed well enough to support the catalogue. Product data was a major workstream within the wider commerce delivery, not a separate outcome claim.
What was at stake
When account-based pricing, repeat ordering and purchase-history visibility slip, trade and account customers lose confidence in the site and push work back onto sales and support.
Most relevant to Builders & trade teams running B2B, B2C and D2C operations and weighing similar platform decisions.
Trade accounts do not give second chances. A bad first experience pushes the order to a competitor and the relationship rarely comes back.
For repeat buyers and trade accounts, uncertainty creates friction every time an order is placed again. Wrong-part risk, unclear account terms and a harder repeat-order path can frustrate buyers and move the burden back to account teams and support.
Five things, in order.
- 01Mapped the buying journey before the interfaceStarted with how customers actually order here: account relationships, repeat-buy patterns and the operational context behind each purchase.
- 02Rebuilt the commerce foundation around how the business operatesRebuilt the commerce surface inside the operating business, not as a standalone project.
- 03Connected the systems that the storefront cannot work withoutThe commerce layer had to sit cleanly alongside ERP without coupling the launch to every system on day one.
- 04Brought product data into one governed workstreamProduct information, enrichment and catalogue structure were treated as a delivery workstream that enabled the commerce change.
- 05Scoped the rules per audience, not per platformAccount-led ordering and self-serve buying were shaped as distinct journeys on the same foundation.
Platforms and integrations
Difficult parts
Results
In the client's words
iWeb have been our partner now for more than 15 years. In all honesty we haven’t been able to find a better digital partner. They've delivered, they are a talented team and they've grown in line with our expectations.”
Ongoing support
The project did not end when the platform went live.
Support mattered because the builders and trade still depended on parts data, pricing imports, account behaviour, inventory feeds, integrations and customer-facing information after launch.
Keeping the build decisions and system ownership visible gave the support team a clearer basis for tracing issues and maintaining the connected trading system after launch.
Projects with a similar shape
A timber merchant PWA rebuilt around branch trading, stock visibility and trade ordering.
Timber merchant operations supported by stronger catalogue scale, adoption and page speed activity.
A builders' merchant platform built around online sales, trade accounts and order value.
Trade commerce supported by stronger online sales, active account activity and higher average order value.
A builders' merchant platform rebuilt around search, engagement and trade customer ordering.
Merchant trading supported by stronger search activity, engagement and faster routes to market.