The Real Reason You’re Looking for a Shopify Alternative
The $39/month Basic plan isn’t actually your problem. The problem is what happens three weeks after launch when you realize abandoned cart emails require an app ($29/month), your blog posts have no meta description control without another app ($15/month), and you can’t add a gift message field to checkout without upgrading to Shopify Plus (starts at $2,300/month, not a typo). I’ve watched founders burn through $150/month in app subscriptions on a store grossing $800/month. The unit economics are just broken at that stage.
Then there’s the transaction fee trap. If you’re not using Shopify Payments β and you can’t if you’re in one of the 20+ countries where it’s unavailable, or if you want to use Stripe with a custom setup β you’re paying 2% on every order on top of payment processor fees. On a $50 order, that’s $1 gone before you’ve accounted for cost of goods, shipping, or ads. At $1,500/month revenue that’s $30 disappearing into Shopify’s pocket monthly just for the privilege of using a different payment gateway.
None of this is Shopify being predatory β it’s a genuinely solid product and the right call once your store is doing $5k+ a month and your time is worth protecting. But below $2k/month, you need to be ruthless about fixed costs, and $39 base plus apps is not ruthless. That threshold is also roughly where you can afford to absorb the operational overhead of a self-hosted alternative, so the crossover point matters both ways.
Before we go further, let’s be precise about what “free” means in each category, because the word does a lot of heavy lifting:
- Open-source / self-hosted (WooCommerce, Medusa.js, PrestaShop): Zero license fee. You will pay for hosting β a decent VPS on Hetzner runs around β¬4-6/month, DigitalOcean droplets start at $6/month. You also pay with your time for setup, updates, and anything that breaks at 2am.
- Freemium hosted platforms (Ecwid, Wix eCommerce, Square Online): There’s a real free tier, but it comes with actual constraints β usually a product count cap, no custom domain, or a platform badge on your storefront. The limits aren’t hidden, but they’re not front-and-center either, so I’ll call them out specifically for each one.
- Open-source with cloud option (Medusa.js): Code is free, self-hosting is free, but their managed cloud has its own pricing. This hybrid model trips people up constantly.
The thing that caught me off guard the first time I moved a client off Shopify to a self-hosted stack was how fast “free” turns into “I need to hire someone.” WooCommerce itself costs nothing. Wrangling PHP memory limits, configuring caching layers, and debugging plugin conflicts after a WordPress core update? That’s either your weekend or a developer’s invoice. Factor that in honestly before you commit to the self-hosted path β it’s the right call for some teams and the wrong call for others, and I’ll tell you which is which for each tool below.
For a broader view of what’s worth paying for once your store actually has revenue and you’re ready to invest in tooling, check out our guide on Essential SaaS Tools for Small Business in 2026 β it covers the stack decisions that make sense post-traction rather than pre-revenue.
The Contenders I Actually Deployed
The Square Online free tier is the only option here where “free” means what you think it means β no credit card, no trial countdown, no “free until you actually use it.” You get a real storefront, inventory management, and payment processing (2.9% + 30Β’ per transaction, same as their paid tiers). The catch: every page has a “Powered by Square” badge and you’re stuck on a squareonline.com subdomain unless you pay $12/month for a custom domain. For a client who needed something live in 48 hours and wasn’t ready to commit to infrastructure, this was the right call. I wouldn’t use it for anyone who cares about SEO long-term, because you have zero control over the URL structure.
WooCommerce on Shared Hosting β The $6/Month Classic
I’ve set this up more times than I can count. Grab a Hostinger Business plan (~$6/month when they’re not running a sale, closer to $3 during promos), point your domain, and run through the WordPress 5-minute install. WooCommerce itself is free. What trips people up is that “free” WooCommerce doesn’t include payment gateways beyond PayPal and a basic bank transfer. Stripe requires the free WooCommerce Stripe plugin, which works fine, but you’re immediately in plugin dependency territory. The thing that caught me off guard the first time: WooCommerce stores a lot of session data in wp_options, and on shared hosting with a default MySQL config, you’ll start seeing slowdowns around 500 orders if nobody’s running wp_options cleanup. Install WP-Sweep or add this to your cron:
DELETE FROM wp_options WHERE option_name LIKE '_wc_session_%' AND option_value NOT LIKE '%"session_expiry"%';
Use WooCommerce when your client already knows WordPress, needs a huge extension ecosystem, and isn’t expecting more than a few hundred concurrent visitors on shared hosting. Don’t use it when you need a clean API-first architecture β WordPress’s REST API works, but it’s bolted on, not designed in.
PrestaShop 8.x on a $5 DigitalOcean Droplet
This one surprised me. PrestaShop gets dismissed a lot in English-speaking dev communities, but version 8.x is genuinely solid β the codebase cleanup they did between 1.7 and 8 was real. I spun up a $5/month DO droplet (1GB RAM, 25GB SSD, Ubuntu 22.04), installed LAMP, and had PrestaShop running in about 40 minutes. Here’s the part nobody tells you: PrestaShop’s default PHP configuration will cause the installer to fail silently on some DO images because of the fileinfo extension. Run this before you start:
Stop Using Netlifyβs Git Integration β Hereβs How to Wire Up GitHub Actions Instead
sudo apt install php8.1-fpm php8.1-mysql php8.1-curl php8.1-gd php8.1-intl php8.1-mbstring php8.1-xml php8.1-zip php8.1-fileinfo
sudo systemctl restart apache2
The native multi-currency and multi-language support is better out-of-the-box than WooCommerce with plugins. If your client sells internationally, this matters immediately. The admin UI feels dated compared to Shopify, but it’s functional. Where PrestaShop hurts: the module marketplace is expensive (β¬50-β¬150 per module is normal), and free modules are often abandoned. Budget for maybe one paid module if you need anything beyond the basics.
Medusa.js β For the One Client Who Wanted Headless
I had exactly one project where this made sense: a client with a custom React frontend who needed commerce logic without the CMS baggage. Medusa is a Node.js commerce engine β you get a REST API, an admin dashboard, and a PostgreSQL-backed data layer. Setup is straightforward if you’re comfortable with Node:
npx create-medusa-app@latest my-store
cd my-store
cd backend && medusa seed
The honest trade-off: Medusa is fast and the API design is clean, but the docs have gaps. Payment plugin documentation in particular assumes you already know how their subscriber/event system works, which you won’t on day one. I spent half a day debugging a Stripe webhook issue that turned out to be a missing STORE_CORS env variable that wasn’t mentioned in the quickstart. Also β Medusa needs at minimum a $12/month droplet (2GB RAM) to run comfortably. On 1GB, the build process will OOM kill you. Don’t use this for a client who needs to update their own product catalog without a developer in the room; the admin UI is functional but not something you hand to a non-technical owner and walk away from.
What I Ruled Out and Why
- OpenCart: I checked the GitHub repo before recommending it and the commit history told me everything I needed to know. Meaningful feature work has basically stalled. Security patches trickle in, but you’re betting on a platform that feels like it’s in maintenance mode. For a new store launch in 2024, that’s a bad foundation.
- Wix eCommerce: The free tier blocks payment processing entirely. You cannot accept money on the free plan. “Free eCommerce” is a marketing statement, not a technical reality. Once you add payments, you’re at $17-$35/month, at which point you’re paying Shopify money for worse developer tooling.
- BigCartel: Five products on the free tier. Five. If your client is selling exactly five things forever, sure. Otherwise you’re looking at $9.99/month for 50 products, which is fine pricing, but then you’re not in the “free” conversation anymore. BigCartel is genuinely nice software for artists selling a small catalog β just be honest about what “free” gets you before you recommend it.
WooCommerce: Still the Default Answer for a Reason
The thing that caught me off guard the first time I set up WooCommerce on a VPS β not a managed host β was how manual the process actually is. Bluehost and SiteGround users get a one-click install button that handles WordPress, WooCommerce, and a starter theme in one shot. On a VPS, you’re doing this yourself:
wp core install --url=yourdomain.com --title="My Store" --admin_user=admin [email protected]
wp plugin install woocommerce --activate
wp theme install storefront --activate
That’s not a complaint β it’s a heads up. If you’re comfortable with wp-cli, this whole stack takes maybe 20 minutes. If you’re not, factor in the learning curve before you commit. The good news is the Storefront theme (free, made by WooCommerce’s own team) looks genuinely clean out of the box. I’ve seen developers spend $60 on a premium theme on day one when Storefront with a custom logo and some color tweaks would have shipped faster and performed better.
The free tier is actually quite generous β until payment methods get complicated. WooCommerce Payments (the official free plugin, powered by Stripe) handles card payments with no monthly fee, just the standard transaction percentage. That’s your happy path. But the moment a customer says “can I pay with PayPal?” or you need a local payment gateway like Klarna or Afterpay, you’re looking at individual extensions that each run $79β$129/year. Stack three of those and you’ve just built a $300/year recurring cost that doesn’t show up in any “free alternative” listicle.
The tax setup is where I’ve watched three separate people get burned. The setup wizard asks if you want to calculate taxes and you click yes. What it doesn’t tell you clearly is that wp option update woocommerce_calc_taxes yes just flips a boolean β it doesn’t configure any actual rates. You still need to go into WooCommerce β Settings β Tax and add your rate tables manually, or install a plugin like TaxJar or Avalara (both paid). Selling in the US across multiple states without this configured correctly is a compliance problem, not just a UX annoyance. Don’t let the wizard’s cheerful progress bar convince you you’re done when you’re not.
Performance deserves a real warning. A default WordPress + WooCommerce installation on shared hosting runs fine. Add Elementor for page building, a slider plugin, a review plugin, and a live chat widget β which is exactly what most first-time store owners do β and you’re looking at 3β4 second load times without caching in place. This isn’t hypothetical; load up GTmetrix on a stock WooCommerce/Elementor shared host build and watch the waterfall. W3 Total Cache or LiteSpeed Cache (if your host runs LiteSpeed, which SiteGround and many others do) is not optional at that point, it’s the fix. Configure page caching, object caching if you have Redis available, and exclude the cart and checkout pages from the cache β those need to stay dynamic.
Use WooCommerce if you’re already running a WordPress content site and want to bolt on a store, or if you know you’ll need a deep plugin ecosystem (subscriptions via WooCommerce Subscriptions, bookings, memberships, bundles β it’s all there). Don’t use it if your entire business is the store with no content angle, because then you’re carrying WordPress’s full overhead for no benefit. Also don’t use it expecting zero ongoing cost β budget for at least one or two paid extensions within the first six months. The core is free; the real-world configuration rarely stays that way.
PrestaShop 8.x: More Powerful Than It Gets Credit For
PrestaShop gets dismissed a lot by developers who tried it five years ago and moved on. That’s a mistake. Version 8.x is genuinely solid e-commerce infrastructure, and for a specific class of store β larger catalogs, B2B buyers, EU VAT complexity β it runs circles around WooCommerce out of the box.
Getting It Running on Ubuntu 22.04
Spin up a droplet (2GB RAM minimum, 4GB if you’re serious), then install PHP dependencies before you touch the PrestaShop installer:
sudo apt update
sudo apt install php8.1 php8.1-mysql php8.1-zip php8.1-gd php8.1-curl php8.1-intl php8.1-mbstring
The thing that caught me off guard: if you skip php8.1-gd or php8.1-curl, the web installer will either stall silently or complete with broken image handling and no HTTP client. No loud error, just a half-broken store. The installer’s dependency check will show warnings, but it’s easy to blow past them. Don’t. Also throw in php8.1-intl now β you’ll need it for locale handling and you don’t want to debug missing translations after you’ve already configured the store.
After install, forget looking for a .env file. PrestaShop doesn’t work like a modern Symfony app even though it’s technically built on Symfony components. Database credentials live in app/config/parameters.php, and that’s also where you’ll adjust _PS_MODE_DEV_ when something breaks and you need real error output instead of the generic white screen. Set it to true during setup, then flip it back before you go live.
Where PrestaShop Actually Beats WooCommerce
Layered navigation (faceted search) is the big one. WooCommerce’s filtering is either slow or expensive β you’re adding a plugin, potentially a third-party search service, and hoping it indexes fast enough. PrestaShop’s layered navigation is native, indexed directly against your product attributes, and stays responsive at catalog sizes where WooCommerce starts choking. Multi-currency is also native, not bolted on. You define currencies, set exchange rate update rules, and it propagates across the catalog automatically. For an EU-based store launching with EUR, GBP, and CHF on day one, that’s hours of setup time saved. The B2B features β customer groups with custom pricing tiers, quote request workflows β are included free and actually work without premium plugins.
The Honest Problems
The back-office UI looks like something built for Internet Explorer 11. It works β everything is where you expect it, the UX logic is consistent β but if you’re handing this to a client who’s used Shopify’s admin, budget time for the “this feels old” conversation. The front-office themes are fine and customers won’t notice anything, but the merchant-facing side is genuinely dated. The module ecosystem is large, which sounds good until you realize a chunk of those modules haven’t been touched since PrestaShop 1.7. Before installing anything, check the compatibility tag for PS 8.x explicitly and sort reviews by date. A module with 500 reviews and a 4.8 rating means nothing if the last review is from 2021.
Who Should Actually Use This
- 50+ SKU catalogs with attributes: sizing, color variants, material types β PrestaShop’s combination system handles this cleanly and the faceted search makes it discoverable
- B2B stores: if you need customer group pricing, minimum order quantities, or quote requests, you’re getting that free here versus paying for extensions elsewhere
- EU stores: VAT rules per country, multi-currency, and GDPR-compliant cookie handling are all native β not an afterthought requiring three plugins
- Developers comfortable with PHP/MySQL: if you can read a stack trace and write a SQL query, debugging PrestaShop is manageable. If your client wants a no-code setup they maintain themselves, the learning curve is steep
Medusa.js: The One for Developers Who Want Full Control
If you’ve ever priced out a Shopify app stack for subscriptions + multi-currency + custom checkout and felt your stomach drop, Medusa is the answer you were looking for. The core is MIT licensed, self-hosted, and genuinely fully-featured β Medusa Cloud exists if you want managed hosting, but nothing is locked behind it. You get subscriptions, multi-region pricing, and custom checkout flows as first-class API concepts, not as $200/month third-party bolt-ons.
Getting up and running is cleaner than you’d expect from a headless framework. One command scaffolds both the backend and a ready-to-run Next.js storefront:
npx create-medusa-app@latest
The CLI walks you through naming your project and picks PostgreSQL as the database (non-negotiable β SQLite exists for local dev but don’t ship it). After setup, medusa develop boots your API on port 9000 and the admin panel on 7001. The admin is legitimately good β product management, order handling, discount rules β and it talks to your own API, not some external SaaS endpoint you can’t control. The thing that caught me off guard was how much is already wired up in the Next.js starter: cart context, checkout steps, region switching. You’re not staring at a blank canvas.
The backend is Node/Express under the hood. Your custom logic lives in /src/api for new routes and /src/services for extending core behavior. Want a custom endpoint that calculates shipping based on order weight and destination before the customer hits checkout? That’s a 40-line service, not a support ticket to a SaaS vendor:
// src/api/store/custom-shipping/route.ts
import { MedusaRequest, MedusaResponse } from "@medusajs/medusa"
export const POST = async (req: MedusaRequest, res: MedusaResponse) => {
const { cart_id } = req.body
// your logic here
res.json({ shipping_options: [...] })
}
Here’s the honest trade-off you need to internalize before committing: the plugin ecosystem is small. WooCommerce has decades of community plugins for every niche carrier, payment processor, and ERP. Medusa has the essentials β Stripe, PayPal, SendGrid, S3 β and then it drops off sharply. Need FedEx LTL freight rates or a specific regional payment method? You’re writing a custom fulfillment provider or payment processor from scratch. That’s not a dealbreaker if you have the dev hours, but it’s a real cost. Budget it honestly.
Where Medusa genuinely pulls ahead: anything with unusual business logic. I’ve seen it used for B2B stores where pricing varies per customer account, for rental businesses that needed time-based availability checks baked into the cart, and for mobile apps where the web store and the React Native app share the exact same API. That last use case is where Medusa is almost unfair compared to alternatives β your mobile app just calls POST /store/carts and POST /store/orders like any other client. No separate mobile SDK, no Shopify Storefront API rate limits to manage.
- Use Medusa if: you’re a developer building a store with logic that doesn’t fit a standard template β subscriptions, B2B pricing tiers, regional catalogs, or a mobile app running alongside the web store.
- Don’t use Medusa if: the person maintaining the store post-launch isn’t technical. The admin panel is good, but there’s no theme editor, no drag-and-drop page builder, and plugin gaps get solved with code, not clicks.
- Watch out for: database migrations when you upgrade Medusa versions. Run
medusa migrations runafter every upgrade and test on a staging DB first β the migrations are usually fine, but “usually” is doing a lot of work in that sentence.
Square Online: The Only Zero-Infrastructure Free Option
No repo to clone, no config to wrestle with, no hosting bill to rationalize β Square Online is the only option on this list where the path from “zero” to “taking real money” is literally just a browser tab. You go to squareup.com, create an account, and start adding products. That’s not a simplified pitch β that’s the actual flow. I’ve watched non-technical business owners have their first product listed in under 20 minutes. For developers who’ve spent hours debugging Nginx configs just to launch a side project, it feels almost suspicious.
The free tier holds up better than most. You get unlimited product listings, a yourname.square.site subdomain, and real payment processing β not a sandbox, not a trial, not “up to X transactions.” The catch that actually matters is the transaction fee: 2.9% + $0.30 per transaction. That’s identical to Shopify’s basic rate, so don’t expect Square to be cheaper on that front. Check their current pricing page before you commit, because these numbers do change. The other hard blocker: custom domains are locked behind the Plus plan. Your store will live at yourname.square.site until you pay up, and that subdomain does real damage to organic search.
The thing that caught me off guard the first time I set this up for a client was how genuinely good the Square POS sync is. If you’re a retailer already running Square hardware at the register, inventory updates in both directions without any configuration. You sell a hoodie in-store, it decrements online. You fulfill an online order, the POS reflects it. That bidirectional sync is the actual reason to pick Square Online over everything else on this list β not the price, not the feature set. For anyone running a hybrid physical/digital operation on Square hardware, this is the obvious choice.
Where it falls apart is predictable once you know what to look for:
- SEO ceiling: The free subdomain gets indexed, but you have no control over canonical URLs, sitemap structure is limited, and page speed on the free tier can drag. You’re not building a search-driven traffic machine here.
- No abandoned cart recovery: This is a paid feature. If you’re selling more than a handful of SKUs and expect any cart abandonment (you will), you’re leaving money on the table on the free plan.
- Third-party integrations: Syncing inventory with an existing Shopify store, or pushing orders into an external ERP? That’s either manual work or a paid Zapier/Make workflow. Square’s native integration ecosystem is thin compared to WooCommerce or even Wix.
- No digital product delivery: Square Online doesn’t natively deliver digital downloads. If you’re selling PDFs or templates, you’ll be emailing files manually or hacking together a workaround.
The honest positioning for Square Online is this: it’s a secondary channel, not a primary one. A coffee shop adding online ordering for pickup. A boutique that wants their Square register inventory to automatically appear online. A service business selling five gift card denominations. That’s the sweet spot. If you’re launching a standalone e-commerce operation with growth ambitions and SEO as a channel, the free subdomain and missing marketing tooling will grind you down inside six months. Pick something else and come back to Square when you need the POS sync.
Side-by-Side: What Actually Matters for a Small Store
The thing that trips up most people comparing these platforms is optimizing for the wrong variable. Everyone asks “which is cheapest?” when the real question is “which gets me selling fastest without screwing me later?” Those are different questions with different answers. Here’s the raw comparison, then I’ll tell you what it actually means.
| Platform | Hosting Cost | Transaction Fees | Product Limits | Technical Skill | Time to First Sale |
|---|---|---|---|---|---|
| WooCommerce | ~$6β10/month | 0% platform fee (Stripe/PayPal rates apply) | Unlimited | Moderate | ~2β4 hours |
| PrestaShop | ~$5β10/month VPS | 0% platform fee | Unlimited | Higher | ~3β6 hours |
| Medusa.js | ~$10β20/month (RAM-heavy) | 0% platform fee | Unlimited | Developer-level | ~1β2 days |
| Square Online | $0 | 2.9% + $0.30 per transaction | Unlimited (free tier) | Minimal | ~30 minutes |
The transaction fee math on Square Online deserves a closer look before you write it off as “just 2.9%.” On a $50 product, you’re paying $1.75 per sale. Sell 200 units a month and you’ve spent $350 in fees β enough to pay for WooCommerce hosting for nearly three years. The crossover point where WooCommerce’s ~$8/month hosting becomes cheaper than Square’s per-transaction cut happens somewhere around $280β300 in monthly revenue, depending on your average order value. Below that, Square is genuinely the cheaper option even though it “has fees.”
PrestaShop’s placement in this list is the one I’d push back on if you’re a solo founder. The free software is legitimately free, but the module ecosystem is predatory β basic features like one-page checkout or abandoned cart emails cost β¬150ββ¬300 each through their marketplace. WooCommerce has the same problem to a lesser degree, but the WordPress plugin ecosystem is so much larger that free alternatives exist for almost everything. With PrestaShop, you often hit a wall where the official paid module is the only real option. The 3β6 hour setup estimate is also optimistic if you’re not already comfortable with Linux server administration and MySQL.
Medusa.js is in a completely different category and I want to be direct about that. The other three are store builders. Medusa is a headless commerce engine β you’re getting a REST API and an admin panel, not a storefront. You still need to build or wire up a frontend, configure a Redis instance, and connect a PostgreSQL database. The 1β2 day estimate assumes you already know what you’re doing. Here’s what a basic local setup actually looks like:
npx create-medusa-app@latest my-store
cd my-store
# You'll need PostgreSQL running β Medusa won't use SQLite in production
# Set your DATABASE_URL in .env:
# DATABASE_URL=postgres://user:password@localhost:5432/medusa_store
npx medusa migrations run
npx medusa seed # optional demo data
npx medusa develop
That gets you the backend on localhost:9000. Your storefront is still a blank canvas. That’s the point β Medusa gives you complete control over every piece of the commerce logic, which is genuinely powerful if you’re building something that doesn’t fit the standard template. Custom subscription models, multi-vendor marketplaces, B2B pricing tiers β this is where Medusa earns its place. But if you’re selling candles or phone cases, it’s massive overkill.
The honest decision tree: no technical background and you need revenue this week β Square Online, full stop, don’t argue with yourself. Comfortable installing WordPress plugins and want to own your data without per-transaction fees β WooCommerce on a cheap Hetzner or DigitalOcean droplet. Running a development shop or building a product where commerce is one feature among many β Medusa. PrestaShop is the choice for almost nobody starting fresh in this space; it made more sense before WooCommerce matured and before the headless options existed.
When to Pick What: Matching the Tool to Your Actual Situation
Non-technical founder, side project, launching this weekend β Square Online
Stop overthinking it. Square Online has a free tier, connects to a free Square payment account, and you can have a product page live in about 45 minutes without touching a config file. The thing that surprises most people is that the free plan actually lets you sell β you pay 2.9% + $0.30 per transaction, same as Stripe, but there’s no monthly platform fee eating into your margins before you’ve made a single sale. You can always migrate later. The worst outcome isn’t picking an imperfect platform β it’s spending three weekends configuring WooCommerce and never shipping. Get the first sale first, optimize the stack second.
You’re a developer building a store for a client who will manage it themselves β WooCommerce
I’ve handed off stores built on Medusa.js and Sylius to clients and regretted it every time. The support emails start within a week. WooCommerce wins client handoffs specifically because your client already knows WordPress, or their nephew does, or there’s a YouTube tutorial for literally every task they’ll ever need to do. The WordPress admin is ugly and dated but it’s learnable without you. The real setup cost is hosting β don’t cheap out here. Put them on Cloudways (starts around $14/month) or a managed WordPress host. A WooCommerce store on shared $3/month hosting will crater under any real traffic and you’ll get blamed for it.
# Quickest local dev setup for WooCommerce before handing off
wp core download
wp config create --dbname=clientstore --dbuser=root --dbpass=root
wp core install --url=localhost:8080 --title="Client Store" --admin_user=admin
wp plugin install woocommerce --activate
Get them comfortable with the Products screen and Order management before you hand over the keys. Those two views are 90% of what they’ll touch.
Fashion/niche store, 100+ SKUs, SEO is your primary acquisition channel β PrestaShop
PrestaShop’s layered navigation β the filterable sidebar with attributes like size, color, material β is built in and generates proper faceted URLs that Google can actually crawl. Contrast this with WooCommerce where you’re installing plugins to replicate the same behavior and praying they don’t conflict. For a store where someone searches “linen wide-leg pants under $80” and you want a category page ranking for that, PrestaShop’s URL structure out of the box is cleaner. The tradeoff is real though: the initial setup is a solid day’s work, module quality varies wildly on their marketplace, and the admin UI feels like 2012. Plan for 4-6 hours of setup before you touch a product. It’s worth it if SEO is your channel; it’s overkill if you’re driving traffic from Instagram ads.
Custom business logic β subscriptions, rentals, multi-vendor β Medusa.js
Every other platform on this list will fight you the moment your data model doesn’t fit standard retail. I tried building a rental marketplace on WooCommerce once using a combination of plugins. It worked until it didn’t, and debugging the interaction between four plugins you didn’t write is a special kind of misery. Medusa.js treats the commerce engine as an API you own, which means you implement the business logic yourself, but it’s your code, not plugin soup.
# Bootstrap a Medusa backend
npx create-medusa-app@latest my-store
cd my-store/backend
# Custom subscription logic goes in src/services/
# Medusa exposes a SubscriberService you extend directly
The honest gotcha: Medusa’s free/open-source core is solid but the managed cloud (Medusa Cloud) is paid. You’ll be self-hosting on something like Railway or a VPS. Budget time for that infrastructure work. The docs are actually good β better than PrestaShop’s β but you need to be comfortable reading TypeScript and you need to actually want to write code. This is not a weekend project for a non-technical founder.
You already run Square in-person β Square Online, full stop
The inventory sync between Square POS and Square Online is the whole argument. Sell the last medium in-store, and it goes to zero online automatically. The alternative β maintaining two inventory systems manually and dealing with overselling emails from customers β is a tax on your time that compounds daily. Square’s ecosystem is designed around this exact use case: a business with a physical presence extending to online. The free tier covers it. You don’t need to evaluate anything else if this describes you.
Real Gotchas I Hit That the Docs Don’t Mention
The WooCommerce + shared hosting combo is a silent performance killer and it’s almost never documented clearly. By default, WordPress uses wp-cron β a fake cron that piggybacks on page loads. Every time someone visits your store, WordPress checks whether scheduled tasks need to run. Order confirmation emails, inventory sync, subscription renewals β all of that fires during a real user’s page request. On a busy day, your checkout page randomly gets sluggish and you’ll spend hours blaming your theme. The actual fix is two steps: first, disable the fake cron by adding this to wp-config.php:
define('DISABLE_WP_CRON', true);
Then add a real server cron via cPanel or crontab -e:
*/5 * * * * php /var/www/html/wp-cron.php
Adjust the path to match your actual install. After I made this change on a client’s store, page load on the cart dropped noticeably and the “random slow checkout” complaints stopped entirely.
PrestaShop SSL Migration Will Break Your Store If You Do It Wrong
I installed PrestaShop on HTTP thinking I’d sort out SSL later. That was a mistake. The admin panel has a setting for enabling SSL β you flip it, save it, and then spend 20 minutes wondering why half your assets still load over HTTP and your store redirects in an infinite loop. The reason is that PrestaShop stores the domain in two separate config rows: PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL. The admin UI sometimes only updates one of them. You need to go directly into the database and fix it:
UPDATE ps_configuration
SET value = 'yourdomain.com'
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');
Then clear the PrestaShop cache from /var/www/html/var/cache/ (or app/cache/ on older versions). Don’t skip the cache clear β PrestaShop caches configuration aggressively and you’ll think the query didn’t work. Also make sure your .htaccess or nginx config is forcing HTTPS before you toggle the SSL setting in admin, otherwise you’ll get locked out of the backend.
Medusa.js Has a Hard RAM Floor Nobody Tells You About
The Medusa.js docs make it sound like you can spin this up anywhere Node runs. Technically true. Practically, the default stack β PostgreSQL, Redis, and Node all on the same box β needs real memory. I tried deploying on a 512MB DigitalOcean droplet to keep costs down during testing. The npm build step OOM-killed the process every single time. Not a graceful error, just a dead process and a confused shell. You need at least a $12/month droplet (1GB RAM) to get through the initial build without the kernel stepping in. Once it’s running, memory usage settles down and you could theoretically tune it lower, but the build itself is the spike that gets you. If you’re evaluating Medusa for a client and want to demo it cheaply, build the image locally or on a CI runner and push the built artifact β don’t build on the server.
Square Online’s Free Tier Quietly Walls Off Google Shopping
Square Online looks like a solid zero-cost option and for a basic storefront it is. But the moment you try to grow traffic through free Google Shopping listings, you’ll hit a wall. The free tier doesn’t support Google Merchant Center product feed export. There’s no API access to generate a feed yourself either β the product data is locked inside Square’s system. You only discover this when you’re deep in the Google Merchant Center setup flow, looking for the feed URL that doesn’t exist. Upgrading to Square’s paid plan unlocks the integration, but at that point you’re paying a monthly fee and the “free alternative” framing falls apart. If Google Shopping is part of your launch strategy from day one, Square Online free tier isn’t your platform. WooCommerce with the free Product Feed Pro plugin or PrestaShop with its built-in feed module will actually get you there without opening your wallet on day one.