Ecommerce website cost in South Africa is build + platform + payments + operations, not one sticker price.

Ask five suppliers what an ecommerce website costs and you will collect five numbers that cannot be stacked against each other, because each one is quoting something different: a theme fee, a freelancer’s day rate, a monthly SaaS plan, or a full build with catalogue work already folded in. None of those numbers, on its own, tells you what it actually takes to open a store and start selling from it.

A number worth planning around covers five layers stacked together: the build itself, the platform it runs on, the payment gateway that actually takes the money, the apps and integrations that make daily operations bearable, and the ongoing work of running the thing once it is live. Miss even one of those layers and a "R12,000 store" quietly turns into a R30,000-a-year commitment nobody actually budgeted for.

Nexus builds Shopify and WooCommerce stores at three entry points, Launch from R7,500, Scale from R11,000 and Pro from R15,000, once-off. Eligible 12-month plans start from R950/month with the full total disclosed upfront. None of that includes the platform subscription or gateway fees, those are billed separately, and this guide tells you exactly what to expect from them.

Product count is a weak way to predict cost, and it fools plenty of first-time buyers. Twenty simple T-shirts in three sizes are an afternoon’s work to configure. Eight products carrying colour, size, bundle and wholesale-tier variants can take longer to set up correctly than a fifty-item catalogue with none of that complexity attached.

Integrations are where quotes actually diverge. Connecting accounting software, an inventory system, a loyalty app, a marketplace feed or custom courier logic each adds real configuration and testing hours, hours a bare theme-install quote never once accounted for.

The most common cause of a delayed launch is rarely design. It is content readiness: missing product photos, vague sizing information, and a returns policy nobody has actually written yet. A developer cannot launch a store around content that does not exist yet, however fast the build itself moves along.

• Catalogue structure, variants, collections, bundles
• Payment methods and local gateway configuration
• Courier rules, free-shipping thresholds, rural delivery exceptions
• Apps for reviews, upsells, subscriptions or on-site search
• Migration effort from a spreadsheet or an existing store
• Staff training and handover documentation

A homeware brand accepts a R9,000 quote for "a Shopify store" from a freelancer who quotes purely off a rough product count. Three weeks in, the brief expands: bundles for gift sets, a wholesale tier for boutique stockists, a courier integration for rural delivery zones, and a loyalty app the founder assumed was standard. None of it was scoped, because none of it was asked about upfront, the freelancer priced a theme install, not a store.

By the time the missing pieces get added one at a time, on top of an already-built structure that was not designed to carry them, the real cost lands closer to R40,000, and the timeline has roughly tripled. Nothing about this was dishonest pricing; it was an incomplete brief meeting an incomplete quote, and the gap between them got paid for in change requests instead of upfront planning.

This is the actual argument for a proper discovery conversation before any number gets quoted, not because a longer process is virtuous, but because catalogue complexity, integrations and fulfilment rules are exactly the variables that turn a R9,000 estimate into a R40,000 reality, and they are all knowable in advance if someone asks.

Shopify’s plans bill monthly in US dollars, so the rand cost moves with the exchange rate, budget a range, not a fixed number carved into your spreadsheet. WooCommerce carries no plan fee of its own, but it shifts that same cost into hosting, a theme licence, essential plugins and, realistically, an ongoing developer relationship to keep security patches current.

Then there is the payment layer, and this is exactly where South African budgets tend to go wrong. Shopify Payments (the processor that lets stores in other markets skip a separate gateway fee entirely) is not available to South African merchant accounts. Every SA Shopify store connects a third-party gateway such as PayFast, Peach Payments or Yoco, pays that gateway’s fee, and then pays Shopify an additional transaction fee on top for not using its own processor. WooCommerce sidesteps that second fee, but it still needs a gateway of its own.

Neither platform gives you payment processing for free. The real difference is where the fee sits and how many layers stack on top of each other, see our dedicated breakdown of Shopify transaction fees in South Africa for the exact bands.

Shopify concentrates most of your recurring cost into one predictable SaaS bill: subscription, apps and the payment fee stack together. It is easy to forecast once you know your volume, and Shopify itself owns the uptime and security of the core platform underneath you.

A merchant migrating an existing catalogue between platforms faces its own separate cost line, worth naming upfront rather than discovering mid-project: product data export and cleanup, redirect mapping so existing SEO value is not lost, historical order data handling, and a testing period before the old store is switched off. Migrations are rarely a simple export-and-import job once real order history and SEO equity are involved.

WooCommerce often shows a lower sticker price at first glance, but that saving simply moves into hosting quality, plugin licences and developer time spent keeping the site secure and working. A "free" WooCommerce store that nobody actively maintains is not cheaper, it is a support bill quietly waiting for the worst possible moment to arrive.

Run both scenarios on your real order volume over 24 months before choosing either one outright. Our full Shopify vs WooCommerce comparison unpacks the maths merchants usually get wrong the first time round.

A store that can process ten orders a day comfortably by hand can quietly become unmanageable at eighty, and the fix at that point is rarely cheap, a rushed integration with a fulfilment partner, emergency staff hires, or a wave of refunds from missed delivery promises. Model your fulfilment capacity against realistic post-launch demand before launch, not after the first good marketing month exposes the gap.

Returns handling deserves the same upfront thought. A published, workable returns policy protects margin and reduces support load; a vague or unrealistic one generates disputes that cost far more in staff time and reputation than the returns themselves.

• Approximate SKU count, with variants and collections roughly mapped
• Payment methods you need to support, card, EFT, buy-now-pay-later
• Courier partners and how complex your shipping rules actually are
• Whether you need wholesale pricing, subscriptions or multi-currency
• The real state of your product data, photos, sizing, copy
• Any apps you already know you will need
• Who, specifically, will update products every week after launch

1. Normalise what is actually includedTheme customisation, number of products uploaded, payment setup, apps, training and the support window, line these up side by side.
2. Add platform and payment costs to every quoteAsk each supplier to state expected monthly platform fees and the payment fee stack, a build-only number is not comparable to one that includes them.
3. Stress-test operations, not just the designWalk through a real test order: stock check, payment, fulfilment, and a refund, on paper if the store is not built yet.
4. Confirm who owns whatDomain, store, apps and customer data should be yours to take elsewhere if the relationship with a supplier ever ends.
5. Ask who fixes what in the first 30 daysBroken apps, failed payments and customer WhatsApp messages need an owner immediately after launch, not eventually.

The cheapest store is the one that sells cleanly at a margin you can sustain, not the one with the lowest number on the invoice.

Nexus ecommerce planning principle

If you are early, finish a product and shipping brief before you ask anyone for a number at all, a vague brief produces a vague quote that will move the moment real scope shows up. If quotes already exist, add platform and payment fees into a 12-month sheet before deciding which one is genuinely "cheaper" than the others.

Nexus can recommend Launch, Scale or Pro on Shopify or WooCommerce once your catalogue and operations picture is clear. Browse the full pricing page for disclosed monthly totals, then talk to us with your real SKU count and payment needs in hand, not a moodboard on its own.