Custom Ecommerce vs Shopify: When Does Custom Actually Make Sense?

When a business starts thinking seriously about ecommerce, one question comes up quickly:

Should we use Shopify, or should we build something custom?

I think that is often the wrong first question.

The technology decision should come later.

A better place to start is:

How does this business actually sell?

What does the customer need to understand or configure before buying? How does pricing work? What does inventory mean for this business? What happens between checkout and fulfilment? Which parts of that process are strategically important?

Once those questions are clear, the platform decision becomes much easier.

Custom ecommerce starts to make sense when business-critical product, operational, integration or transaction requirements are valuable enough that a standard platform materially constrains them—and when the business can justify the additional ownership cost.

When Shopify is probably the smarter choice

Custom development is not automatically more sophisticated.

For a business selling a relatively standard catalogue through a conventional product → cart → checkout journey, an established ecommerce platform can solve an enormous amount of difficult infrastructure.

That can include:

• product management;
• checkout;
• payments;
• themes;
• hosting;
• integrations;
• apps;
• administration;
• operational tooling.

That means the business can get to market faster and take on less engineering responsibility.

If the platform already handles the important business requirements well, rebuilding those capabilities from scratch may create cost without creating meaningful advantage.

Paying engineers to rebuild solved infrastructure is not automatically a competitive advantage.

Where the decision begins to change

The case for custom ecommerce becomes stronger when the limitations of the platform begin becoming limitations on the business.

That often happens when complexity starts appearing in the product model, operations, integrations or transaction logic.

Imagine a product model that is no longer simply:

Product → Size → Colour → Add to cart

Instead, it might involve:

Base product → configurable components → compatibility rules → bundles → conditional pricing → shared inventory

At that point, the commerce system is beginning to encode part of how the business itself works.

A catalogue is more than a collection of product cards

One of the things I explored while building Project Carry was the idea of catalogue authority.

A serious commerce system has to answer questions such as:

• What exactly can be sold?
• Which configurations are valid?
• What is the authoritative price?
• Which inventory does a bundle consume?
• What happens if one component becomes unavailable?
• Can two different offers depend on the same physical stock?

Those questions are not primarily design questions.

They are business-rule questions.

And once the product model becomes important enough, the architecture underneath the storefront begins to matter much more.

Sometimes the storefront is the easy part

A customer may see:

Product → Cart → Checkout

But the business may have to coordinate:

• inventory;
• warehousing;
• shipping;
• taxes;
• reservations;
• customer accounts;
• staff permissions;
• fulfilment;
• finance;
• supplier systems;
• reporting;
• external providers.

So the real question becomes:

Can the commerce system accurately represent how this business actually operates?

If standard integrations can do that well, use them.

If the business repeatedly has to distort its processes to fit the platform, the economics of custom software begin to change.

Transaction authority matters too

Checkout is easy to describe as:

Customer pays → order succeeds

Real transaction systems are less tidy.

A commerce system may need to answer:

• What price was authoritative when checkout started?
• Was inventory reserved?
• What if the customer submits the same action twice?
• What if payment succeeds but the browser closes?
• What happens when a provider responds late?
• What if two customers compete for the same inventory?
• What happens if the internal system and payment provider temporarily disagree?

This is where concepts such as idempotency, reservations, retries, concurrency and reconciliation become important.

But the business consequence is what matters.

The goal is to prevent things like duplicated transaction intent, incorrect stock, inconsistent payment state or failures that cannot be recovered cleanly.

Custom has a cost too

Greater control creates greater responsibility.

When you own more of the commerce system, someone also has to own:

• engineering;
• maintenance;
• testing;
• security;
• infrastructure;
• monitoring;
• provider integrations;
• upgrades;
• bugs;
• reliability.

So “we want more control” is not enough.

Control is valuable when the value of that control exceeds the cost of owning it.

That is the threshold that matters.

It does not have to be Shopify versus building everything

There is a large middle ground.

A business might use:

Established commerce platform + custom frontend

or:

Platform + custom internal systems

or:

Platform + custom integrations

or:

Hosted payments + custom catalogue/configuration layer

or:

Custom commerce application + specialized external providers

The business does not need to own every layer simply because one layer requires customization.

Architecture should follow what the company actually needs to control.

A practical decision framework

This is not a scoring calculator.

It is a way of identifying where the important complexity actually lives.

What building Project Carry taught me

Project Carry is a concept/engineering ecommerce system I built to explore some of these boundaries.

Instead of treating ecommerce as a set of storefront screens, I approached it as a system that needed consistent authority across:

• catalogue;
• configurable products;
• bundles;
• inventory;
• authenticated cart;
• checkout;
• shipping;
• tax;
• reservations;
• payment boundaries;
• retries;
• reconciliation.

It is not an operating retailer and does not provide evidence of real customers, orders or sales.

Its value is different.

It gave me a practical environment for exploring the engineering decisions underneath a more demanding commerce model.

Read the Project Carry case study →

Custom should earn its place

Shopify is not the beginner option, and custom development is not automatically the sophisticated option.

The better decision is the one that fits the business.

If an established platform already handles the important requirements well, use it and spend the company's resources somewhere more valuable.

But when product rules, operations, integrations or transaction logic become strategically important—and the platform increasingly forces the business to work around it—custom development can start earning the additional investment and responsibility it requires.

Technology should adapt to the business only where doing so creates enough value to justify owning the complexity.