Is a custom build cheaper than Shopify in the long run?

Usually not, and anybody who tells you otherwise is counting only the subscription. Shopify includes hosting, PCI scope, fraud screening, uptime and a team maintaining the checkout. A custom build moves all of that onto your budget. It wins when it removes work rather than when it removes a monthly fee.

Can we keep Shopify checkout and build everything else ourselves?

Often yes, and it is frequently the right shape. Shopify keeps the checkout and the payment compliance, your application owns pricing, entitlements and whatever makes your business unusual. The part to design carefully is which system is the source of truth for an order once it exists.

What about Shopify Plus?

Plus buys you checkout extensibility, higher API limits and B2B features that remove some of the reasons people leave. It is worth pricing against a custom build before starting one, because for a meaningful share of the cases we are asked about, Plus is the cheaper answer.

How do we migrate without losing search traffic?

By treating the URL map as the first deliverable rather than the last. Collection and product URLs, the pagination and filter parameters, and a redirect for every URL that has ever ranked. A replatform that discovers its redirects in the final week has already lost the thing it was trying to protect.

Shopify vs Laravel: Where the Order Model Breaks

Shopify is a product you rent, and it is the right answer for most stores. The boundary is not catalogue size or traffic. It is the moment your order stops being a simple order.

Published September 22, 20264 min read

Most comparison pages on this subject are written by agencies that build custom stores. So, plainly: for most of the businesses that search this, the answer is that Shopify is correct and you should not be reading further.

Shopify is not a framework with limitations. It is a product you rent, and the rent includes hosting, PCI scope, fraud screening, uptime, and a team whose entire job is keeping a checkout working on Black Friday. Rebuilding that to own it is a decision that needs a better reason than wanting to own it.

What Shopify actually costs

Before deciding it is expensive, add it up properly, because almost nobody does.

The subscription is the small number. The real figure is the transaction percentage on every order, plus the apps. A store of any age is usually carrying eight to fifteen of them: subscriptions, bundles, reviews, a wishlist, a feed manager, a page builder, two that nobody remembers installing. Each is a monthly fee and each injects script into your storefront.

Write that total down. Sometimes it is genuinely large and the case makes itself. Often it is smaller than the maintenance cost of the thing that would replace it, and knowing that before starting is worth the hour it takes.

The boundary is the order, not the catalogue

Catalogue size is the wrong metric. Shopify handles large catalogues comfortably, and we have seen small catalogues that needed to leave.

The line is the order. If your order is these items, this address, this payment, Shopify models it natively and everything works. It stops fitting when an order carries business rules that Shopify has no concept of:

Pricing that depends on who is buying, in contract terms rather than discount codes.
A fulfilment process with states - approval, partial dispatch, back-order, return-to-supplier - that has to be queryable and reportable.
Subscriptions with proration, mid-cycle changes and a billing record that still reconciles a year later.
Stock that lives in an ERP which has strong opinions and is not going to change them.
Quotes, approvals, credit limits. The entire B2B shape.

Each of those can be approximated with apps and metafields. The question is how many approximations the business is running at once, and whether anybody can still say where a rule lives - which is the same question that decides it on any platform.

What a custom build has to earn

A custom store starts behind. It has no checkout, no fraud screening, no app ecosystem, and no team on call. To be worth it, it has to remove more work than it creates.

The cases where it does are specific. A business where the order process itself is the product. An operation where staff hours go into working around the platform every day. A company whose stock and pricing live in a system that Shopify can only talk to through a nightly CSV. Those are real, they are common enough that we build them, and they are not most stores.

The shape that keeps Shopify

The decision is rarely all or nothing, and the middle option is underrated.

Shopify keeps the checkout, the payment compliance and the part of the flow where mistakes are expensive and regulated. Your Laravel application owns the pricing engine, the entitlements, the fulfilment states, the B2B account structure - whatever makes your business unusual - and talks to Shopify through its API.

The part to design deliberately is which system is the source of truth for an order once it exists, and what happens when the two disagree. That is reconciliation, and it is the work we spend the most time on in any integration.

If you do move

Treat the URL map as the first deliverable. Collection and product URLs, the filter and pagination parameters, a redirect for every URL that has ever ranked. A replatform that discovers its redirects in the final week has already given away the traffic it was trying to protect.

And build the order model before the storefront. The storefront is the part everyone wants to look at and the part that is cheapest to change later. The order is neither.

If the cart is self-hosted rather than rented, none of the ownership argument above applies and the question is a different one. OpenCart is the version of it we are asked about most.