Custom eCommerce vs Shopify Plus: When to Build, When to Stay

A custom eCommerce platform makes more sense than Shopify Plus when a business needs B2B account-level pricing that Shopify Plus cannot model, multi-vendor marketplace infrastructure, deep ERP integration, or a catalog structure that exceeds Shopify's variant and product type limits.

Shopify Plus is the right choice for a large portion of direct-to-consumer retailers. It is not the right choice for every business doing eCommerce. The distinction matters because the decision to build custom — or stay on Shopify Plus — has a 3-to-5-year revenue and operational tail attached to it.

This guide covers the exact points where Shopify Plus stops being adequate, what a custom build actually includes, what the cost comparison looks like over three years, and when staying on Shopify Plus is genuinely the better call.

Where Shopify Plus genuinely excels

Shopify Plus is the most battle-tested platform for D2C brands selling a defined product catalog to individual consumers. This is the use case it was designed around, and it executes it well.

The checkout is conversion-optimised, hosted, and maintained. The app ecosystem covers most standard marketing, inventory, and fulfillment needs without custom development. Merchants get Shopify Payments, Shopify Flow for basic automation, and the Shopify Plus merchant success program. For a D2C business under $20M annual revenue with a product catalog that fits Shopify's data model, the operational simplicity of Plus is a genuine competitive advantage.

That advantage erodes quickly once the business model moves outside the D2C standard case — specifically when it involves B2B customers, multi-vendor selling, complex catalog structures, or systems that need to talk to each other in ways the Shopify API cannot support.

What are the five signs your business has outgrown Shopify Plus?

Each of these is a structural ceiling in the Shopify data model — not a missing app, not a configuration issue. When a business hits one of these, workarounds exist but they accumulate technical debt and limit growth.

• B2B account-level pricing — Shopify Plus added B2B features in 2022–2023, but they are built around company-level price lists. If a business needs contract-specific pricing per SKU per account, tiered volume discounts that vary by customer segment and product line, or pricing that changes based on purchase history, Shopify's B2B model cannot represent it. Workarounds require custom apps that recreate pricing logic outside Shopify's checkout — which means maintaining two separate pricing systems.
• Multi-vendor marketplace requirements — Shopify is a single-merchant platform. It has no native concept of vendor accounts, vendor-specific fulfillment routing, split payouts, or vendor dashboards. Marketplaces built on Shopify require third-party multi-vendor apps (Webkul, Shipturtle) that bolt on these concepts after the fact. At meaningful transaction volume, these apps become performance and reliability constraints.
• ERP integration depth — Shopify connects to ERP systems via its API. That connection is fine for syncing inventory counts and pushing orders. It is not adequate when real-time cost of goods data needs to flow from ERP into product pricing, when order allocation logic depends on warehouse-level stock rules held in ERP, or when the ERP's product data model is the master record and Shopify must reflect it exactly. These integration patterns require custom middleware that ends up doing work Shopify's data model cannot represent natively.
• Catalog complexity beyond Shopify's variant model — Shopify supports 100 variants per product (as of 2024 API changes, 2,000 in some configurations). This is sufficient for apparel and straightforward consumer products. It fails for industrial products with configurable specifications, custom-built or made-to-order items, products where options nest more than two levels deep, or catalogs where the same item appears under multiple product hierarchies with different pricing logic.
• Custom checkout logic that cannot live in Shopify Functions — Shopify Functions allow some customisation of discounts, shipping, and payment methods. They do not allow arbitrary business logic in the checkout — credit line checks against a customer account system, compliance-gated purchasing flows, quote-to-order conversion with approval steps, or split billing across purchase orders. If the checkout needs to behave like a business system rather than a shopping cart, Shopify's checkout extensibility has a hard ceiling.

What does a custom eCommerce platform include that Shopify cannot?

A custom eCommerce build is a software project, not a platform configuration. The result is a system built around the business's actual data model, not a commercially viable approximation of it.

The key differences in practice:

• Pricing engine — A custom platform holds pricing logic in a dedicated service layer. Price for a given account, SKU, and quantity combination is computed at request time by a rule engine that can be as complex as the business needs — contract tiers, volume discounts, promotional stacks, customer-group overrides, cost-plus rules, or real-time margin calculations from live COGS data.
• Product data model — The catalog schema is designed to match the business's product structure, not Shopify's. That means unlimited attribute depth, configurable product types, product relationships (accessories, replacements, configurations), and a hierarchy that mirrors how the business actually thinks about its range.
• Checkout as a business process — Order placement becomes a workflow step rather than a payment transaction. That means quote flows, approval chains, purchase order reference capture, credit line validation, delivery scheduling rules, and split shipment logic can all be built into the purchase path.
• ERP as the master record — Instead of Shopify pulling data from ERP, the custom platform treats ERP as authoritative. Inventory, pricing, and product status flow from ERP into the commerce layer in real time. Orders flow back. There is no sync lag, no mapping translation problem, and no third-party middleware sitting between the two systems and adding failure points.
• Multi-vendor architecture — Vendor accounts, product ownership, fulfillment routing by vendor, payout splitting, vendor dashboards with order management and performance reporting — all first-class concepts in the data model, not afterthoughts bolted on via an app. For businesses that need full custom marketplace development, this is where Shopify's architecture breaks down most visibly.

The 40%+ sales increase: what changed in the rebuild

A market-leading retailer Madgeek worked with had been running on a modified platform that could no longer support their catalog growth or B2B buyer workflows. The rebuild produced a 40%+ increase in sales within the first operating year.

Three structural changes drove that number:

1. The catalog was rebuilt around how buyers search and configure, not how the legacy system stored products. Buyers found what they needed in fewer steps. Fewer abandoned sessions.
2. B2B account pricing was moved into the platform. Business buyers saw their negotiated prices on first login, without needing to call or request a quote for standard orders. That removed friction from the re-order process — the highest-frequency purchase type.
3. The ERP integration gave real-time stock visibility per warehouse. Buyers stopped abandoning orders due to stock uncertainty — they could see actual availability at the point of purchase decision.

None of these were Shopify Plus features. All three required a custom data model and integration architecture. The platform cost was returned inside the first year.

How does the cost compare: Shopify Plus fees vs a custom build over 3 years?

The cost comparison is closer than most merchants expect — because Shopify Plus at scale is not cheap, and the ceiling costs are often hidden in the apps, transaction fees, and integration middleware required to approximate what a custom platform does natively.

Shopify Plus real-world cost stack

• Platform license — $2,300/month base (2026 pricing), up to $40,000+/month for very high GMV tiers on revenue-based plans
• Third-party apps — Enterprise merchants regularly run $2,000–$8,000/month in app subscriptions covering loyalty, subscriptions, B2B features, product configurators, ERP connectors, and search
• Transaction fees — 0.15% to 0.25% of GMV if not using Shopify Payments (common for B2B merchants using existing payment infrastructure)
• ERP integration middleware — $500–$3,000/month for platforms like Celigo, Boomi, or custom sync services
• Agency development for customisation — Most Plus merchants at this scale are spending $50,000–$200,000/year on ongoing Shopify development to work around the platform's limits

A merchant at $30M GMV on Shopify Plus, with a typical app stack and ERP integration, is spending $120,000–$250,000 per year in direct platform costs before any development work. Over three years, that is $360,000–$750,000.

Custom build cost structure

• Initial build — $80,000–$200,000 for a full custom eCommerce platform with ERP integration, depending on catalog complexity, order workflow logic, and B2B requirements
• Infrastructure — $1,000–$5,000/month for hosting, CDN, monitoring, and scaling (cloud costs scale with traffic, not with GMV)
• Ongoing development — $30,000–$80,000/year for feature additions, integrations, and performance improvements (controlled by the business, not dictated by platform release cycles)
• No transaction fees — At $30M GMV, removing Shopify's 0.15% transaction fee saves $45,000/year alone

Three-year total cost of ownership for a custom platform at the same scale: $200,000–$400,000 — including the initial build. At $30M+ GMV, the custom platform often costs less in year two and three than Shopify Plus costs to run. The crossover point depends on GMV, app complexity, and how much workaround development is required on Shopify.

When should you stay on Shopify Plus?

Shopify Plus remains the right choice when the business model fits the platform. Not every merchant who complains about Shopify limits actually needs a custom build.

Stay on Shopify Plus when:

• D2C model, defined product catalog, no B2B pricing complexity — This is Shopify's core case. The platform is optimised for it. A custom build would cost more and deliver the same checkout conversion rates.
• Under $5M annual revenue — The capital required for a custom build is better deployed into growth at this stage. Shopify Plus constraints at under $5M are almost always solvable with apps.
• The team has no internal capability to own a custom codebase — A custom platform requires ongoing engineering ownership. A business with no technical team and no plans to build one will be more exposed on a custom platform than on Shopify Plus, even if the platform is technically superior.
• Speed to market is the primary constraint — A Shopify Plus store can launch in weeks. A custom build takes 4–9 months. If a business is racing to market and the catalog fits Shopify's model, Shopify Plus and a migration plan later is the more rational sequence.
• The friction points are in marketing and conversion, not the platform — Some merchants assume a custom platform will solve revenue problems that are actually caused by poor SEO, weak product pages, or high acquisition costs. A custom build does not fix those. Diagnosis before architecture.

What does the decision process actually look like?

The decision reduces to three questions, answered in order:

1. Does the business model fit Shopify's data model? If yes, stay. If no, continue.
2. Is the cost of the workaround (apps, custom development, middleware) already exceeding the cost of a build? If not yet, set a threshold and revisit in 12 months. If yes, continue.
3. Is there a specific capability the business cannot build on Shopify that represents a material revenue or operational constraint? If yes, the case for a custom build is real. Proceed to scoping.

Most merchants who reach the third question already know the answer. They have been living with the constraint for 12–18 months and can name the revenue it has cost them. The decision at that point is execution, not analysis.

What technology stack does a custom eCommerce build typically use in 2026?

The stack choice depends on the business's existing infrastructure, team capability, and integration requirements. These are the patterns used for production custom eCommerce platforms in 2026:

• Frontend — Next.js with server-side rendering for SEO performance, React for the buyer-facing catalog and checkout UI
• Commerce API layer — Node.js or Python services handling catalog, pricing, cart, and order logic — built around the actual data model, not a generic platform's abstractions
• Database — PostgreSQL as the primary store for transactional data; Elasticsearch or Typesense for catalog search with faceted filtering at scale
• ERP integration — Event-driven sync via message queue (typically RabbitMQ or AWS SQS) for stock and pricing updates; synchronous API calls for order placement
• Payments — Stripe for card payments; existing payment provider APIs for B2B invoice and purchase order flows where card is not the payment method

The stack is chosen for the project, not imposed. For a business running SAP, the integration architecture looks different than for a business running a mid-market ERP on AWS. The right stack is the one that fits the existing infrastructure and the team that will own it.

What does a custom eCommerce build engagement actually involve?

The projects that go wrong in custom eCommerce almost always fail at the same point: the data model was not properly designed before development started. Catalog structure, pricing rules, and ERP integration contracts need to be defined and agreed before a line of application code is written.

A well-run custom eCommerce engagement runs in four phases:

1. Discovery and data modeling (3–5 weeks) — Catalog structure, pricing rules, ERP data contracts, order workflow logic, user roles and account hierarchy. This produces a specification that the build is held accountable to.
2. Core platform build (10–16 weeks) — Catalog and product management, pricing engine, buyer authentication and account management, cart and order flow, payment integration, admin tooling.
3. ERP integration and data migration (4–8 weeks, overlapping with build) — Integration layer built, tested against ERP staging, data migration scripts validated, parallel running period with the existing system.
4. Performance testing, cutover, and stabilisation (3–4 weeks) — Load testing against peak traffic projections, cutover plan with rollback defined, monitoring dashboards active, first 30 days of live operation with engineering available for rapid response.

The total timeline for a full custom eCommerce build with ERP integration is typically 5–7 months from brief to production cutover. Simpler builds without complex B2B workflows can reach launch in 4 months.

Madgeek's custom eCommerce development service page covers the engagement model, what a scoped proposal covers, and how to start a conversation about whether a custom build is the right call for a specific situation.