E-commerce Development
E-commerce development covers catalogue, checkout, feeds and the load behaviour that decides whether a campaign converts or fails. Most e-commerce problems we are asked to fix are data problems wearing a front-end costume.
Catalogue and pricing decide the build
When an e-commerce site underperforms, the visible symptom is usually the front end and the actual cause is usually the data. Attributes that do not support the way customers filter, product information that differs between the site and the feed, and pricing rules that the platform cannot express without a plugin nobody maintains.
For B2B in particular, pricing is the decision that determines everything else. Customer-specific price lists, contract pricing, volume breaks, approval-gated orders and credit limits are where standard platforms stop and where the build cost concentrates.
The second thing that gets assumed rather than tested is peak behaviour. A campaign that succeeds and then times out has cost more than one that never ran, so we load test against a peak you name and show you where it breaks.
What an e-commerce engagement covers
Six workstreams. The attribute model shapes the rest.
Catalogue and attribute model
Product data structured around how customers actually search and filter, and around how your merchandising team thinks, rather than around how the ERP happens to store it.
Pricing and contract rules
Customer-specific price lists, volume breaks, contract pricing and credit limits assessed against platform capability, with the gap costed before the platform is chosen.
Checkout and payment
Checkout built with failure handling — declined payments, timeouts, partial stock — because that is where revenue is actually lost rather than on the product page.
Product feeds
Feeds for Merchant Center and marketplaces generated from the same source as the site, so the two cannot disagree and disapprovals do not accumulate quietly.
Structured data
Product, offer, availability and review markup matching what is on the page, kept accurate by generation rather than by hand.
Load testing
Tested against a peak you name, with results and the failure point shown rather than headroom asserted.
How an e-commerce engagement runs
Model the catalogue
Attribute model designed around search, filtering and merchandising, validated against real product data rather than a sample.
Assess pricing rules
Every pricing and contract rule tested against platform capability, with the cost of each gap stated before the platform decision is made.
Build catalogue and checkout
Product experience and checkout built with failure paths handled, and integration to stock and fulfilment proven.
Wire feeds and schema
Feeds and structured data generated from one source, validated against the live pages and against marketplace requirements.
Load test and launch
Tested against your named peak with the failure point identified, then a controlled launch with monitoring.
Platform versus custom
Where the line falls, and why B2B moves it.
| Dimension | Standard platform | Platform plus extensions | Custom build |
|---|---|---|---|
| Time to launch | Fastest | Moderate | Slowest |
| Pricing flexibility | Limited | Moderate | Complete |
| Upgrade risk | Low | Extension-dependent | You own it |
| Cost profile | Licence | Licence plus build | Build plus maintenance |
| Right for | D2C, standard pricing | Most B2B | Genuinely unusual models |
| Wrong when | Contract pricing is central | Extensions are unmaintained | A platform would have fitted |
What we will establish first
A build cannot fix product data. If attributes are inconsistent, descriptions are missing and stock figures are unreliable, a new site presents those problems more attractively and to more people. Data remediation is scoped as a named deliverable with a defined stopping point, because otherwise it becomes an open-ended project of its own.
We also will not recommend a custom build where a platform would have fitted. Custom e-commerce means owning payment integration, security, tax logic and every future marketplace requirement. That is justified by genuinely unusual pricing or fulfilment models and by very little else.
- Most e-commerce problems are data problems presenting as front-end problems.
- For B2B, pricing and contract rules determine the platform decision.
- Generate feeds and schema from the same source as the site.
- Load test against a named peak and report the failure point, not the headroom.
Questions buyers ask about this
Platform or custom build?
Platform unless your pricing, contracts or fulfilment genuinely do not fit one. B2B pricing rules — customer-specific lists, contract pricing, approval-gated orders, credit limits — are the usual reason they do not. We cost each gap against platform capability before the decision rather than discovering it during build.
Will it handle a campaign spike?
We load test against a peak you name and show you the results and the failure point rather than asserting headroom. Knowing that the site degrades at four thousand concurrent users is more useful than being told it scales, because it lets you plan the campaign and the infrastructure around a real number.
Why do product feeds matter so much?
Because disapprovals accumulate silently and reduce reach without producing an obvious symptom. Generating feeds from the same source as the site means the two cannot disagree, which removes the most common cause of items being rejected or shown with wrong prices.
Can it integrate with our ERP?
Yes, and the integration design matters more than the connector. We specify per field which system owns it, whether the site reads live or from a cache, and what happens when the ERP is unavailable — a store that shows stale stock confidently causes more damage than one that says it cannot confirm availability.
How do you handle B2B-specific requirements?
Company accounts with multiple users and roles, requisition and approval flows, customer-specific catalogues and pricing, quote-to-order, and credit terms. These are assessed at the start because collectively they determine whether a standard platform is viable, and they are the most common reason a D2C-oriented build disappoints a B2B seller.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.