When your commerce model doesn't fit a platform
Custom e-commerce builds for business models that standard platforms don't accommodate cleanly.
What is Custom E-commerce?
Custom e-commerce is building a store's commerce logic - pricing, checkout, inventory, and often the storefront itself - outside the constraints of a platform like Shopify or Magento, usually on a headless architecture where the frontend is decoupled from the commerce backend. It's the right approach specifically when a business model doesn't map onto standard platform assumptions: subscription billing with usage-based components, marketplace dynamics with multiple sellers, or pricing logic that varies by customer, contract, or negotiated terms.
Custom e-commerce is a commerce build made outside a standard platform's constraints, usually headless, for business models - subscriptions, marketplaces, custom pricing - that a platform like Shopify or Magento can't cleanly support.
Why this matters for the business
Forcing a non-standard commerce model onto a standard platform usually means a growing pile of workarounds - a subscription add-on stacked on a platform that wasn't built for recurring billing, or a marketplace bolted together from apps never designed to talk to each other. Each workaround is a maintenance liability, and the combined fragility tends to surface at the worst time, like a high-traffic sales period.
Custom builds cost more upfront than a platform subscription, which is exactly why the decision matters - it's only the right call when the commerce model genuinely doesn't fit, not because custom feels more sophisticated. Judged honestly, most catalogues don't need it.
Storefront (web / app / kiosk) <-> Commerce API <-> [ Pricing Engine | Inventory | Payments | Order Management ]
What makes this hard to get right
- Custom builds take longer to launch than a platform-based store, since there is no template to start from
- Ongoing maintenance is the business's responsibility (or its agency's), not absorbed by a platform vendor
- Every integration - payments, inventory, shipping - has to be built and tested individually rather than installed as an app
How we approach Custom E-commerce
Commerce Model Assessment
- Honest evaluation of whether a standard platform could actually work
- Identifying which specific business rules genuinely require a custom build
Architecture & Platform Selection
- Headless versus fully custom stack decisions
- API and commerce engine selection based on the business model
Custom Pricing & Subscription Logic
- Usage-based, tiered, or negotiated pricing implementation
- Recurring billing and subscription lifecycle management
Marketplace & Multi-Seller Architecture
- Seller onboarding and catalogue management
- Commission, payout, and multi-party payment logic
Payment & Inventory Integration
- Payment gateway integration built for the specific pricing model
- Inventory sync across warehouses, sellers, or fulfilment partners
Scalability & Infrastructure Planning
- Infrastructure sized for realistic growth, not worst-case guesswork
- Monitoring and capacity planning built in from launch
Scope, area by area
| Area | What we deliver |
|---|---|
| Architecture | A documented commerce architecture matched to the actual business model |
| Pricing & Billing | Custom pricing and subscription logic built and tested against real scenarios |
| Integrations | Payment, inventory, and fulfilment integrations built for the specific model |
| Storefront | A headless or custom frontend connected to the commerce backend |
How it actually runs
Model & Fit Assessment
We first confirm the commerce model genuinely can't be served by a standard platform, since that's the more cost-effective outcome when it's true.
Architecture Design
The commerce architecture - headless or fully custom - is designed around the specific pricing, inventory, and checkout logic the model needs.
Core Build
Pricing engine, checkout, and inventory logic are built and tested against real scenarios, not just happy-path cases.
Integration
Payment gateways, fulfilment systems, and any third-party services are integrated and tested individually.
Launch & Scaling Plan
Infrastructure is sized for realistic growth, with monitoring in place from day one rather than added after a problem.
How this compares
| Custom / Headless Build | Standard Platform |
|---|---|
| Commerce logic matches the business model exactly | Business model adapted to fit platform constraints |
| Higher upfront build cost and longer timeline | Faster launch, lower upfront cost |
| Full ownership of maintenance and updates | Platform vendor handles core maintenance |
| No platform-imposed ceiling on customisation | Customisation bounded by what the platform allows |
This is a genuine trade-off, not a strict upgrade - custom is the right call when the model doesn't fit a platform, not a default best option.
What we measure this against
- Whether the commerce model's actual business rules are supported without workarounds
- System uptime and integration reliability under real transaction volume
- Total cost of ownership versus the workaround cost of forcing the model onto a standard platform
Who needs this
Subscription or usage-based businesses
Where billing logic is more complex than fixed recurring charges - metered usage, tiered plans, or mid-cycle changes.
Marketplace operators
Multi-seller catalogues, commission logic, and split payments rarely fit cleanly into a single-seller platform.
Businesses with negotiated or contract-based pricing
B2B sellers where price genuinely varies by customer or contract, not just by published tier.
Where this applies
- A subscription box business needs billing logic that handles skips, swaps, and mid-cycle plan changes
- A marketplace connects multiple independent sellers under one storefront with split payouts
- A B2B distributor needs checkout pricing that reflects individually negotiated contracts, not a public price list
The most common mistake in this space isn't choosing the wrong technology - it's skipping the honest assessment of whether the business model actually requires a custom build at all. A surprising number of 'custom' requirements turn out to be a standard platform's default behaviour that nobody had configured correctly.
Other services in this area
Fast to launch, built to actually convert
Shopify store development and theme customisation built around conversion, not just launch speed.
Enterprise catalogue complexity, handled properly
Magento development and management for larger, more complex product catalogues.
More revenue from the traffic already showing up
E-commerce conversion optimisation across product pages, cart, and checkout.
Common questions
If your pricing, billing, or seller structure requires workarounds and app stacking on a standard platform, that's the signal. If a platform can handle it with configuration alone, custom is usually not worth the added cost and timeline.
Meaningfully longer than a platform-based store - typically three to six months depending on the complexity of the pricing, integration, and storefront requirements, since there is no template to start from.
Related but not identical. Headless means the frontend is decoupled from the commerce backend, which is common in custom builds, but you can also run headless on top of a platform's commerce engine without building the backend from scratch.
We do, under an ongoing arrangement, or your internal team can take it over with full documentation - either is workable, but it needs to be planned for upfront since a custom build has no vendor safety net.
Often less expensive over several years for a genuinely non-standard business model, because the alternative is compounding workaround costs on a platform that was never built for it. For a standard catalogue, a platform is almost always cheaper - custom is not a default recommendation.
We can't guarantee zero future changes - no build can promise that against unknown future requirements. What we can do is size the architecture for realistic growth and avoid the kind of platform lock-in that would force a full rebuild rather than an extension.
Not sure if your commerce model actually needs a custom build?
We'll give you an honest assessment - including telling you when a standard platform would genuinely serve you better.
Talk to us →