Choose an e-commerce development partner on stores they have run rather than stores they have launched. Ask for conversion and performance numbers, how they handle peak trading, and what their support commitment is on a Saturday in December. Commerce work is judged after go-live, when downtime has a price per hour.
The selection criteria differ from ordinary software procurement because the system earns money continuously. A partner who builds well but responds slowly is a worse commercial choice than one who builds adequately and answers within the hour.
Key takeaways
- Ask for operating evidence: Conversion rate, page speed and uptime on stores they still support.
- Peak season is the real test: Establish now what cover exists during your busiest trading period.
- Integrations decide the timeline: ERP, stock and payment connections are where commerce projects overrun.
- Get a response-time commitment: If an hour offline costs real revenue, best effort is not a support model.
Ask what happened after launch
A portfolio of launched stores tells you a partner can deliver a project. It does not tell you whether the store worked.
Ask for stores they still support, and for numbers: conversion rate before and after, page load times, uptime, and what they changed in the first six months based on data. Partners who operate stores will have these readily. Partners who build and hand over will talk about design instead.
Ask directly what the worst incident they have handled was, and what happened. Every partner running commerce systems has had a payment gateway fail or a stock feed corrupt during a sale. How they describe it tells you how they will describe yours.
Assess four capabilities separately
Commerce depth is understanding of the mechanics that determine revenue: checkout flow, payment failure recovery, tax and shipping rules, promotions, and the operational reality behind returns.
Integrations are usually the schedule risk. Ask how they have handled ERP, stock and accounting connections before, and what they do when the source system is slow or briefly unavailable.
Delivery is process quality: environments, testing, release approach, and the ability to deploy a fix during trading without taking the store down.
Ownership is who holds the hosting, domain, payment and platform accounts. These should all be yours, and it is far easier to establish at the start.
Settle peak-season cover before signing
Most retail businesses take a disproportionate share of annual revenue in a few weeks. That is exactly when a partner's ordinary support model is least useful.
Agree in writing: what cover exists outside business hours during peak, what the response time commitment is, whether there is a code freeze period, and who is reachable. If the answer is that someone will probably see the email, price that risk against your hourly revenue and decide whether it is acceptable.
This conversation is straightforward before a contract and adversarial during an outage.
Price the integrations individually
The most common overrun in commerce projects is integration work quoted as a single line. Each connection — stock, pricing, orders to ERP, accounting, shipping, tax, marketing — has its own data model, failure behaviour and reconciliation requirement.
Ask for each to be priced separately, and for each to have a named owner, a stated source of truth, and a defined behaviour when the other system is unavailable. A proposal that treats integrations as one number has not examined them.
For the wider planning decisions this sits inside, see the e-commerce app development guide.
Confirm what you own
Before signing, establish in writing that you own the source code from day one and it lives in a repository you control; that the hosting, domain, payment provider and platform accounts are in your company's name; that customer and order data is exportable in a documented format; and what is handed over if the relationship ends.
The payment account matters most. A store transacting through a partner's merchant account is a store that cannot easily change partner, and that constraint tends to surface at the least convenient time.
Start with something small and real
Where possible, begin with a bounded first engagement — a performance audit, a checkout improvement, a single integration — before committing to a replatform.
It gives you evidence of how they work, and it usually pays for itself. Checkout friction and page speed are among the few areas where a small, well-targeted piece of work produces a measurable revenue change within weeks, which is also the fastest way to find out whether a partner can deliver one.
Related guides
- Alongside How to Choose an E-Commerce Development Partner, continue with E-Commerce App Development: A Practical Planning Guide.
- Alongside How to Choose an E-Commerce Development Partner, continue with Mobile Loyalty App Development: Features, Cost Drivers, and Roadmap.
If the work prompted by How to Choose an E-Commerce Development Partner leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Commerce Platform.
Ali Boran Gazel