Custom Ecommerce vs Shopify: When Building Is Worth It

Checkout, primarily. Shopify's checkout has been optimised against a volume of real transactions no individual store will ever generate, and rebuilding it is one of the more reliable ways to lose revenue without noticing you are losing it. Conversion differences of a few percent do not announce themselves. They just quietly happen.

Beyond checkout there is PCI compliance handled on your behalf, fraud analysis included, tax calculation across jurisdictions maintained by somebody else, payment integrations that keep working when providers change their APIs, and an application ecosystem where most things you will want already exist.

The trade is uniformity. Your store works the way Shopify believes stores work. For the overwhelming majority of retail this is not a constraint but a decade of accumulated good decisions you receive at no cost.

The expenses that matter are the subscription, transaction fees if you do not use their payment processing, and application subscriptions, which stack more quickly than anyone expects. A store running eight applications is unremarkable and is not cheap, and this is the number that eventually drives the custom conversation.

WooCommerce is the right answer more often than the discourse suggests, particularly where content and commerce are equally important.

If a meaningful part of the business is publishing, whether recipes, guides, reviews, or a community, WordPress is a better content platform than Shopify and WooCommerce lets the store live inside it rather than beside it. You own the data, you own the hosting, there are no transaction fees, and customisation means writing PHP rather than working around a platform's assumptions.

The cost is that you now own a WordPress installation. Updates, plugin conflicts, security patching, backups, and performance tuning are somebody's job. This is where the comparison becomes less about features and more about organisational capacity, because a neglected WooCommerce store is a genuine liability in a way a neglected Shopify store is not. Shopify cannot be compromised through an outdated plugin you forgot about.

Choose it when content and commerce carry equal weight, or when you have the technical capacity and object to platform fees on principle. Avoid it when nobody has been named as the person who maintains it.

Wanting it to look different is not one of them. Looking different is a theme. These are the situations where a platform is the wrong shape rather than the wrong style.

The business logic is the product

Configurable products with real dependency rules between options. Quoting that depends on customer, volume, and contract terms. Subscription models nobody has built before. Marketplace mechanics with multi-party payouts. Business-to-business ordering with approval chains and account-specific catalogues.

If the thing that makes the business work is the logic sitting between browsing and paying, a platform will resist you at every step, and the usual outcome is a stack of applications and workarounds that costs more than a build and performs worse. The workaround stack is also harder to reason about than a codebase, because it is distributed across vendors nobody controls.

Platform fees have reached the cost of a salary

This is arithmetic rather than philosophy. Subscription plus transaction fees plus application subscriptions, multiplied by twelve. Once that figure exceeds what a build plus its maintenance would cost, and volume is stable enough to trust the projection, custom starts to make sense.

For most stores that crossover never arrives. For a high-volume store operating on thin margins it can arrive quickly, and the margin structure is what determines it rather than the revenue.

An integration exists that nothing supports

A legacy enterprise resource planning system, a specialised warehouse management platform, an industry compliance requirement, or unusual tax treatment. Occasionally there is no application and no plausible workaround, and the integration is not optional to the operation of the business.

And the option people rarely ask about

Headless commerce is frequently the correct answer and almost never the thing people arrive asking for. Keep Shopify as the commerce engine, meaning checkout, inventory, payments, and compliance, and build a custom frontend against its API.

You get the experience you want while keeping the parts that are genuinely hard and genuinely regulated. It costs less than a full custom build and removes most of the ceiling. If you are considering custom because the storefront feels constraining rather than because the logic does, this is almost certainly your answer, and it is worth naming explicitly because the conversation is usually framed as a binary that it is not.

A build is a defined scope with an end date. What follows it has neither.

Payment providers change their APIs. Tax rules change, sometimes with a few weeks of notice. Security patches need applying. Browsers change and something breaks on iOS for reasons nobody anticipated. Fraud patterns evolve and your defences do not evolve with them unless somebody is paid to evolve them. Every one of those is Shopify's problem today and becomes yours permanently the moment you build.

The honest budget is somewhere between ten and twenty percent of the build cost annually, ongoing, with no end date. If that number causes the project to stop making sense, that is useful information now rather than in year two.

We tell clients this before quoting, because a custom store nobody maintains becomes a liability faster than almost any other category of software. It is also the number most agencies leave out of the pitch, which is why so many custom stores are quietly abandoned eighteen months after launch.