Wix, BigCommerce, PrestaShop & WordPress: Platform Store Creation Compared

Choosing an ecommerce platform is rarely a purely technical decision—it is an operational constraint you adopt for years. I recently dealt with a client who had built a supposedly straightforward apparel store on Wix. Within 24 months, their product catalogue expanded to include complex sizing and colour matrixes. Wix’s hard limits on product variants forced them to split single items into multiple listings, destroying their internal reporting and confusing their customers. The inevitable migration off Wix to WooCommerce ended up costing them three months of intensive data mapping and significantly more capital than doing it right the first time.

Every platform makes promises about scalability and ease of use. But as an engineer, the reality is dictated by API access, database schemas, and architectural limits. In this deep dive, I am breaking down the technical realities of starting a store on Wix, BigCommerce, PrestaShop, and WordPress (WooCommerce). We will look past the marketing material and examine how these platforms handle the actual engineering requirements of modern ecommerce.

1. Wix eCommerce: The Closed Walled Garden

Wix is a website builder that bolted on ecommerce functionality. From a developer’s perspective, it is a completely managed, proprietary ecosystem where convenience is heavily traded against control. You are paying to not have to think about infrastructure.

1.1. Account Setup and Plan Structure

To run a functional store on Wix, you must subscribe to a Business & eCommerce plan (typically Core, Business, or Business Elite). Lower tiers technically allow product creation but restrict crucial checkout or payment gateway features. Account setup takes mere minutes, reflecting their target demographic of non-technical founders. However, the first red flag for systems integrators appears immediately: you have absolutely no FTP, SSH, or direct database access. Your entire interaction with the platform occurs through their web UI or their Velo (formerly Corvid) JavaScript API.

1.2. Catalogue and Product Management

Wix supports physical, digital, and service products natively. The UI is clean, but the underlying data structures are rigid. The most critical limitation—and the one that forced my client to migrate—is the variant limit. As of writing, Wix limits you to 6 product options (e.g., size, colour, material) and up to 1,000 total variants per product. While 1,000 sounds sufficient for a t-shirt, complex customisable products or wholesale catalogues hit this ceiling very quickly. You cannot inject custom database fields directly; you are reliant on Velo data collections, which operate asynchronously from the core catalogue logic in ways that can cause race conditions during checkout.

1.3. Payment, Tax, and Shipping Abstractions

Wix strongly pushes Wix Payments, their white-labelled Stripe integration. Manual payment methods (cash on delivery, bank transfer) are supported. If Wix Payments is unavailable in your region, you can connect third-party gateways via Wix Pay, but your options are strictly limited to their pre-approved partner list. You cannot build a custom payment gateway integration.

Tax configuration relies on a native integration with Avalara for automated calculations (available on higher tiers) or manual rule setup. Shipping setup handles flat rates, weight-based calculations, and USPS integrations natively, but complex logic (like restricted shipping zones based on multi-vendor combinations) is nearly impossible to implement cleanly.

1.4. Limitations and Architectural Constraints

Wix is built on a black-box microservices architecture that you cannot touch. Checkout customisation is locked down—you cannot modify the DOM of the checkout page, preventing custom analytics implementations or bespoke field injections without relying on approved apps. There is no server-side execution environment for PHP/Python/Node.js to handle complex background tasks; you are limited to Velo’s server-side functions, which have strict execution time limits.

2. BigCommerce: The API-First SaaS

BigCommerce represents the mid-market SaaS alternative. Unlike Wix, which hides its complexity, BigCommerce exposes a highly mature API surface while maintaining a managed infrastructure. It is architected for serious transactional volume.

2.1. Store Setup and Theming

The onboarding wizard provisions a store instantly. The default frontend is powered by the Cornerstone theme, which utilises the Stencil CLI framework. Stencil allows developers to pull the theme locally, run a Node.js-based local server synced to live store data, and push compiled assets via an API. Alternatively, BigCommerce natively supports headless architecture, allowing you to use Next.js or Vue.js via their Storefront API while BigCommerce handles the backend.

2.2. Complex Catalogue Management

BigCommerce’s catalogue is where it justifies its enterprise pricing. It handles products, complex category trees, up to 250 options, and 600 variants per product natively. More importantly, it supports custom fields directly on the product model and product rules that conditionally alter price, weight, or image based on selected options. This schema is robust enough for B2B catalogues without requiring extensive custom development.

2.3. Payments, Tax, and Logistics

Crucially, BigCommerce charges zero additional transaction fees regardless of which payment gateway you use (Stripe, PayPal, Square, Braintree are built-in). This is a massive cost advantage over Shopify at scale.

Tax is handled via a native Avalara integration or TaxJar, alongside manual rules. Shipping is incredibly robust through a native integration with ShipperHQ, allowing for real-time carrier quotes, dimension-based packing algorithms, and complex per-zone rate mapping.

2.4. BigCommerce API Architecture

BigCommerce provides both a REST Management API and a GraphQL Storefront API. The Management API is subject to rate limits based on your plan tier but provides granular access to orders, products, and customers. The GraphQL API allows for lightning-fast headless implementations.

3. PrestaShop: The Open Source PHP Monolith

PrestaShop is a traditional, self-hosted PHP monolith. It is massively popular in European markets due to excellent multi-language and complex tax compliance features out of the box, but it requires serious system administration skills to maintain.

3.1. Server Requirements and Infrastructure

PrestaShop 8.x requires a specific environment. You need PHP 8.1 (support for 8.2 is improving, but 8.1 is safer for module compatibility), MySQL 5.7+ or MariaDB, and either Apache or Nginx. It relies heavily on mod_rewrite (or Nginx equivalents) for friendly URLs. If you misconfigure the PHP memory limit (needs minimum 256MB) or max_input_vars (needs minimum 5000), you will face silent failures when saving large product catalogues.

3.2. Installation and Nginx Configuration

Installation involves downloading the archive, extracting it to your web root, creating a database, and running the web-based install wizard. Crucially, post-installation, you must physically delete the /install directory from the server for security reasons. PrestaShop writes its configuration to app/config/parameters.php.

If you are running Nginx, PrestaShop does not generate an .htaccess equivalent automatically. You must configure Nginx manually to handle the front controller pattern. A standard block looks like this:

3.3. Shop Configuration and Modules

PrestaShop’s native configuration handles currency, multi-language, and highly specific tax rules (e.g., eco-taxes, specific European VAT rates) incredibly well. Functionality is extended via modules, which can be installed from the Addons Marketplace or uploaded manually as ZIP files. Note that module quality varies wildly, and bad modules are the leading cause of performance degradation in PrestaShop instances.

4. WordPress + WooCommerce: The Extensible Ecosystem

WooCommerce is technically a plugin for WordPress, but in practice, it transforms WordPress into a fully-fledged ecommerce framework. It offers total control, massive extensibility, and significant technical debt if managed poorly.

4.1. Automated Installation via wp-cli

While you can install WordPress via FTP, professionals use wp-cli. Here is a runnable bash script to install WordPress and WooCommerce on an Ubuntu 22.04 server (assuming MySQL and PHP 8.2 are already configured):

4.2. Configuration and Essential Stack

Once installed, the WooCommerce setup wizard guides you through basic store settings. You configure simple, grouped, or variable products. Payment integration is typically handled via WooCommerce Payments (powered by Stripe) or dedicated plugins for PayPal, Authorize.net, etc.

Running WooCommerce in production requires a mandatory stack of supporting plugins. You need Yoast SEO (or RankMath) for meta data, a caching solution like WP Rocket or LiteSpeed Cache, and a security firewall like Wordfence. Out of the box, WooCommerce is highly unoptimised for scale.

4.3. Performance and Database Realities

Performance optimization for WooCommerce is an ongoing battle. You must have a server running PHP 8.2, OPcache enabled, and crucially, an object cache like Redis or Memcached. Without object caching, WooCommerce queries the database mercilessly for post meta data on every page load.

The WordPress database schema (specifically the wp_posts and wp_postmeta tables) was designed for blogging, not complex product variant relational data. High Order Volume (HPOS - High-Performance Order Storage) was recently introduced by WooCommerce to move orders out of the postmeta tables into dedicated tables, which significantly improves backend database performance, but you must ensure all your plugins are HPOS compatible.

5. Platform Comparison Data

This table outlines the hard technical constraints and architectural realities of each platform.

6. The Honest Trade-Off: When NOT To Use These Platforms

As systems engineers, we must acknowledge that no platform is a silver bullet. Here is when you should actively avoid these options:

• When NOT to use Wix: Never use Wix if your product catalogue requires complex conditional logic (e.g., selling car parts with year/make/model fitment), if you need to integrate a custom ERP via flat file FTP, or if you expect to process over 500 orders a day. The closed ecosystem will throttle your operations.
• When NOT to use BigCommerce: Avoid BigCommerce if you have a minuscule budget, or if you require extreme, low-level modifications to the checkout flow that their checkout SDK cannot support. If you need complete data sovereignty (e.g., hosting data on specific local government servers), a SaaS product is disqualified immediately.
• When NOT to use PrestaShop: Do not use PrestaShop if you do not have access to a dedicated PHP developer or a managed hosting team. The upgrade paths between major versions are notoriously difficult, and relying on cheap marketplace modules will result in a slow, insecure store.
• When NOT to use WooCommerce: Do not use WooCommerce if you have a massive catalogue (100,000+ SKUs) and are unwilling to invest heavily in premium infrastructure (dedicated databases, Redis clusters). Out-of-the-box WooCommerce on shared hosting will collapse under the weight of a large catalogue.