In this guide 6 sections
Go custom only when rules fail. Negotiated dealer pricing, multi-warehouse allocation, order approvals and ERP integration are the usual triggers, because platform settings and extensions cannot express them without workarounds that keep breaking. High traffic or a distinctive look are rarely good reasons, since better caching, stronger hosting and a well-built theme on a standard platform already cover both needs.
Where off-the-shelf platforms start to strain
Some patterns keep recurring. Pricing may follow a negotiated agreement rather than a discount code, and an order above a set value may need sign-off before it is confirmed.
Stock may need allocating across several warehouses or legal entities, which a standard platform built around a single stockroom does not model at all. Catalogue structures such as kits, configurable products and batch or lot tracking may not map onto the generic product record that most retail platforms use.
None of this is exotic. A retail-first platform, built around one price per product and one warehouse, was never designed for it, so the useful question is whether these frictions apply to you.
Try configuration and extensions first
Try the platform first. Shopify and WooCommerce both offer mature apps for tiered wholesale pricing, quantity-break discounts and customer-specific catalogues, and those cover a genuine share of what looks like a custom requirement.
Run a simple exercise. List each requirement that seems to need custom work and name two or three apps or settings that could plausibly solve it before any code is written. Then write down, in one sentence each, exactly why every candidate falls short for your particular catalogue, customers and warehouse setup, and keep the notes somewhere visible.
That list becomes your justification, if one is still needed, and it is the cheapest protection against rebuilding something that a monthly subscription app already handled.
Weigh scale, operational complexity and ownership
Order volume alone rarely decides this. Modern platforms and even a well-hosted WooCommerce store handle large transaction volumes without trouble, so the real test is the complexity of the rules running on each order. Count the connected systems too.
Ownership is the other question. Some businesses want their own codebase, with no monthly platform fee, no forced upgrade path and full control of the intellectual property, and they accept heavier maintenance in return.
Take an electrical-fittings distributor with around 200 dealers. Each dealer has a negotiated price list and a credit limit that must be checked before an order is accepted, and larger orders wait for a manager’s approval. Pricing, a credit check and an approval workflow together are the layered logic that pushes a business from configuring a platform toward building something.
A middle path before building from scratch
Full rebuilds are not the only option. Keep the existing platform for catalogue browsing, checkout and payment handling, and build a custom layer only for the piece that is genuinely different. A headless storefront is another variant. That piece might be a dealer portal, a quoting engine or a warehouse allocation and replenishment service, connected to the platform through its API and tested against real orders.
This limits how much code the business must maintain while still closing the exact gap that pointed toward custom work in the first place. It is usually cheaper and quicker to ship than a ground-up rebuild, and the retail-facing pages stay on infrastructure that someone else patches and monitors.
- Dealer portal with customer-specific price lists
- Quoting engine for orders needing sign-off
- Warehouse allocation and replenishment behind the checkout
- Idempotent order and stock sync with the ERP
Validate the riskiest customer journey first
Walk the riskiest journey first. It is usually a big credit order. Use a clickable prototype and not only a specification document, because the flow forces decisions that a written specification lets you skip without anyone noticing.
Two questions show the point. Ask what happens if a dealer’s credit runs out mid-order, if two reps approve the same order within a minute, and if a backordered line ships separately.
Then build its smallest working slice. Dealers should use it before scope widens. A custom build that proves itself on one workflow is a far safer investment than one that tries to launch everything at once and stumbles in front of customers.
Custom-commerce readiness checklist
The checklist covers pricing complexity, integration depth, workflow uniqueness, ownership priorities and written evidence that configuration or an extension was tried and fell short. A business with several ticks, each backed by a real attempted workaround and a dated note, is a genuine custom candidate worth scoping properly. Assumptions alone do not.
Open a blank worksheet to printQuestions owners ask
Can we retain an existing storefront?
Often, yes. In the hybrid pattern described above, custom logic connects behind or beside the existing storefront and does not replace the checkout and product pages that customers already know. That lowers both cost and risk.
Does high traffic alone justify custom development?
No. Established SaaS platforms and a properly hosted WooCommerce store both carry heavy traffic without custom code, because load is solved with hosting and caching. High traffic is a reason to invest in a content delivery network and better hosting, not a reason to build a custom application.
What should we build first if custom is justified?
Start with one dealer order. Test it with a few real dealers, fix what they trip over, and only then widen the scope to quoting, allocation or reporting.