Short answer: judge a nearshore partner for a large commerce programme on five artefacts — a migration traffic graph, a stock-sync design, a checkout edge-case list, named integration experience, and a written peak-season cover plan. Everything else in the pitch is decoration.
Large commerce projects fail in predictable places
Not in the design. In five places, every time:
1. The migration loses search traffic that took years to earn.
2. Stock goes wrong across channels and you oversell on the busiest day.
3. Checkout edge cases leak revenue quietly for months before anyone notices.
4. The ERP integration turns out to behave nothing like its documentation.
5. Peak season arrives and nobody with context is reachable.
So vet for those five specifically, in that order.
1. Migration evidence
Demand: a replatform they ran and the organic traffic graph either side, with dates.
A competent migration dips slightly for one to two weeks and recovers. An incompetent one steps down and stays there, and no amount of subsequent marketing recovers it.
Also ask: how do you build the URL inventory, what is your redirect testing process, and how do you compare crawls before and after launch? A team that answers with a process has done it. A team that answers with reassurance has not.
2. Stock and feed integrity
Demand: a written description of how stock stays honest across web, marketplaces and retail.
"A nightly job" is a design for overselling. Ask what happens between runs during a flash sale, how reservations work in the checkout window, and what reconciles the truth when two channels disagree.
Also ask: what the feed contract is per channel, how errors surface, and who notices when a feed silently stops. Silent feed failure is one of the most expensive bugs in commerce because nothing looks broken.
3. Checkout depth
Demand: their list of checkout edge cases from a previous build.
A real list includes declined cards, partial stock failure mid-order, tax by jurisdiction and threshold, shipping rules by weight and destination, currency rounding, promotion stacking rules, guest-to-account conversion, and payment provider timeouts.
If the answer is "standard checkout", you are buying the happy path, and the unhappy paths are where the money goes.
Everyone tests the purchase. The revenue leaks live in what happens when the purchase fails halfway.
4. Integration experience, named
Demand: the names of ERPs, WMSs and fulfilment systems they have integrated, and one story of a system that behaved differently from its documentation.
Then price it honestly: discovery first, build second. Integrations into systems you do not control cannot be fixed-price in good faith before someone has read the actual API responses. A supplier who quotes one anyway has either padded it enormously or is planning a fight.
5. Peak-season cover, in writing
Demand: a cover plan as a contract clause, not a promise.
It should contain:
- Named on-call engineers for the peak window.
- A response time defined in your trading hours.
- An agreed code freeze window, set months in advance.
- A rehearsed rollback — rehearsed, not documented.
- Monitoring on checkout completion rate, payment failure rate and stock sync lag, with someone paged.
- A load test against realistic peak, run in advance, results shared.
A nearshore team inside Europe overlaps your full working day, so this is a contract question rather than a geography question. Get it written down either way.
Commercial terms that protect you
| Term | What to insist on |
|---|---|
| Ownership | Store admin, repository, cloud, analytics in your name throughout |
| Named team | Specific engineers, notice before any change |
| Change pricing | A published day rate, not case by case |
| Notice period | Short enough that leaving is cheap |
| Handover | A defined package, deliverable within the notice period |
| Proprietary layers | None you cannot operate without them |
That last row matters more on long commerce programmes than anywhere else. Some agencies ship a "framework" of their own on top of the platform. It speeds up year one and makes year three a hostage negotiation.
Where the budget actually goes
| Area | Share of effort |
|---|---|
| Storefront and design | ~15% |
| Migration and URL mapping | ~15% |
| Catalogue, feeds, stock sync | ~20% |
| Checkout, tax, shipping | ~20% |
| ERP, fulfilment, integrations | ~25% |
| Observability and ops | ~5% |
Use it to sanity-check every proposal you receive. One that spends its pages on visual design has priced the easiest sixth of the work.
We build commerce and marketplace systems that are live now — scenta.ro, codcheck.ro — with published prices: €9,500 for a bounded first slice, €7,000 a month for a dedicated senior team, €450 a senior day. Tell us about the programme.
Frequently asked
What is the single most important thing to check?
A replatform they ran, with the organic traffic graph either side of it. Most large commerce failures are migration failures, and that one artefact predicts migration competence better than any credential.
How should peak season be handled contractually?
Named on-call engineers, a response time defined in your trading hours, an agreed code freeze window, a rehearsed rollback, and monitoring tied to checkout completion and payment failure rates rather than server metrics.
How are integrations into an old ERP priced?
As discovery first, build second. Any partner who fixes a price on an undocumented third-party system is either padding heavily or planning a change-request argument.
What exit terms should a large commerce contract include?
Store admin, repository, cloud and analytics in your name throughout; a documented handover package; a defined notice period; and no proprietary layer you cannot operate without them.