Our method: Blue Ocean positioning and StoryBrand messaging - how we build sites that win
Services - E-commerce

Online shops you own.

Most stores are rented: a monthly fee, a cut of every sale, and a shop shaped by whatever the platform decided commerce should be. We build the alternative on Medusa - open source, no per-sale fee, and a checkout you can shape around how your buyers actually purchase.

B2B and trade stores

Account pricing, volume breaks and permitted catalogues driven from your own systems, so a logged-in buyer sees their price rather than phoning their rep.

ACCOUNT PRICING · REORDER · CREDIT

Quote to order

Plenty of B2B purchases need a quote, a PO or internal sign-off before they are an order. That path gets built alongside instant checkout, not instead of it.

QUOTES · POS · APPROVALS

Connected to your systems

Stock, pricing, accounts and orders live in your ERP. We connect them so the store is a live window onto the business, not a second set of numbers to keep wrong.

ERP · STOCK · ORDERS

Why an owned store beats a rented one.

Medusa for the commerce engine, Next.js for the storefront, Render to run it.

No cut of every sale

A revenue share is invisible at low volume and grows precisely as you succeed. Owning the engine turns it into a predictable hosting bill.

Pricing logic without permission

Contract pricing and approval flows get built, rather than worked around on a platform designed for card-paying consumers.

We will talk you out of it

If a hosted platform fits your requirements, that is the cheaper answer and you should take it. We would rather lose the build.

What e-commerce website design and development actually costs.

Our stores start at £12,000, and it is worth being precise about what moves that number, because it is rarely what people expect. Page count barely matters. The cost drivers are the structure of the catalogue (a hundred simple products is a smaller job than thirty configurable ones with specifications and variants), the pricing logic (one list price for everyone is trivial; per-account contract pricing with volume breaks is engineering), and the integrations - whether an order has to reach an ERP, stock system or accounts package rather than an inbox.

A hosted platform prices differently: a monthly subscription, apps on top, and on most plans a percentage of every transaction. At low volume that is genuinely cheaper than a build, which is why we recommend it for simple shops. The crossover comes as volume grows and the percentage compounds, or the moment your pricing model stops fitting what the platform permits - the point where you start paying developers to fight the platform instead of extend it.

Integration work is priced after technical discovery against your actual systems, never from a feature list. That discipline is the same one we apply to software generally: the surprises in commerce projects live in the pricing rules and the data quality, and the cheap place to find them is week one.

Stores from £12,000Integrations scoped after discoveryNo percentage of your sales

Owning the checkout is a strategic position, not a technical preference.

Every rented platform makes the same trade: convenience now for control later. The checkout is where that trade bites, because the checkout is where your pricing model, your payment terms and your customer relationship actually live. On a consumer platform those are configuration options, and your business model has to fit inside whichever options exist. A trade business offering credit terms, negotiated pricing and purchase-order flows is not a configuration of a consumer shop - it is a different machine.

Medusa changes the ownership, not just the bill. The commerce engine is open source, the code and data are yours, the payment account is in your name, and a pricing rule the platform never anticipated is an afternoon of engineering rather than a workaround stacked on an app on a plugin. That is also the honest reason it is not for everyone: ownership means somewhere to run it and someone accountable for it, which is what Render and the retainer are for.

The direction of travel matters too. More B2B purchasing is moving online, buyers increasingly expect consumer-grade ordering at trade terms, and the businesses that own their commerce stack get to meet that expectation at their own pace - not at their platform's.

Replatforming without losing the trade you already have.

Most stores we build replace an existing one, and the replatform is where the commercial risk concentrates. The store that exists has rankings, customer accounts, order history and buying habits, and all four are easy to destroy with an enthusiastic migration. The discipline is unglamorous: baseline current behaviour before touching anything, map every product and category URL one-to-one for redirects, migrate accounts and order history rather than asking customers to start again, and switch over in stages where the risk is high.

The redirect map deserves particular respect in commerce, because product URLs carry rankings that took years to earn and category pages often outrank the homepage. A blanket redirect to the new homepage reads as a soft 404 to search engines, and the traffic loss lands in the same quarter you are trying to justify the build.

The measure of a good replatform is that your buyers barely notice - the store just got faster, the prices are still theirs, and reordering still works from muscle memory. The improvement shows up in the numbers, not in a retraining exercise for your customers.

Why it’s different

Why an owned store beats a rented one.

The monthly fee is not the real cost of a rented platform. The real cost is the shape of the shop you are allowed to build, and the percentage that leaves on every order you win.

The per-sale cut compounds

A revenue share is invisible at low volume and material at scale, and it grows precisely as you succeed. An owned store converts that variable cost into a fixed, predictable hosting bill.

Trade selling breaks consumer platforms

Account pricing, volume breaks, credit terms, POs and approval flows are normal in B2B and awkward-to-impossible on a platform designed for card-paying consumers. Working around that is where budgets disappear.

The integration is the project

Stock, pricing and accounts already exist in your ERP. Most of the value is connecting them, and most of the risk is in the edge cases - which is why we price that part after looking at your real systems.

We will talk you out of it

If your requirements fit a hosted platform, that is the cheaper answer and you should take it. We would rather lose the build than sell you engineering you did not need.

The programme

What's in every e-commerce build.

Five workstreams from first conversation to trading store. Smaller stores use a subset; trade stores with integrations use all five.

Commerce discovery

The pricing logic surfaces here, or it surfaces in month three.

  • Catalogue and pricing-rule audit
  • Systems map: ERP, stock, accounts
  • Platform recommendation, including 'use Shopify'
  • Itemised scope and timeline

Catalogue and data

The unglamorous work that decides whether the store ranks and converts.

  • Products modelled as structured data
  • Variants, specifications and filtering
  • Category structure from how buyers search
  • Migration mapping from the old store

Storefront design and build

A shop front that loads like a marketing site.

  • Next.js storefront, built for Core Web Vitals
  • Design reviewed on working pages
  • Basket, checkout and account flows
  • Product schema and SEO foundations

Commerce engine

Medusa, configured to how you actually trade.

  • Payment provider in your name
  • Tax and shipping rules, not defaults
  • Account pricing and quote-to-order where needed
  • Order flow into your systems

Launch and trade

Staged, measured, reversible.

  • Redirect map for every product URL
  • Accounts and order history migrated
  • Staged switchover with monitoring
  • Post-launch conversion programme
What happens, and when

What happens, and when.

Weeks 1 to 2

Technical discovery

Catalogue, pricing rules and systems audit against your real data, ending in an itemised scope. The surprises in commerce projects are always in the pricing logic, and this is where they should surface.

Weeks 3 to 8

Storefront and commerce build

Catalogue and pricing modelled, storefront designed and built, checkout and payment configured, reviewed weekly on a working URL rather than in mockups.

Weeks 6 to 10

Integration and migration

ERP, stock and account connections proven against live systems, products and URLs mapped for redirects, accounts and order history migrated.

Week 10 onward

Launch and trade

Staged switchover with monitoring, then the ninety days after launch where the conversion work actually pays - because a store gives you far better data than a brochure site ever will.

Honest fit

Is an owned store right for you?.

A good fit when

  • Pricing is per-account, contracted or volume-based rather than one list price for everyone
  • The catalogue is large or structurally complex, with specifications, variants or filtering that matter
  • Orders need to reach an ERP or stock system rather than an inbox
  • Some buyers need a quote, a PO or internal approval before they can order
  • Platform fees and revenue share have become a number worth engineering away

Not the right buy when

  • You sell a small catalogue at list price for card payment - Shopify is cheaper and faster, and we will tell you so
  • You need to be trading in three weeks; an owned store is a build, not a signup
  • Nobody internally owns product data; a store exposes every inconsistency your team has been working around

Fair questions.

Scoped stores start at £12,000 with us, covering catalogue and pricing modelling, storefront design and build, checkout and payment configuration, and deployment. ERP, stock and account-pricing integrations are priced separately after technical discovery. A simple card-payment shop on Shopify costs far less, and we will say so if that is what fits.