How Australian sellers should pick an online store platform

Decide the requirements before you compare platforms

Nearly every platform comparison starts in the wrong place, with a feature grid and a monthly fee. Platforms are broadly capable of the same things for a straightforward retail catalogue, so a feature grid produces a tie and the decision defaults to whichever one the loudest person has used before. The differences that matter are the awkward parts of your specific business, and they only surface when you write your requirements down properly first.

Write ten to fifteen requirements, in your own words, and mark the ones that are genuinely non negotiable. Not a wish list. The things that, if the platform cannot do them cleanly, make it the wrong choice. For Australian sellers those usually cluster around the same few areas: how complex the catalogue really is, whether trade customers need different prices, what has to flow into MYOB or Xero, how freight is calculated across a very large country, and how much of the checkout you need to control.

• How many SKUs, and how many option combinations per product
• Do different customers see different prices, and how are those groups determined
• What must synchronise with accounting, inventory or an ERP, and in which direction
• How freight is quoted: flat, table based by weight and zone, or live from a carrier
• Whether GST inclusive and exclusive display are both required
• Who maintains the site day-to-day, and what they are comfortable doing

The four realistic options, compared

For Australian sellers the practical shortlist is short. Hosted Shopify, self-hosted WooCommerce on WordPress, hosted BigCommerce, or a custom or headless build. Everything else tends to be a variation on one of those trade offs. The table below compares them on what actually differs rather than on feature counts, which are broadly similar at the level most businesses operate.

• Shopify is the default for a reason: fast to launch, reliable, and it removes hosting and patching from your worry list. The trade is that when you hit a platform boundary, you work around it or upgrade
• WooCommerce gives full control of code, checkout and data, at the price of owning hosting, updates, performance and security. It shines when content and commerce live together
• Custom or headless is right when your commercial rules are the product, and wrong when it is chosen for status rather than necessity

	Shopify	WooCommerce	BigCommerce	Custom or headless
Best fit	Retail catalogues, fast launch, small teams	Content led sites, WordPress skills in-house	Large catalogues and B2B price lists	Unusual commercial rules or deep system integration
Catalogue and variants	Strong, with option limits worth checking for configurable products	Very flexible, and needs care to stay fast at scale	Strong, with generous option handling	Whatever you model
B2B pricing	Available on higher tiers or via apps	Via plugins, quality varies	Price lists and customer groups built in	Native to your data model
Checkout control	Limited outside enterprise tiers	Full control	Moderate	Full control
Hosting and maintenance	Included	Yours to manage and patch	Included	Yours, or managed
Integration approach	App ecosystem, then custom apps	Plugins, then custom code	Apps and a capable API	Direct to your systems
Where the cost lands	Apps, transaction terms and tier upgrades	Plugin licences, hosting, developer time, maintenance	Tier thresholds tied to sales volume	Build and ongoing engineering
Main risk	Hitting a platform limit you cannot work around	Plugin sprawl and performance decay	Smaller ecosystem for niche needs	Cost and time, and dependence on the build team

Catalogue complexity is the first fork in the road

The number of SKUs matters far less than the shape of them. Two thousand simple products are easy for every platform on the list. Two hundred products with six options each, where the combinations create thousands of variants, are hard for some of them, and that is where platform choice is actually made. Multiply out your option combinations before you shortlist anything, because most hosted platforms impose limits on options and variant combinations per product, and those limits change over time and by plan. Check the current position for the plan you would actually buy rather than relying on a blog post.

Made to order and configured products are the sharpest version of this. If a customer chooses a length, a material, a finish and a fixing type, and the price is calculated from those choices rather than looked up from a list, you are describing a configurator rather than a variant matrix. Some platforms accommodate that through apps with real limitations, and some cases need custom work. Manufacturers and trade suppliers hit this constantly, and it is the most common reason an otherwise sensible ecommerce project outgrows a hosted platform.

• Separate true variants from configurations where price is calculated rather than listed
• Decide where product data lives long term, because the platform should consume it rather than own it

B2B pricing, accounts and trading terms

A large share of Australian online sellers are not pure retail. They sell to trade, to dealers, to schools or to government alongside the public, and the moment that is true the requirement list changes in ways a retail focused demonstration will never reveal. The core requirement is that different customers see different prices. That can mean percentage discounts by group, fixed price lists per account, quantity break pricing, contract pricing negotiated per customer, or hidden pricing until login. Then come the account behaviours: multiple users under one trading account with different permissions, purchase order numbers captured at checkout, quote requests instead of immediate payment, ordering on account with terms rather than by card, credit limits, and reordering from a previous order or a saved list. Add tax display switching, because trade buyers expect to see prices excluding GST while consumers must be shown a GST inclusive total.

BigCommerce handles much of this natively. Shopify covers it on its higher tiers or through apps, with the usual caveat that stitching several apps together creates a maintenance surface. WooCommerce can do all of it with plugins, and the quality varies considerably. If trade is a material share of revenue, it is often better to treat the trade experience as its own project, sometimes as a customer portal or a dealer portal sitting alongside the retail storefront, rather than forcing one interface to serve two very different buyers.

MYOB and Xero: where the integration actually breaks

Agree the accounting model with your accountant before choosing any connector. The first question is whether each order becomes an individual invoice in MYOB or Xero, or whether sales are posted as a daily or weekly summary. Individual invoices are useful when customers need them and terrible when you process thousands of small orders, because the accounting file becomes unmanageable and API limits become a real constraint. Xero applies per minute and per day API call limits, so a high volume store pushing every order individually can hit them, and syncs then queue or fail silently.

Then work through the details that always cause reconciliation pain. Payment provider fees are an expense, not a discount, and if the connector nets them off, the payout will never reconcile cleanly against the bank feed. Refunds and partial refunds need to create credit notes correctly. Multi currency, if you sell overseas, needs a defined rate treatment. Inventory is the biggest decision: whether stock is tracked in the accounting system, in the store, or in a separate inventory system that both read from. Pick one master. Two systems both believing they own stock levels is the most reliable way to oversell.

• Establish a single master for stock, and make everything else a reader
• Check API call limits against your order volume, and how the connector behaves when a sync fails
• For complex flows, a purpose built integration is often more reliable than three chained connectors

GST, pricing display and tax invoices

GST is a solved problem on every platform on the shortlist, but it needs configuring correctly at the start, because changing pricing display conventions on a live catalogue is a genuinely painful exercise. Australian consumers must be shown a single total price that includes GST, displayed prominently, so a consumer facing storefront should enter and display prices inclusive of tax.

The complication is mixed audiences. If you sell to both consumers and trade, you need inclusive display for the public and exclusive display for logged in trade customers, ideally without maintaining two price lists. Platforms differ a lot here and the difference is rarely visible in a sales demonstration. Test it with a real trade account during evaluation. It is a common cause of an expensive rebuild eighteen months later.

Freight rules platforms handle badly

Shipping is where Australian requirements diverge most from the assumptions baked into platforms built for other markets. The country is enormous, the population is concentrated in a handful of cities, and carriers price accordingly with zone based rates, remote area surcharges and cubic weight calculations. Cubic weight is the one that catches people out: carriers charge on the greater of actual weight and volumetric weight, so a light but bulky item is priced as though it were far heavier.

Out of the box, most platforms handle flat rates and simple weight based tables well, and struggle with anything beyond that. The rules that cause trouble are the ones real businesses need: different rules for oversized items, splitting an order across multiple parcels or multiple despatch locations, excluding remote postcodes from free shipping, dangerous goods restrictions for batteries or aerosols, freight on quote for large items, and click and collect from selected locations. Each of these is achievable somewhere, usually through an app, a plugin or custom logic, and each one should be tested with your own products rather than assumed.

• Test the checkout with real remote postcodes across WA, NT, TAS and regional QLD, not just capital cities
• Confirm multi parcel and split despatch handling if you ship from more than one location
• Store despatch dimensions and weight against every SKU as a standing data requirement

Total cost of change, not licence fees

The monthly licence fee is usually the least significant number in a five year view, and fixating on it leads businesses to platforms that cost far more in the aggregate. Compare the total cost of change instead: everything you will spend to get onto the platform, everything to run it, and everything it would cost to leave.

That last category is the one nobody costs and everybody eventually pays. Reduce it by keeping product data outside the platform where you can, by using documented APIs rather than embedding logic in theme code, by owning your accounts and your domain, and by keeping content structured rather than trapped in page builder markup. A platform is a five to eight year decision for most businesses, and building for a future exit is not pessimism, it is what makes the exit affordable when it comes.

• Build: design, development, data migration, integrations, content, training, internal time
• Run: licence, apps and plugins, hosting, transaction costs, maintenance, security, ongoing changes
• Leave: replatforming, redirect mapping, integration rebuilds, retraining, temporary traffic disruption
• Risk: the cost of a limit you discover in year two, and what the workaround will cost annually

How to run the decision in two weeks

This choice does not need three months of evaluation, and long evaluations rarely produce better answers than short structured ones. Two focused weeks with the right people and real data will get you to a defensible decision, provided you test with your own edge cases rather than sitting through demonstrations of somebody else's catalogue.

• If both shortlisted platforms pass the proof of concept, pick the one your team can operate without help
• Do the migration planning before committing, because the redirect and data migration effort is part of the cost of the decision

1. Days 1 to 2: write the requirements with the people who run the business daily, and mark the genuine non negotiables
2. Day 3: quantify the catalogue. Real SKU count, real variant combinations, configurable products, bundles and attribute filtering needs
3. Day 4: define the integration map. Which systems, which direction, how often, and who owns the master record for each entity
4. Day 5: agree the accounting model with your accountant, including invoice versus summary posting and stock ownership
5. Days 6 to 7: shortlist two platforms, no more, and get access to a trial of each
6. Days 8 to 10: build a proof of concept on both with twenty of your genuinely awkward products, your freight rules and a test trade account
7. Day 11: test the accounting connector with real order scenarios including a refund, a partial shipment and a trade order on account
8. Day 12: cost all three buckets over five years: build, run and leave
9. Days 13 to 14: decide, write down why, and record which assumptions would change the answer so the decision can be revisited on evidence