⚡ Quick answer: Store pricing depends first on how many products you’re selling, not on “make it look nice.” Under 100 products runs from $700, 100-1,000 products runs $1,200-1,800, and past 1,000 products runs $2,800-3,800. That’s development only — domain, product-page content, and initial SEO setup are separate line items almost everyone forgets to budget for until it’s too late.
“How much does an online store cost” is really a different question in disguise: how many products will you actually be selling a year from now, not just at launch.
That’s where we start — not with design.
In early conversations with clients, the catalog question is almost always harder to answer than it looks: a business owner knows exactly how many products they sell today, but rarely has a firm number for a year out if the range grows or a new supplier gets added. That’s normal — but it’s exactly why the site’s structure needs built-in flexibility from day one, instead of betting on guessing the exact number in advance.
| Catalog size | Price | Timeline | What’s included |
|---|---|---|---|
| Under 100 products | from $700 | 21-30 days | Basic filters, product cards, cart, online payment, shipping carrier integration |
| 100-1,000 products | $1,200-1,800 | 35-50 days | Advanced filters, customer accounts, loyalty program, CRM, custom design, base SEO |
| 1,000+ products | $2,800-3,800 | 80+ days | Complex database architecture, automated inventory sync, tiered pricing, SEO-structured catalog |
Tellingly, the $1,200-1,800 range for a mid-sized catalog is exactly where Netloria operates: a store built to actually grow with the business, not one that gets rebuilt from scratch after the first hundred products. The gap between the low and high end of that range is almost always the difference between a templated design and a fully custom one — not between a “good” vendor and a “bad” one: both are technically functional, one just adapts an existing structure to your brand while the other builds the layout from zero around your specific catalog and how buyers in that niche actually search for products.
In our own work, most traffic to a new online store now comes from mobile, not desktop — and that needs to shape the design from day one, not get bolted onto an already-finished desktop layout afterward. A store built mobile-first typically ends up with simpler filters, bigger buttons, and a shorter path to checkout — and those are exactly the details that cost more to retrofit later than to plan for from the start.
| Line item | Estimated cost | Required? |
|---|---|---|
| Hosting and domain | $30-120/year | Yes |
| Product-card content (photos, descriptions) | from $250 | Yes |
| Initial SEO setup | $250-700 | Recommended |
| Launch-month advertising | $250-700 | Recommended |
A store with no product-card content and no initial advertising is technically a finished website that nobody visits yet.
Which is why the launch budget shouldn’t be “development plus a little buffer” — it should be development plus at least one full line item for content and another for initial traffic. Otherwise a finished store can sit idle for months without a single order, simply because nobody knows it exists yet and the product cards look empty without photos or descriptions.
Domain and hosting are the smallest of the four line items, but they’re the one most often left out of the first invoice entirely, since they look like a rounding error next to development costs running into the thousands.
Catalog size sets the baseline cost, but integrations are what usually push the price toward the top of the range. Connecting several shipping carriers at once costs more than connecting one. Integrating with an accounting system or ERP for automated inventory sync is a genuine chunk of work, not “just a plugin” — especially if that accounting system already handles offline sales and data needs to sync in both directions. Multi-currency support or listing on marketplaces like Amazon or Etsy gets quoted separately too, since each one needs its own data feed.
Practical tip: before requesting a quote, write down not the number of products but the list of integrations you’ll genuinely need in the first six months — that, far more than design, is usually what explains the price gap between quotes for what looks on paper like the same store.
Before picking a vendor, it’s worth sketching out category and filter structure yourself — which product attributes buyers actually search by (size, color, brand, price range), not which ones seem logical to whoever manages the catalog. Restructuring categories at 50 products is a few hours of work. Restructuring them at a thousand products, once items are scattered across the wrong sections and buyers are used to the old links, is a project comparable in scope to part of the original build.
The alternative to a custom build is a hosted platform like Shopify or BigCommerce, from roughly $30-40/month. It looks cheaper at first, but three years of subscription adds up to around $1,000-1,500 — close to the cost of a custom WooCommerce build, minus the ongoing feature limits.
We covered this exact logic — renting versus owning your site — in more depth in WordPress vs Tilda vs Wix. The same principle applies to a store, just at higher stakes: migrating a catalog of hundreds of products off a hosted platform onto your own site is no longer a matter of a few hours.
There’s a detail people rarely factor in when comparing the two: on a SaaS platform, you’re renting more than just functionality — you’re renting someone else’s architectural limits. If two years in you need non-standard logic — say, custom pricing for wholesale clients or a tiered volume-discount system — on a WooCommerce build that’s a question of a plugin or custom code. On a closed platform, it’s a question of “is this even possible,” and the answer depends on the platform’s own product roadmap, not on you.
The most common online payment options are Stripe, PayPal, and direct processing through your bank. Each carries its own transaction fee (typically 2-3% depending on volume and terms) and its own setup process, worth starting in parallel with development rather than after — business verification with a payment provider often takes longer than the actual code integration. This is exactly where an earlier platform choice matters: as noted above, some closed-platform builders restrict which payment processors you can connect, so it’s worth checking compatibility before the product catalog even starts getting populated.
Shipping is the second half of the same equation. Carrier API integration lets a buyer see shipping cost and timeline right in the cart, instead of finding out only after placing the order — and that, more than any “buy now” button design, is usually what determines whether a buyer actually completes checkout.
The most common thing we see: budgets get built around the current product count, not the one a year out. A store with 80 products, built for the “under 100” tier, can technically hold 500 — but without expanded filters and an optimized catalog structure, buyers simply won’t find what they’re looking for among hundreds of listings, and catalog growth turns into a conversion drop instead of a sales increase.
Budget for the catalog you’ll have in a year, not the one you have today.
The second common mistake is expecting a finished store to start selling on its own the moment it launches. A technically working site and a site that actually converts a visitor into a buyer are two different stages: the first is the result of development, the second is the result of ongoing work on product cards, site speed, checkout clarity, and trust signals (reviews, return policies, clear shipping terms). In our own work, it’s usually these post-launch “details” that move conversion more than any further investment in the build itself.
Development doesn’t end on launch day — the first few weeks almost always surface small technical quirks: a product variant displaying incorrectly, a shipping calculation error for a specific region, a bug in the order confirmation email. Before signing anything, get a clear answer on how long after handoff these kinds of fixes are covered for free, versus what counts as new work billed separately. A vendor who won’t draw that line clearly upfront is itself a signal worth paying attention to before you commit.
If you’re still weighing whether you need a full store or something simpler would do — take a look at our online store development terms, and we’ll price it out against your actual product count and the integrations you specifically need.
