Ecommerce Development Services: Custom Build vs Platform, and What It Costs

Most ecommerce projects do not fail on the storefront. They fail on the third integration nobody scoped — the ERP that holds real stock levels, the tax engine that behaves differently in two states, the warehouse system that only speaks CSV over SFTP at 3am.

This guide is about deciding well before that happens: when a platform is the right answer and when custom is, what an ecommerce engagement actually contains, what headless commerce changes in practice, what the work costs at each scope, and how to check a partner before you commit.

Custom build or platform: which does your store need?

Start on a platform unless you have a specific reason not to. Shopify, Magento and their peers already solve carts, checkout, tax, payments and PCI scope — problems that are expensive to rebuild and unglamorous to maintain. Custom development earns its cost when your commercial model does not fit the platform's assumptions.

The expensive mistake in both directions is the same: choosing before understanding the commercial model. A platform build that spends nine months fighting the platform costs more than the custom build would have; a custom build of things Shopify does for free costs more than it ever returns. Our comparisons of Magento versus Shopify and WordPress versus Shopify go through the platform side of that decision in detail.

What does an ecommerce development engagement include?

A real engagement covers five layers, and only the first is visible to customers. Storefront and design, the commerce backend holding catalogue and orders, payments and tax, the integrations into systems you already run, and the operational work — environments, testing, migration and launch — that decides whether any of it survives Black Friday.

• Storefront — category and product pages, search and filtering, cart and checkout, and the performance budget that governs all of them.
• Commerce backend — catalogue structure, variants, inventory, promotions, order lifecycle and returns.
• Payments and tax — gateways, fraud rules, multi-currency, and the tax logic for every market you sell into.
• Integrations — ERP, PIM, warehouse and shipping, CRM, analytics, and the marketing stack.
• Data migration — products, customers, order history and the URLs that carry your existing search rankings.

Migration deserves naming separately, because it is the item most often discovered late. Moving a catalogue is straightforward; preserving order history, customer accounts and every indexed URL is not, and getting the redirects wrong is the fastest way to lose traffic you already had.

What does headless commerce actually change?

Headless splits the storefront from the commerce engine and connects them over APIs. The practical gain is independence: the front end can be rebuilt, re-designed or re-platformed without touching orders and payments, and marketing can ship pages without waiting on a release cycle tied to the backend.

The cost is that you now own things the platform used to own. Checkout behaviour, SEO rendering, preview environments and the front-end deployment pipeline all become your team's responsibility. That trade is worth it for a content-led brand publishing constantly across several markets. It is rarely worth it for a single-market store with a stable catalogue.

The same pattern shows up in cloud programmes generally: McKinsey estimates nearly $3 trillion in available value from cloud adoption, while 82% of the executives it surveyed said the benefits they had captured were partial, limited to specific areas, or still early-stage (McKinsey). Adopting the architecture is not the same as getting the return from it — headless included.

Migration: the part that decides whether you keep your traffic

Replatforming puts existing search rankings at risk, and the damage is usually self-inflicted rather than unavoidable. Products move to new URLs, filters generate different paths, and the redirects that should carry authority across either get written late or get written from the new sitemap instead of the old one.

One rule prevents most of it: build the redirect map from a crawl of the live site, never from the new site's sitemap. The new sitemap only knows pages that exist now, which is precisely the wrong direction — the pages you must not lose are the ones about to disappear.

Where ecommerce builds actually overrun

Overruns cluster in the same four places, and none of them is the storefront. Recognising them at proposal stage is cheaper than discovering them in month three, when the launch date is already announced and the scope conversation has become a contract conversation.

• The integration you inherited. An ERP or warehouse system with no documentation and one person who understands it sets the real pace of the project.
• Product data quality. Inconsistent variants, missing attributes and duplicate SKUs surface during migration and have to be cleaned by someone who knows the catalogue.
• Tax and shipping rules. Every additional market adds rules that are simple individually and interact badly in combination.
• Undecided merchandising. If nobody has settled how promotions, bundles and tiers should work, that decision will be made repeatedly during the build.

The practical defence is to scope the integrations and the catalogue clean-up as their own workstreams with their own owners, rather than folding them into the build as assumptions. Both are business work as much as engineering work, and neither goes faster because a developer is waiting.

What does ecommerce development cost?

Price the scope, not the platform. A themed platform store and a custom marketplace differ by an order of magnitude, and most of the gap sits in integrations and migration rather than in the storefront everyone looks at during the sales conversation.

The recurring costs matter as much as the build and are missed more often: platform or licence fees, payment processing, hosting and CDN, third-party apps that quietly accumulate, and the development capacity to keep integrations working as the systems on the other end change. Budget for the year after launch, not just the launch.

How to check an ecommerce development partner

Ask about the parts that are hard to fake. Anyone can show a good-looking storefront; far fewer can talk credibly about a migration that preserved rankings, an integration that survived a peak season, or what happened the first time a payment provider changed its API mid-project.

1. Show me a store you migrated, and what happened to its traffic. Migration is where damage is done, and honest partners have the before-and-after numbers.
2. Who owns the code, the repository and the platform accounts? The answer should be you, in writing, from the start.
3. How do you handle peak load? Ask what they did on a real peak day, not what their architecture theoretically supports.
4. What is the integration list, and who is responsible for each end? The systems you already run are the most common source of overrun.
5. What is in the price and what is billed separately? Design, QA, project management, infrastructure and migration should all be named explicitly.

How Empat approaches ecommerce work

Empat is a custom software and AI development agency with offices in San Francisco, London and Kyiv. We work at the platform-plus-custom end of this range rather than the themed-template end — the projects where the commerce engine is only part of the problem and the integrations decide the timeline.

That includes Magento development for catalogue-heavy and B2B stores, and custom front ends where performance or content velocity justifies going headless. Billing is transparent: no hidden infrastructure or onboarding fees, prepayment rolls into the first invoice, and utilization is shared with the client.

If you are hiring rather than choosing an approach, hire ecommerce developers covers the roles a store actually needs, hire Shopify developers covers the platform-specific case, and how to find a web developer covers the search itself. Our broader industry work is on the industries page.

FAQ

How much does custom ecommerce development cost?

A themed platform store starts around $30,000 over six to ten weeks. Adding a custom backend, ERP integration and data migration moves it to roughly $50,000 and three to five months. A headless build starts near $60,000, and a custom multi-seller marketplace commonly exceeds $100,000. Integrations and migration drive more of the variance than the storefront does.

Should I use Shopify or build custom?

Use Shopify or a similar platform unless your commercial model breaks its assumptions. Complex contract pricing, multi-seller payouts, deep ERP dependency or unusual fulfilment logic are the signals that justify custom work. Building a cart, checkout and PCI-compliant payment flow from scratch when a platform already provides them rarely returns the investment.

What is headless commerce?

Headless commerce separates the customer-facing storefront from the commerce engine that holds catalogue, orders and payments, connecting them through APIs. It lets you redesign or replatform the front end without touching transactions, and lets marketing publish without a backend release. In exchange, your team takes ownership of checkout behaviour, SEO rendering and front-end deployment.

How long does an ecommerce site take to build?

A themed platform store takes six to ten weeks. A platform build with custom backend work and migration runs three to five months. Headless projects typically take four to six months, and custom marketplaces six to twelve. Data migration and third-party integrations are the two items most likely to extend any of these estimates.