Short answer: most of an e-commerce project's cost is not the storefront. It is the migration, the feeds, checkout edge cases, tax and shipping rules and the integrations behind them. A fixed scope is achievable for everything you control, and the parts you do not control should be priced separately and honestly.
The homepage is the cheap part
Every e-commerce brief opens with design and closes with "and integrate with our ERP". The second sentence is the project.
Where the effort actually lands, roughly, on a serious build:
| Area | Share of effort | Why it bites |
|---|---|---|
| Storefront and design | ~15% | Well-understood, genuinely fixable in scope |
| Migration and URL mapping | ~15% | Lose this and you lose the traffic you already paid for |
| Catalogue, feeds, stock sync | ~20% | Stock honesty across channels is a permanent obligation |
| Checkout, tax, shipping rules | ~20% | Edge cases are where revenue leaks |
| ERP, fulfilment, integrations | ~25% | Behaviour is discovered, not documented |
| Observability and ops | ~5% | Skipped, then urgently retrofitted |
Reading that table is the fastest way to tell whether a proposal is serious. If a quote spends most of its words on the visual design, it has priced the easiest fifteen per cent and will discover the rest with your money.
Shopify or custom
Shopify is the right answer more often than agencies like to admit. For standard catalogue retail you get payments, fraud, tax, PCI scope, a fulfilment ecosystem and an app market for a monthly fee. Custom-building that is a decade of work you do not want to own.
Custom earns its place when the commerce model is unusual: B2B pricing tiers per customer, product configurators, rental or subscription mechanics, multi-seller marketplaces, or industry-specific compliance in the order flow. There the platform's opinions cost more than they save.
The mistake is choosing custom because the brand wants a distinctive storefront. Distinctive storefronts are entirely achievable on a headless Shopify setup, with the platform doing the boring parts you cannot afford to get wrong.
Nobody has ever lost money because their checkout was too standard. Plenty have lost money reimplementing tax.
What fixed scope must include
A fixed-scope e-commerce agreement should enumerate, explicitly:
- Every template and its empty, loading and error states.
- The complete URL map, old to new, with redirect behaviour.
- Catalogue structure, variant model and the feed contract for each channel.
- Checkout: currencies, tax rules by jurisdiction, shipping rate logic, payment methods, and what happens on a declined card or a partial stock failure.
- Named integrations, each with the version and the documentation you are handing over.
- The launch plan, including the crawl comparison and the rollback.
Anything that depends on a system you do not control — an ageing ERP, a warehouse API with no docs — gets a separate discovery line with a real number. A supplier who fixes a price on an undocumented integration has either padded it enormously or is planning a change-request conversation.
Why nearshore fits commerce work
Commerce is seasonal and unforgiving. A bug on the second Friday in November is a different kind of event from a bug in March. What you need from a partner is response latency, not headcount.
A nearshore team in Europe gives you a full overlapping working day: a question at 09:30 gets an answer before lunch, and someone with context is reachable during your trading hours. A twelve-hour offset turns every ambiguity into a half-day round trip, and commerce ambiguities compound because they usually involve money moving.
For North American clients the calculus is similar but shifted: European teams overlap the US morning, which covers the window where most decisions get made, and EU jurisdiction means GDPR handling is native rather than bolted on.
Vetting a partner for a large-scale build
Five questions worth more than any pitch deck:
1. Show me a migration you ran and the traffic graph either side of it. The graph is the whole answer.
2. How do you keep stock honest across three channels? If the answer is "a nightly job", ask what happens between jobs on a sale day.
3. What is your checkout failure rate and how would you know? Tests the observability culture.
4. Which named engineer is on this in month nine?
5. Who owns the repository, the cloud accounts and the store admin? Yours, from commit one, or walk.
We have built commerce and marketplace systems that are open in a browser today — scenta.ro and codcheck.ro among them — and our rates are published rather than negotiated: €9,500 for a bounded first slice, €7,000 a month for a dedicated senior team, €450 a senior day.
Frequently asked
Where does the money actually go in an e-commerce build?
Not the homepage. Migration that preserves URLs and rankings, the product feed that keeps stock honest across channels, checkout edge cases, tax and shipping rules, and the integrations into ERP and fulfilment. That is 70% of the effort in most projects.
Shopify or a custom commerce platform?
Shopify for standard catalogue retail — you get payments, tax, fraud and PCI scope for a monthly fee. Custom when the commerce model is unusual: B2B pricing tiers, configurators, rental or subscription logic, or a marketplace with multiple sellers.
Can an e-commerce build be fixed scope?
The build can. Integrations into systems you do not control should be separately estimated, because their behaviour is discovered rather than specified. Any supplier who fixes a price on an undocumented third-party ERP integration is guessing.
How do you protect search rankings during a replatform?
A full URL inventory before anything is built, a mapped 301 for every URL with traffic or links, structured data preserved, and a crawl comparison before and after launch. Replatforms that lose traffic lose it at exactly this step.