Meridian Supply
A B2B distributor moves platform with account pricing, ERP integration and a redirect map built from crawl and analytics data.
Replatformed without losing ground
03 · Build
An online store is an operational system, not a website with a basket. It has to hold an accurate catalogue, price correctly for different customers, take payment reliably, tell the warehouse what to ship, tell finance what was sold, and stay fast while doing it.
We build and improve commerce systems on the platform that fits how you sell – and we treat the parts that decide revenue, the catalogue and the checkout, as engineering problems rather than design details.
The expensive failures are rarely visual. They are in the catalogue model, the checkout, the integrations, and the gap between what the site says and what the warehouse knows.
New stores and replatforms on Shopify, WooCommerce or a custom build, with a catalogue and taxonomy modelled on your real range rather than forced into a default structure.
Customer-specific pricing, account hierarchies, quote and approval flows, purchase orders, credit terms, bulk and repeat ordering, and restricted catalogues.
Payment gateway integration including multi-currency and local methods, tax handling across jurisdictions, shipping rules and carrier integration, and returns handling.
One source of truth for products, prices, stock and orders, synchronised reliably in both directions – with failure handling that surfaces problems instead of silently losing them. See digital systems.
Step-by-step funnel analysis, checkout simplification, guest checkout, address and payment validation, and clear delivery and cost expectations set before the final step.
Category and product page speed, image strategy, script auditing – app and tag bloat is the most common cause of slow storefronts – and Core Web Vitals work on the templates that carry the revenue.
The platform is chosen against your catalogue, your selling model and your operations.
Strong default for most B2C and many B2B stores. Hosted, reliable checkout, good operational tooling, large ecosystem. The trade-offs are platform fees, checkout customisation limits below the top tier, and app sprawl if it is not governed.
Good where the store sits inside a content-heavy WordPress site and where full control of data and hosting matters. Requires deliberate hosting, caching and maintenance – it is not lower-effort, just differently distributed effort.
Right when the selling model does not fit a platform – complex B2B pricing, configurable products, unusual fulfilment – or when the storefront has performance requirements a themed platform cannot meet.
More on how we weigh these decisions on the technology page.
Every engagement follows the same sequence, with a defined output at each stage and nothing proceeding on an assumption that has not been written down. Build work sits inside that process rather than alongside it.
That is the goal of every replatform we run, and it is a defined workstream: URL mapping, redirect implementation, structured data parity and crawl comparison before and after. See migration.
Both. A large share of our commerce work is improving stores that already trade – performance, checkout, integrations and data model – because that is usually where the return is fastest.
Yes, provided it exposes an API or a supported exchange format. We scope integrations during discovery, because their complexity is the most common cause of commerce projects overrunning.
Send us the store and the step you think is losing people. We will tell you what we see in the data before proposing anything.
Or email hello@applystudio.com – we reply within one business day.