Price per customer
Wholesale, dealer and retail buyers seeing different prices on the same product, sometimes negotiated individually.
E-commerce · Delhi NCR & remote
When your pricing is not a price.
Standard platforms assume a product has one price for everyone. A great many real businesses — wholesale, B2B, made-to-order, dealer networks — do not work that way at all.
Short answer
Custom e-commerce development is for stores whose rules a standard platform cannot express: customer-specific pricing, minimum order quantities, quotation flows, made-to-order configuration, dealer logins or tight ERP integration. The test is whether you are currently running a workaround alongside your store.
Customer-specific pricing
Rules a platform cannot express
ERP and inventory integration
You own the source
Free scoping call
Get a free quote
Four details. A real reply the same day, from me.
Fighting your platform?
Get a Free Quote
WhatsApp
01 The premise
The plugin ceiling.
Most platform limitations can be worked around once. You add a plugin for tiered pricing, another for minimum order quantities, a third for customer groups. Each works. The trouble starts when they have to work together, because none of them was written with the others in mind, and the arithmetic of a discount applied to a tier inside a group is now decided by plugin load order.
That is the ceiling. Beyond it, every new rule costs more than the last and the whole thing becomes untouchable at exactly the point where your business wants to change something. I meet a lot of stores in this state, and the tell is always the same: an offline process running alongside the store to correct what the store got wrong.
Custom e-commerce means the rules live in code you own, expressed once, testable. It costs more to build than installing plugins and far less to change afterwards. It is the right answer for a minority of stores — but for that minority it is the difference between selling online and pretending to.
02 The signals
The rules that break standard platforms.
If two or more of these describe you, custom is probably the cheaper route overall.
Minimums and multiples
Sold by the box, the metre or the pallet, with minimum order values that vary by customer or by region.
Quote instead of buy
A cart that produces a quotation for approval rather than a payment. Standard in B2B and unsupported by most platforms.
Made to order
Dimensions, materials and options that calculate a price rather than selecting a variant from a list.
ERP is the source of truth
Stock, pricing and customers live in an existing system, and the store must read from it rather than duplicate it.
API IntegrationApproval workflows
A buyer places an order, their manager approves it, and only then does it become an order. Ordinary in corporate purchasing.
03 Straight talk
Custom, or stay put?
I would rather talk you out of this than take on a project that a platform could have handled.
Build custom
- Pricing rules are a competitive advantage. If how you price is part of why customers stay, it deserves to be modelled properly.
- You run a parallel manual process. Orders corrected by hand after they arrive is the clearest signal of all.
- The plugin stack contradicts itself. Rules whose outcome depends on plugin order are a fault, not a configuration.
- An ERP already owns the data. Duplicating it into a platform creates two truths, and they will diverge.
Stay on the platform
- One price for everyone. Straightforward retail is exactly what platforms are excellent at.
- The catalogue is small and stable. Complexity is what justifies custom, not size.
- You need to launch this quarter. A custom build has a real timeline. Launch on a platform, migrate later if you must.
- Nobody will own the system. Custom software needs an owner on your side. Without one it decays.
Free scoping call
What is your store getting wrong?
Describe the pricing or ordering rule your platform cannot handle, and what you do by hand to correct it. That is usually where custom e-commerce pays for itself.
- I will tell you to stay on the platform if that is right
- Fixed price for a defined first version
- Source code and data are yours
- Same-day reply, all 7 days
Free scoping
Get a free quote
Four details, and a real reply today.
04 Process
How the risk is contained.
Custom e-commerce fails by scope, not by difficulty.
Model the rules
Every pricing, discount and eligibility rule, written down with edge cases. Most arguments happen here, where they are free.
Decide the boundary
What the store owns and what the ERP owns. Two systems believing they own stock is the single most expensive mistake available.
Build version one
The rules that matter now, at a fixed price. Everything else listed for later, deliberately.
Test with real accounts
Your actual customers, with their actual negotiated prices, before launch. Sample data hides exactly what matters here.
Migrate carefully
Customers, price lists, order history and URLs. Redirects mapped so search rankings and bookmarks survive.
— E-commerce
Related services.
These sit next to custom e-commerce and are usually bought with it. Same person doing the work in each case.
— Questions
custom e-commerce — your questions.
Straight answers, including the ones that cost me work. If yours is not here, ask it — I reply the same day.
For one or two rules, do exactly that. The ceiling appears when rules interact: a tier inside a customer group with a promotional discount and a minimum quantity. Each plugin is right on its own and the combination is decided by load order, which is not a rule you can reason about or test.
Yes, and it is common. Retail customers see standard pricing; logged-in trade customers see their own price list, credit terms and minimum quantities. The important early decision is whether trade pricing is visible before login, because that affects both SEO and your retail positioning.
Through its API where one exists, or a scheduled data exchange where it does not. The critical decision is which system owns which data — typically the ERP owns stock and pricing while the store owns web orders and customers. Ambiguity there is what causes stock errors.
It needs a developer for rule changes, whereas a platform setting can be clicked. In exchange there is no plugin update schedule, no platform version migration and no compatibility risk. For a store with genuinely complex rules, custom is usually the lower-maintenance option in practice.
Yes, with proper planning. Every product and category URL is mapped to its new address with a 301 before launch, and the old structure is crawled first so nothing is missed. Ranking loss during migration is almost always caused by skipping that step, not by the move itself.
Card data never touches your server. Payment is handled by the gateway’s hosted flow, and your site only receives a confirmation, verified server-side by webhook. That keeps you out of the heavier compliance obligations entirely, and it is how it should be built regardless.
Free consultation · No obligation
Model your rules properly, once.
Tell me the pricing or ordering rule you are currently correcting by hand. You will get an honest answer on whether custom is justified — including when it is not.
- I will recommend staying put when that is right
- Rules modelled once, testable, in code you own
- ERP boundary decided before the build
- Fixed price for a defined first version
Start here
Send your enquiry
Name, number, email, what you need.