When Does Custom E-commerce Make Sense?

We build custom software for a living, so take this in the spirit it’s offered: most businesses should not build custom e-commerce. Hosted platforms solve checkout, payments, tax, fraud and compliance — problems that are genuinely hard, genuinely boring, and already solved.

The interesting question is when that stops being true.

The three options, honestly

Hosted platform. You use the platform’s storefront and admin. Fast, cheap, well-supported. You accept its opinions about how commerce works.

Headless. You keep the platform’s commerce engine — catalogue, cart, checkout, payments — and build your own front end against its API. You get design and performance freedom without rebuilding the hard parts.

Custom. You build the commerce logic yourself. Rare, expensive, and occasionally the only honest answer.

Most businesses that think they need custom actually need headless. That distinction alone saves a lot of money.

Signals you’ve outgrown a hosted platform

Any one of these on its own isn’t decisive. Three or more usually is.

• Your pricing can’t be expressed. Customer-specific pricing, contract rates, volume tiers per account, or rules that depend on the customer’s order history.
• You’re paying for apps to patch the model. Eleven plugins, each solving one gap, each an upgrade risk, collectively costing more than the platform.
• Your catalogue doesn’t fit. Configurable products with real dependencies, made-to-order items, rentals, subscriptions with unusual billing, or products that are really services.
• Performance is capped. You’ve done the obvious work and the theme’s architecture is the limit.
• The workarounds have become the process. Staff are trained on "the thing we do because the system won’t let us do it properly."
• Integration is fighting you. Your ERP is the source of truth but the platform insists on being one too, and reconciliation is somebody’s weekly job.

Signals you should stay put

• Your catalogue is conventional and your pricing is one number per product.
• Your growth constraint is traffic or margin, not the software.
• You have no in-house technical capacity and no budget for ongoing maintenance.
• The complaint is "it looks generic" — that’s a design problem, and headless solves it far more cheaply than custom.

The middle path most people should take

Headless gives you:

• a front end you fully control, so performance and design are yours to fix;
• the platform’s checkout, payments, tax and fraud handling — the parts you really don’t want to own;
• freedom to structure content and category pages for SEO rather than around theme constraints;
• an integration layer you write, rather than an app you hope keeps working.

The trade-off is real: you now own a codebase, and you need someone to maintain it. That’s a genuine ongoing cost, not a one-off.

What custom actually costs you

Beyond money:

• Compliance. PSD2/SCA, tax rules across markets, accessibility, consumer rights. The platform was quietly handling these.
• Fraud and chargebacks. Someone else’s machine learning was working for you.
• Edge cases. Partial refunds, split shipments, currency rounding, failed payments retried at 3am. Every one is a decision you now make.
• Ongoing engineering. Not "a project", a commitment.

If those don’t have owners, the honest answer is that you’re not ready for custom — and that’s a completely reasonable place to be.

A simple test

Write down the three things about how you sell that your current platform makes hardest. For each one, ask: is this a genuine competitive advantage, or is it a habit?

If they’re habits, change the habits. If they’re genuinely how you win — the reason customers choose you over an easier competitor — then software that supports them is worth building.

That’s the same test we apply to custom software generally. If you want a second opinion on which side of it you’re on, describe your setup and we’ll tell you honestly — including when the answer is "stay where you are".