Ecommerce website cost: the honest bands, shape by shape

Ask three agencies what an ecommerce website costs and the answers will span two orders of magnitude, all of them defensible. That is because the question, as asked, has no answer: an ecommerce website is not one product. A founder validating a product line with thirty items, a retailer moving an established catalog online with a warehouse behind it, a brand that has outgrown its platform and needs a storefront the platform cannot render, and an operator assembling a multi-vendor marketplace are buying four different systems that happen to share a checkout button.

This guide prices the four shapes separately, because that is the only honest way to do it. For each, it gives the band, what sits at the bottom and top of the band, and the drivers that move a project from one end to the other. It then does what most pricing articles skip: the recurring bill, which in ecommerce is not a footnote but the larger number over any horizon past two years, and the hidden lines, migration, redirects, content production, and compliance, that appear on no proposal and every invoice.

Two boundaries, so this guide stays useful. The general question of what any website costs, marketing sites, web apps, and the agency-versus-freelancer decision, lives in our website cost breakdown. And the engineering anatomy of a custom build, the architecture, the layer-by-layer scope, and the staged launch sequence, lives in the ecommerce platform build guide. This article owns the money: what you will actually pay, for what, and how to know your quote is real.

The four store shapes: price the product, not the word

The template store is the first shape: a hosted platform account, a purchased or free theme, products entered by hand, and the built-in checkout doing what it does. Launch cost runs $500 to $5,000 depending on whether the owner does the work or pays a freelancer, and the shape is genuinely right for its job: validating demand, selling a small catalog, testing a market before committing capital. Its ceiling is real but distant for most new stores; the money mistake at this stage is not underspending, it is overspending, paying custom-build prices for a business that has not yet proven anyone wants the product.

The platform store is the second shape and the center of gravity of the market: the same hosted platform, taken seriously. A customized or custom-designed theme, a structured catalog with variants and collections, payment and shipping configured for real operations, apps or light custom code for the gaps, migration of an existing catalog and its SEO equity, and integrations with accounting, email, and fulfillment. This runs $5,000 to $40,000 with an agency or a competent offshore team, and the width of that band is mostly catalog complexity and integration count, not design taste.

The custom storefront is the third shape, and the first rule about it is to resist it until the platform ceiling is real. Here the buying team builds its own frontend, and sometimes parts of the backend, against a commerce engine, because the platform genuinely cannot render the experience, the catalog logic, or the performance the business needs: configurable products with pricing engines, B2B contract terms, storefronts embedded in unusual channels, or international structures the platform handles badly. At offshore rates this runs $40,000 to $150,000; at Western agency rates, two to three times that. The engineering anatomy of this shape, what the layers are and how the build sequences, is the subject of the platform build guide.

The marketplace is the fourth shape and a different species, not a bigger store: multiple vendors with their own catalogs and payouts, commission logic, vendor onboarding and dashboards, split payments, and dispute flows. The moving parts multiply and so does the price: $120,000 is a realistic floor for a first production version at offshore rates, and mature marketplaces spend multiples of that across their first years. Anyone quoting a marketplace at platform-store prices is describing a plugin demo, not a business.

Which shape are you actually buying?

What does the business need the store to do?

• Validate a product line, small catalog

  Template store

  Speed and cheapness are the strategy; custom anything is premature capital.

• Run a real retail operation on a platform

  Platform store, configured seriously

  The platform ceiling is far away; the money belongs in catalog, integrations, and migration.

• The platform provably cannot render the business

  Custom storefront on a commerce engine

  Pricing engines, B2B terms, or performance needs justify owning the frontend.

• Multiple vendors selling through you

  Marketplace build

  Vendor management, split payments, and commissions are a different product with a different floor.

What actually moves the estimate

Catalog complexity is the first driver and the most underestimated. Thirty simple products and three thousand products with size-color variants, per-region pricing, bundles, and back-in-stock logic are different engineering problems wearing the same word. Complexity shows up everywhere at once: the data model, the import pipeline, the search and filtering, the page templates, and the migration effort. When an estimate doubles between a first call and a proposal, the catalog walkthrough is usually what happened in between, and that is the estimator doing their job.

Checkout and payments are the second driver. A single-country store on the platform checkout costs nearly nothing extra; each addition has a price tag. Multiple currencies and tax regimes, local payment methods beyond cards, wallets with their own integration quirks, subscriptions and recurring billing, B2B terms like partial payment and invoicing, and gift flows each add integration work and, more expensively, testing surface. Payment bugs are the one category a store cannot ship and apologize for, so this scope is priced with its testing included or it is underpriced.

Integrations are the third driver, and they scale with how real the operation is. Accounting sync, a warehouse or 3PL connection, shipping rates and label generation, email and marketing automation, a POS if there are physical stores, and an ERP if the company is old enough to have one. Each integration is small; the tenth one is not, because they interact. A store that must keep stock truthful across a warehouse, two sales channels, and a POS has quietly bought an inventory synchronization problem, and the estimate that missed it will be corrected by production incidents.

Design is the driver everyone expects to dominate, and it usually does not. A quality theme, customized with restraint, serves a platform store excellently for a few thousand dollars. Fully custom design earns its price at two moments: when brand differentiation is the actual competitive strategy, and when conversion optimization on real traffic justifies bespoke flows. Buying custom design before having traffic to convert is the most common way ecommerce budgets die: the money that should have bought integrations and content buys pixels nobody measures.

Spending the budget where it works

Do this

• Walk the catalog before pricingVariants, pricing rules, and data quality set the real scope; an estimate without a catalog walkthrough is a guess.
• Price payments with testing includedCheckout is the one surface that cannot ship broken; the testing line is part of the price, not padding.
• List every system the store must talk toAccounting, warehouse, shipping, email, POS. The tenth integration costs more than the first because they interact.

Not this

• Buy custom design before trafficBespoke flows optimize conversions you do not yet have; a good theme converts fine while you earn the data.
• Treat migration as an afterthoughtCatalog, customers, orders, and URL equity move or the launch is a step backward wearing a new theme.
• Compare quotes without their assumptionsA $15k and a $40k quote for the same store are pricing different scopes; make both write the assumptions down.

The bands, with what sits at each end

The template store band, $500 to $5,000, runs from a self-built store on a monthly plan with a free theme to a freelancer-assisted launch with a purchased theme, configured shipping and taxes, and a clean product upload. The top of the band buys polish and time saved, not capability; the capability is the platform, and it is the same at both ends. The spend to be suspicious of in this band is the four-figure custom theme for a store with no sales history.

The platform store band, $5,000 to $40,000, is wide because it covers the real spread of retail operations. The bottom is a clean single-market store: customized theme, structured catalog in the hundreds, standard payments, a couple of integrations, and a straightforward migration. The top is a serious trading operation: custom design on the platform, thousands of SKUs with variants and pricing rules, multi-market checkout, a full integration set including warehouse and accounting, and a migration with URL mapping and SEO continuity engineered rather than hoped for. Most established small and mid-size retailers land between $12,000 and $30,000 when the scope is honest.

The custom storefront band, $40,000 to $150,000 at offshore rates, prices the shape where the frontend, and sometimes order or pricing logic, is owned code. The bottom of the band is a custom storefront over a commerce engine with standard flows; the top adds pricing engines, B2B account structures, multi-region architecture, and the operational integrations of a company big enough to need this shape. Western agency pricing for the identical scope runs two to three times the band, which is the arithmetic behind offshore delivery for these builds; the trade-offs of that decision are their own subject.

The marketplace band starts near $120,000 and does not really have a top. The floor buys the minimum honest version: vendor onboarding, per-vendor catalogs, split payments through a marketplace-capable processor, commission logic, and basic vendor dashboards. Everything a real marketplace becomes, ratings and disputes, vendor tooling, logistics orchestration, category expansion, is a roadmap priced in years. The marketplace decision is a business-model decision wearing a technology costume, and it should be made on unit economics, not on how achievable the build looks.

The bands at a glance, offshore rates

$500 to 5k Template store launch Self-built to freelancer-assisted; capability is the platform at both ends.

$5k to 40k Platform store, configured seriously Most established retailers land at $12k to 30k with honest scope.

$40k to 150k Custom storefront on a commerce engine Western agency pricing runs two to three times this band.

$120k and up Multi-vendor marketplace floor Split payments, commissions, vendor tooling; the top is a roadmap, not a number.

The recurring bill: the number that outgrows the build

Ecommerce is unusual among software purchases in how quickly the running costs overtake the build. A platform store carries a platform subscription, an app stack that accretes toward $100 to $500 a month at surprising speed, and payment processing at roughly 2 to 3.5 percent of revenue plus per-transaction fees, which at any real sales volume is the largest technology line the business pays, disguised as a cost of goods. Add theme and app updates, seasonal campaign work, and somebody on call when checkout misbehaves, and a store built for $20,000 routinely spends $10,000 to $25,000 a year staying alive and current.

A custom storefront trades some of those lines for others. Platform subscription may shrink or vanish, and app rents become owned code, but owned code is a payroll: hosting and infrastructure, dependency updates, security patching, and the engineering retainer that keeps the storefront moving with the business, realistically fifteen to twenty-five percent of the build cost per year. The crossover arithmetic matters: a business paying heavy platform percentage fees at scale can genuinely save money owning its stack, but only above a revenue line that most stores never cross, which is why the custom shape is a ceiling response, not an ambition.

The line that belongs in every recurring budget and appears in almost none is content. Products need photography, copy, and translations where markets demand them; categories need merchandising; campaigns need assets; and the store that stops producing content stops growing well before its technology limits it. Teams budget the build to the dollar and then starve the content line that determines whether the build earns anything. Whatever the shape, the honest annual budget has three columns: keep it running, keep it selling, and keep it growing, and the first column is the smallest.

The hidden lines: what proposals omit and invoices include

Migration is the first hidden line, and on replatforming projects it is frequently a third of the honest budget. Products with their variants, images, and metadata; customers with their accounts and consent status; order history if the operation needs it; reviews, which carry conversion weight; and gift card and store credit balances, which carry legal weight. Source data is always dirtier than anyone remembers, and the cleanup is real work. A replatforming proposal without a migration section priced in days is a proposal for building a store next to your business rather than under it.

URL continuity is the second, and it is where replatforming projects quietly destroy value. An established store has years of search equity distributed across product, category, and content URLs, and the new platform will want different URL shapes. Every old URL needs a mapped redirect to its new counterpart; the sitemap, the structured data, and the canonical logic need rebuilding; and rankings need monitoring through the cutover. Done properly this is days of engineering and weeks of vigilance. Skipped, it shows up as a twenty to forty percent organic traffic drop that the new store gets blamed for and the missing redirect map actually caused.

Compliance and content production round out the hidden set. Payments bring PCI scope questions, even when the processor carries most of the burden; privacy regulation touches every store that emails customers or drops a pixel; tax collection across states or countries is configuration work with penalties for getting it wrong; and accessibility is both a legal exposure and a conversion issue. Content production, photography, copy, size guides, translations, is the line most likely to be assumed away as something the merchant will handle, and the launch delay it causes is the most common one in ecommerce projects. Name every one of these lines in the budget, even at zero, so their absence is a decision rather than a surprise.

The lines to force into every proposal

• Migration, per data typeProducts, customers, orders, reviews, balances; with a cleanup allowance, because source data always needs it.
• Redirect map and SEO continuityEvery old URL mapped, sitemap and structured data rebuilt, rankings monitored through cutover.
• Payments and tax compliance scopePCI posture, privacy obligations, tax configuration per market, and who owns each.
• Content production and ownershipPhotography, copy, translations; named owner and dates, because this is the launch delay.
• Post-launch retainer and on-callWho fixes checkout at 9 pm on Black Friday, and what that costs per month.

Each one priced, even at zero. An explicit zero is a decision; a missing line is a surprise.

Three worked examples, priced honestly

A specialty food brand launching direct-to-consumer: forty SKUs, single market, standard payments, no legacy data. Right shape: template-plus, a hosted platform with a purchased theme lightly customized, products entered carefully, shipping and taxes configured, email connected. Realistic spend: $2,500 to $4,000 with freelance help, live in three weeks. The expensive mistake available here is the $25,000 custom build a persuasive agency would happily sell; the cheap mistake is skipping product photography, which for food is the store.

An established retailer replatforming: 2,800 SKUs with variants, two markets and currencies, warehouse integration, accounting sync, eight years of URL equity, and 40,000 customer accounts. Right shape: platform store at the serious end. The honest budget: $18,000 to $32,000, of which perhaps a third is migration and redirect engineering that no one will ever see, and that is the point. The tell of a bad proposal at this scope is a beautiful design section and a one-line migration mention; the traffic drop that follows costs more than the entire project.

A B2B industrial supplier with configurable products, per-account contract pricing, approval workflows, and an ERP that is the system of record: the platform demo falls over in the first hour, because the pricing is not a catalog, it is an engine. Right shape: custom storefront over a commerce backend, ERP-integrated. Realistic budget at offshore rates: $80,000 to $140,000 for a first production version, with the pricing engine and ERP integration, not the storefront pixels, consuming most of it. The build anatomy for this shape, layer by layer, is exactly what the platform build guide walks through.

The three examples, side by side

Scenario	Right shape	Honest budget	Where the money actually goes
DTC food brand, 40 SKUs	Template store, done carefully	$2.5k to 4k	Photography and configuration, not code
Retailer replatforming, 2,800 SKUs	Platform store, serious end	$18k to 32k	Migration, redirects, and integrations
B2B supplier, contract pricing, ERP	Custom storefront on commerce engine	$80k to 140k	Pricing engine and ERP seams, not pixels

Getting a quote that survives contact with reality

A real estimate is a function of a real scope, so the fastest way to a trustworthy number is to arrive with the inputs written down: catalog size and structure, with variant logic and a sample of the messiest products; markets, currencies, and payment methods; every system the store must integrate with, named; migration inventory, what data, from where, how dirty; traffic and revenue expectations, because they size infrastructure and testing; and the content plan, with its owner. A one-page scope of this kind converts vendor conversations from mutual guessing into comparable bids, and it typically shortens the sales cycle by weeks.

Then make every bidder expose their assumptions. Two quotes of $15,000 and $38,000 for the same store are not a cheap vendor and an expensive one; they are two different scopes, and the assumptions section is where the difference lives: how many products they assumed clean, how many integrations they priced as configuration versus custom work, whether the redirect map is in or out, what the testing plan covers, and what happens contractually when the catalog turns out messier than represented. The vendor who resists writing assumptions down is telling you, precisely and in advance, where the overage will come from.

Finally, hold ten to twenty percent as a contingency you expect to spend, and stage the commitment where the shape allows it: theme and catalog first, integrations second, optimization after launch data exists. Ecommerce rewards the budget that survives to iterate, because the store that launches is a hypothesis and the first quarter of real orders is the data. The teams that win are rarely the ones that spent the most on day one; they are the ones still funded and still shipping in month six, pruning what the data killed and doubling what it proved. General principles for pricing any web project, and the agency-versus-freelancer-versus-offshore decision, are covered in the website cost guide.

The path to a number you can defend

1. 1

   Write the one-page scope

   Catalog, markets, payments, integrations, migration inventory, traffic expectations, content owner.

2. 2

   Collect bids against the same scope

   Three comparable bids beat six incomparable ones; the scope is what makes them comparable.

3. 3

   Audit the assumptions, not the price

   The delta between quotes lives in what each assumed clean, included, or excluded.

4. 4

   Stage the commitment

   Foundation, then integrations, then optimization on real data; kill criteria at each gate.

5. 5

   Hold contingency you expect to spend

   Ten to twenty percent; the catalog is always messier than represented.

Frequently asked questions

For estimates with the assumptions in writing, AgileTech is a Vietnam software house that builds and replatforms commerce stacks at offshore rates.