eCommerce Development: What the Process Should Actually Look Like End to End

Most ecommerce development projects go wrong not because of technical failure but because the process was skipped. That is not a dramatic claim. It is what you see when you have reviewed enough builds where the ERP rules were never mapped, the catalogue assumptions were never written down, and checkout was tested once on a happy path. Discovery was a kickoff meeting, architecture was a platform preference, and the first time real edge cases surfaced was during UAT.

The short answer: A rigorous ecommerce development process moves through discovery, solution architecture, UX and data validation, staged build, serious testing, launch readiness, and a structured post-launch handoff. Each phase has clear inputs, outputs, owners and decisions. If any of those phases is thin or absent, you are not buying a process – you are buying optimism.

This is a guide for buyers who want to tell the difference before they sign anything.

Discovery should reduce risk, not collect vague requirements

The first phase is not a polite kickoff and a feature wish list. It should expose how the business actually works, where the dependencies sit, and what breaks if those assumptions are wrong. Ask any supplier how they handle catalogue structure, customer types, fulfilment rules, payment logic and operational constraints before they start talking timelines.

Weak process versus real process: a weak process gives you a long list of requested features. A rigorous one gives you mapped integrations, product data rules, scope priorities, decision owners and known risks. That work belongs in discovery, not after design sign-off.

A catalogue can look simple until variants, bundles and customer-specific pricing collide with ERP rules. In my experience, if nobody can explain how products, filters, pricing logic and fulfilment exceptions are modelled before a single line of code is written, the project is not ready for build. Treat that as a warning sign, not a detail to revisit later.

Discovery outputs worth asking for:

• Prioritised scope, not an unranked wish list
• A dependency map covering ERP, PIM, payments, shipping, tax and third-party tools
• Product data and catalogue assumptions written in plain English
• Known delivery risks, open questions and named decision owners

Architecture decisions need to happen before the build starts looking busy

This is where good projects quietly separate themselves from expensive clean-up jobs. Platform and solution architecture decisions shape maintainability, scalability and operational overhead long before anyone can point at visible progress. Ask why Shopify, WooCommerce, Magento or headless commerce is being recommended for your specific model – not as a house preference dressed up as a recommendation.

My view, having managed builds across Shopify, Magento and WooCommerce at varying scales, is that B2B eCommerce capability changes the architecture picture faster than most buyers expect. Account hierarchies, customer-specific pricing, approval flows, quote logic and permissions are not small add-ons. They affect platform choice, admin workflows and integration behaviour from the start. Do not assume they can be patched in later without significant rework cost.

Checkout is the other place where early architectural choices come back to hurt you. Security, payment behaviour, tax handling, compliance and performance need designing in early because edge cases break pretty demos in production. Load testing is not one standard script run against a staging environment. It should reflect how your store is expected to behave when a promotion spikes traffic, when a payment gateway slows, and when fulfilment exceptions stack up simultaneously.

Watch for suppliers who promise a confident timeline before they have challenged traffic patterns, promotion spikes, integration bottlenecks or checkout sensitivity. That confidence is not competence. It is a proposal written before the hard questions were asked.

UX, data and integrations should move together, not in separate silos

Once architecture is set, the next mistake is splitting design, data and systems into separate tracks as if they barely touch. In ecommerce, they touch constantly. Navigation, filtering, merchandising, account areas and checkout behaviour all depend on what the product data can support and how external systems behave.

If you are reviewing wireframes or designs, ask what stock logic, pricing rules, shipping methods, tax handling, account states and exception paths those journeys assume. You need validated behaviour, not just approved screens. That is where a project discovery workshop can be useful, because it forces the awkward questions out before build accelerates.

A common failure pattern I see repeatedly: a B2B catalogue with customer-specific pricing and mixed fulfilment rules. On paper, the UX looks straightforward. In reality, search visibility, permissions, checkout options and ERP responses shape what the customer can actually do. The visible problem looks like page design. The real issue sits in data ownership and integration behaviour – and the design team had no idea because nobody asked the data team the right questions.

Before development scales up, ask for agreed journeys, data assumptions, integration behaviour, exception handling and acceptance criteria written in plain English. If third-party systems are likely to drive the risk, also review planning eCommerce integrations before development starts.

A proper delivery phase includes staged build, serious testing and launch readiness

“Development and QA” is not a real process. You should expect staged releases on a working environment, review points that catch issues early, and clear ownership for content, product data and UAT. If you only see the site near the end, problems get expensive very quickly.

Working staging versions matter because they let you review real behaviour before final UAT. Ask what you will see at each stage, what is expected from your team, and who signs off journeys, data and integrations before the next phase moves on.

What the end-to-end process should look like at a glance

Discovery: inputs include business goals, catalogue rules, customer types and system landscape. Outputs should be scoped priorities, dependency mapping and delivery risks. Indicative duration: early phase, before solution commitment.

Architecture and solution design: inputs include discovery outputs, platform options and operational constraints. Outputs should be platform choice, technical approach, data model direction and integration logic. Indicative duration: short, focused phase before build planning.

UX, data and integration validation: inputs include journeys, product structure and system rules. Outputs should be validated flows, agreed assumptions, exception handling and clearer acceptance criteria. Indicative duration: overlaps with solution design, before build scales up.

Build and staged review: inputs include approved scope, designs and technical decisions. Outputs should be working increments, feedback loops and resolved defects. Indicative duration: main delivery phase with regular review points.

Testing and launch readiness: inputs include near-complete build, content, data and integrations. Outputs should be UAT sign-off, checkout checks, security review, performance checks and launch plan. Indicative duration: final pre-launch phase, not a last-minute scramble.

Launch and post-launch monitoring: inputs include approved release plan and support ownership. Outputs should be live monitoring, issue triage, backlog separation and handoff clarity. Indicative duration: immediate days and weeks after go-live.

Testing needs to go beyond happy-path QA. Ask how they test payment failures, tax and shipping logic, permissions, bad product data, integration timeouts, device-specific issues and checkout edge cases – not just whether pages load. Also ask how much work sits with your team. Product data review, content input and UAT ownership are rarely small jobs. I have seen projects stall for weeks because a client’s team underestimated their own content and data obligations.

Not sure if your ecommerce project is scoped properly?

Most builds go wrong because discovery was rushed or integration dependencies were never mapped. We run structured discovery workshops that expose catalogue rules, ERP behaviour, checkout logic and operational constraints before development starts.

Check your scope

Quick diagnostic call to see where the gaps sit

Go-live is where process gaps become operational problems

This is where I see weak processes reveal themselves most reliably. Access is scattered across individual inboxes, known limitations were never documented, support boundaries are undefined, and the first operational exception lands with nobody sure who owns it. That is not a launch problem. It is a process failure that started in discovery and compounded through every phase that followed.

The first week after go-live should not be improvised. Checkout stability, order flow, payment behaviour, integration health and admin exceptions need active monitoring – not a shared inbox and a hope. You should know in advance who watches what, what triggers an escalation, and what the response time commitment is.

What a clean handoff actually requires:

• Documentation covering architecture decisions, integration configurations and known constraints
• Clear access ownership for hosting, CMS, admin, analytics and third-party platforms
• Defined support routes with named owners, not a generic support@ address
• A written split between launch-critical fixes and phase-two improvements – so the backlog does not become a negotiation about what was supposed to be in scope

That is also where eCommerce maintenance in London becomes a practical planning question rather than an afterthought. Who handles fixes, updates, monitoring and change requests once the project team steps back needs answering before launch, not after the first incident.

If you want a sober way to assess a supplier before you commit, ask them to walk you through their discovery outputs, architecture decisions, staged testing approach, launch readiness checklist and what the first two weeks after go-live look like operationally. If they can do that clearly without reaching for a generic deck, you are probably looking at a real process. If they hesitate or redirect to timelines and pricing, you have your answer. Also worth reading: how the process changes in a headless eCommerce build.