Custom e-commerce vs platform: when a bespoke shop makes sense

A bespoke e-commerce build makes sense when the way you sell does not fit a product catalogue and a standard checkout: quote-based or calculated pricing, products that are really services or access, a shop that has to sit inside a bigger system, or platform fees that have grown larger than the cost of owning your own code. For everyone else, a well-built WooCommerce or Shopify store is cheaper, faster to launch and easier to hand over. In the UK a genuinely custom shop typically costs from about £8,000 to £30,000+ + VAT, against £1,000 to £5,000 for a good platform build.

We build both, so this is not a pitch for either. Below is how we decide, what each route costs over five years, and the risks you need to manage if you go custom.

What “bespoke” actually means

Agencies use the word loosely. A “bespoke shop” can mean a custom theme on WooCommerce or a system written from an empty folder. These are very different projects, so it helps to name the levels:

Most of the “we need bespoke” conversations we have end at level 2. It gives you custom behaviour exactly where you need it and keeps the boring, well-tested parts (orders, refunds, emails, tax, admin) that a platform has refined over years.

Signs a custom build is worth it

Your pricing cannot be expressed as a price list

Think of a Leeds print firm whose prices depend on size, paper, finish, quantity and turnaround, recalculated live as the customer changes options, with artwork upload and proofing. Or a Glasgow joinery business selling made-to-measure units priced from dimensions. You can force these into WooCommerce with add-ons, but past a certain complexity the add-ons fight each other and every change becomes fragile. A purpose-built pricing engine is often simpler and more reliable.

You are really selling a service or access

Memberships with tiered content, timed access to software, credits that are spent over time, donations with Gift Aid declarations and recurring gifts: these are not products in a basket. Platforms can approximate them with subscription plugins, but the model leaks. When we built a custom CMS and e-commerce donation platform for UNICEF, the “shop” was one part of a system shaped around campaigns and supporters, not a catalogue. Likewise KDMasterKey, the keyword-analysis software we built for self-publishers, sells access to a tool, which is a software problem first and a shop second.

The shop is part of a bigger system

If orders must flow into an ERP, a warehouse system, a CRM and an accounting package, each with its own rules, the integration work can outweigh the shop itself. At that point the shop is a front end on top of your operations, and building it around your data model (rather than around the platform’s) removes a lot of glue code. Our API development and integration work often starts here.

B2B rules that platforms handle badly

Account credit limits, customer-specific price lists, approval workflows where a buyer raises an order and a manager signs it off, minimum order quantities by customer group, invoices on 30-day terms. A Birmingham wholesaler with three of those can live on WooCommerce with custom plugins. One with all of them, plus sales reps placing orders on behalf of customers, will usually be happier with a custom system.

Platform costs keep climbing

Hosted platforms charge monthly fees, app subscriptions and sometimes a share of revenue. For a store turning over a few million pounds with a dozen paid apps, those costs can reach tens of thousands of pounds a year. Owning the code turns that into a build cost plus maintenance. Run the numbers before assuming either way; the comparison below shows how.

Signs you do not need one

Be honest with yourself here, because a bespoke build is a long-term commitment.

• You sell physical products with standard variations (size, colour) at fixed prices.
• Your turnover is under about £500,000 and your processes are fairly standard.
• You need to launch in weeks, not months.
• You have no budget for ongoing development after launch.
• The main reason is “we want it to look unique”. A custom theme on a platform does that for a fraction of the cost.

If most of those apply, read our guide to WooCommerce for UK shops instead and save yourself the money.

Custom vs platform: the trade-offs

The row that surprises people is the fourth. Every platform feature you take for granted, such as partial refunds, discount codes with rules, abandoned basket emails, tax on delivery or a usable order screen for staff, has to be specified, built and tested in a custom system. We see bespoke projects underestimate this more than anything else.

What a bespoke shop costs: worked numbers

We price custom work by the hour, with volume discounts. Two realistic examples using our current rates:

Level 2: WooCommerce with a custom pricing plugin

• about 150 hours of e-commerce development at £65/h = £9,750;
• volume discount for 100+ hours, 25%: −£2,437.50;
• subtotal £7,312.50, plus VAT at 20% (£1,462.50) = £8,775.

Level 4: a custom Laravel shop with ERP integration

• about 300 hours of custom web development at £60/h = £18,000;
• volume discount for 100+ hours, 25%: −£4,500;
• subtotal £13,500, plus VAT at 20% (£2,700) = £16,200.

Those hours are estimates for illustration; a real figure comes after discovery. Hours are bought through hire us, can be paid in full or with a 50% deposit, and never expire.

Five-year view

Upfront cost is half the story. Here is an illustrative comparison for a mid-sized store, excluding card fees (which are similar either way):

With these assumptions the two routes cost about the same, which is typical. Custom wins clearly when platform fees are much higher (large stores, revenue-share plans, expensive apps) or when the custom system saves staff time every week. It loses when the store is small and the process is standard. Plug your own numbers in before deciding.

How we build bespoke e-commerce

Discovery and specification

One to three workshops to map how an order really moves through your business, from enquiry to dispatch to refund. The output is a written specification with user stories, a data model and a list of integrations, plus a fixed estimate per phase. If discovery shows a platform would do the job, we say so.

Architecture

For custom shops we usually use Laravel or Node on the server, MySQL or PostgreSQL, Stripe for payments, and a React or Vue front end where the interface is complex (configurators, account dashboards). Cloudflare sits in front for caching and protection. We keep the architecture as plain as the job allows; a single well-structured application beats a set of microservices for nearly every UK retailer.

Payments, security and compliance

We use Stripe’s hosted card fields or Checkout so card data never touches your servers, which keeps your PCI DSS scope to the simplest questionnaire. Add Strong Customer Authentication handling, UK GDPR-compliant data storage and retention, a cookie banner that respects consent, and the information UK consumer law requires at checkout. See our cybersecurity services for the security testing side.

Testing and launch

Automated tests on pricing, tax and order totals (the parts where a bug costs money), manual testing across devices, test orders through Stripe’s test mode, load testing if you expect peaks such as Black Friday, then a staged launch with redirects from your old shop.

Handover

You own the code, in a Git repository under your account, plus the hosting, domain and Stripe accounts. We write documentation a different developer could pick up. That is the main protection against the risk below.

Risks to manage

• Scope creep. “While we’re at it” adds weeks. Fix the first release, keep a list for phase two and stick to it.
• Key-person dependency. If one freelancer holds all the knowledge, you are exposed. Insist on documentation, a shared repository and readable code.
• Rebuilding the free stuff. Budget explicitly for refunds, discounts, emails, reports and admin screens.
• No maintenance budget. Frameworks, PHP versions and payment APIs change. Plan for a few hours a month, every month.
• Data migration. Customers, orders and SEO history from your current shop need mapping and testing. Lost redirects cost rankings.

The middle path we recommend most often

For a lot of growing UK retailers the best answer is neither “off the shelf” nor “start from scratch”. It is a platform for the parts that are the same in every shop, and custom code for the parts that make your business different.

In practice that usually means WooCommerce handling products, orders, refunds, tax and emails, with one or two custom plugins we write for the awkward bits: a pricing calculator, a trade account system, a sync with your stock or accounting software. Because those plugins are self-contained, they can be tested properly, documented, and later moved into a fully custom system if you outgrow the platform. Nothing is wasted.

The second variant is headless: keep the platform as the back office, and build a separate front end for an experience the theme system cannot deliver, such as a 3D product configurator or an app-like account area. It costs more and needs more maintenance than a classic theme, so we only suggest it when the front end is the product. We explain the trade-offs in headless vs classic WordPress.

Whichever way you go, ask any agency quoting for the work three questions: which parts are you building that a platform already does, how will refunds and VAT be tested, and what happens if you stop working with us? A good answer to the last one names the repository, the documentation and the accounts you will own.

Before you commission a custom shop: a checklist

• Can you describe, in writing, the three things a platform cannot do for you?
• Have you priced the platform route properly, including custom plugins (level 2)?
• Do you have a five-year budget, not just a build budget?
• Who will own the code, repository and accounts?
• Is there a person on your side with time to answer questions and test?
• What is the minimum first release that would make money?

If you can answer all six, you are ready for a proper conversation. We are based in St Albans and work with retailers and organisations across the UK, in person around London and remotely everywhere else. Our custom software development and e-commerce development pages explain how we work, or get in touch with a short description of how you sell today.

Photo: Jakub Żerdzicki via Unsplash