Where commerce projects lose money

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.

  • Traffic is steady but checkout completion has been falling and nobody knows at which step.
  • Category pages are slow, which costs both conversion and search visibility.
  • Stock and pricing are maintained twice – once in the ERP and once in the store.
  • B2B customers need account pricing, quotes or purchase orders and the platform cannot express it.
  • The product data model cannot represent how the range is actually organised.
  • Every promotion needs a developer.

What we do

Store development

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.

B2B commerce

Customer-specific pricing, account hierarchies, quote and approval flows, purchase orders, credit terms, bulk and repeat ordering, and restricted catalogues.

Payments and shipping

Payment gateway integration including multi-currency and local methods, tax handling across jurisdictions, shipping rules and carrier integration, and returns handling.

ERP, CRM and stock integration

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.

Checkout and conversion work

Step-by-step funnel analysis, checkout simplification, guest checkout, address and payment validation, and clear delivery and cost expectations set before the final step.

Commerce performance

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.

Diagram

A catalogue modelled on the real range, with the category and product templates that carry the revenue.

How we approach commerce

  1. Model the catalogue before designing the store Products, variants, options, bundles, attributes and categories are defined against your real range first. Almost every intractable commerce problem traces back to a data model that was decided by a theme.
  2. Treat checkout as critical infrastructure Every field, step and error state in the checkout is deliberate, tested on real devices, and measured. This is the highest-value surface on the site by a wide margin.
  3. Integrate with failure in mind Integrations are built to handle the API being down, the record being malformed and the sync running twice – with retries, idempotency and alerting, not silent failure.
  4. Guard performance against app creep Third-party apps and tags are the main reason storefronts get slow. We audit what each one costs in milliseconds and give you the trade-off explicitly.
  5. Measure the funnel properly Full commerce event tracking so that "checkout is broken" becomes "12% of mobile users drop at the shipping step". See analytics.

What you receive

  • Production store, responsive and performance-tested on real devices
  • Catalogue and taxonomy modelled to your range, with import tooling
  • Configured payment, tax and shipping rules
  • Integrations with your ERP, CRM or stock system, with monitoring
  • Commerce analytics and full funnel tracking
  • Checkout and product template performance results
  • Operational documentation for merchandising and order handling
  • Team training and post-launch support window

Choosing a commerce platform

The platform is chosen against your catalogue, your selling model and your operations.

Shopify

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.

WooCommerce

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.

Custom or headless commerce

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.

Read the full process, stage by stage

Common questions

Can you replatform without losing search traffic?

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.

Do you work on existing stores, or only new builds?

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.

Can you connect the store to our ERP?

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.

Store not converting the way it should?

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.

Message us on Telegram (opens in a new tab)