Why Picocart, when Medusa already exists
Medusa is great. Picocart is not trying to compete with it - but Autonnel needs a different shape of commerce backend.
Let me say this plainly at the top: Medusa is one of the best pieces of open-source commerce infrastructure available right now. It’s modular, Node-native, well-documented, and has a real community behind it that isn’t just GitHub stars collected in a weekend. If you’re building headless commerce and need a full engine, you should seriously evaluate Medusa before you evaluate anything else. This post is not an argument that Medusa is wrong. It’s an explanation of why Autonnel is building Picocart anyway - and why those are actually two different questions.
What Medusa is optimized for
Medusa’s design reflects a clear, well-reasoned opinion: commerce should be the primary system, and everything else builds on top of it. The storefront is a client. The admin UI is a client. Your custom checkout flow is a client. Medusa holds the canonical state - products, inventory, orders, customers, pricing - and exposes it through a modular REST API that you consume from whatever frontend you choose.
That architecture makes sense precisely because Medusa does a lot. It’s not just product storage with an order table bolted on. Location-aware inventory means the same SKU can be tracked across multiple warehouses and fulfillment centers, with routing logic to decide which one ships a given order. The tax module integrates real jurisdictional tax computation. The shipping engine handles rate calculation and carrier integration. Fulfillment routing determines which warehouse picks a given order and what label gets printed.
All of that infrastructure is modular - you can swap the tax provider, add a custom fulfillment provider, write a plugin for your ERP. The plugin ecosystem is real enough that common integrations (Stripe, Mailchimp, various carriers) are maintained packages rather than one-off forks.
The custom REST surface Medusa exposes is designed explicitly for headless-first use. You don’t get a Shopify-shaped API because Medusa isn’t trying to be Shopify-compatible - it’s trying to be better. The endpoints are cleaner, the payload shapes are more intentional, and the authentication story is built for developer control rather than merchant self-service.
When commerce is the center of your business, this is the architecture you want. A DTC brand running multi-location inventory across two 3PLs, doing real-time tax computation for EU VAT, with a custom fulfillment workflow that kicks off a warehouse management system - that’s a Medusa-shaped problem. The engine handles complexity that would take months to rebuild.
What Autonnel actually needs from commerce
Autonnel’s job is funnels. Landing page, checkout, one-click upsell, thank-you. The commerce platform is upstream of all of that. Autonnel reads from it and writes orders to it; it doesn’t replace it.
That means the actual surface area Autonnel touches is small. The Shopify adapter - the one I’ve been running in production and that informed the design of Picocart - calls a specific subset of the Shopify Admin REST API. Products, including variants. Prices, including multi-currency. Inventory, as a single counter per variant. Order creation and status updates. Customer records. Webhooks, so Autonnel knows when an order is paid, shipped, or refunded. That’s roughly ten endpoints. Not ten categories of endpoints - ten endpoints.
Autonnel doesn’t call Shopify’s tax-rate calculator. It doesn’t use Shopify’s fulfillment routing - if the order needs to go to FedEx, that’s Shopify’s problem. It doesn’t surface the Shopify admin anywhere in its UI. The ecommerce adapter is intentionally the smallest possible footprint: read the product data, write the order, listen for status changes.
This matters because the commerce surface isn’t where Autonnel competes. The quality of a funnel depends on page performance, conversion optimization, checkout UX, offer sequencing, and postback accuracy. Commerce is necessary infrastructure, not a differentiator. Autonnel’s ecommerce adapter is deliberately boring.
When the requirement is “implement these ten endpoints well,” Medusa is overspecified. It does implement those endpoints - along with a few hundred others. The tax engine is there whether you use it or not. The multi-location inventory system exists whether your deployment has one warehouse or ten. You’re running all of that for the sake of a product-fetch path and an order-create call.
Why size matters here
The Autonnel deployment story is intentionally minimal. One Astro project, one Cloudflare Workers process, one Postgres connection (or D1, or SQLite on Turso), zero monthly cost until you have real traffic to justify spending money on. That self-hostable-for-free premise is one of the things that makes Autonnel worth building as open-source at all. If you’re a small DTC founder who wants full control over your funnel stack without paying $297/month to ClickFunnels, the promise is: clone, configure, deploy, done.
That promise breaks entirely if standing up Autonnel means you also need to run a Medusa instance. The Cloudflare Workers edge-deployment story Autonnel is built around doesn’t work for Medusa at all - Medusa expects a persistent Node process with a full Postgres connection, which puts it firmly in the VPS or managed Node hosting category. So now you’re operating two completely different deploy stories - one edge, one VPS - with two runtimes, two operational playbooks, two cost models. The self-hostable-for-free ceiling just dropped significantly.
Picocart’s pitch is operational symmetry: the commerce backend Autonnel actually uses, on the same Cloudflare Workers + Postgres edge stack. Yes, it’s a second Worker and a second database - but it’s the same runtime, the same wrangler deploy, the same Hyperdrive Postgres connection model, and the Cloudflare free tier covers both. Nothing new enters the operational surface. And because Autonnel ships a built-in Picocart adapter, wiring the two together is a config change in Settings → Ecommerce, not an integration project.
I want to be clear about what this means: the user is choosing to accept narrower commerce functionality in exchange for operational simplicity. That’s a real trade-off, not a free lunch. If you need Medusa’s full engine - real-time tax computation, multi-location inventory, shipping rate calculation, a rich fulfillment plugin ecosystem - you should use Medusa and write the Autonnel adapter for it. That adapter is probably a day’s work, and the payoff is a production-grade commerce engine running alongside your funnels. Picocart doesn’t invalidate that choice. It just offers a different one.
Shopify API compatibility as a deliberate constraint
The design decision I’m most interested in defending is this one: Picocart doesn’t invent a new REST surface. It implements the subset of the Shopify Admin REST API that Autonnel’s existing Shopify adapter already calls.
The URL structure is the same: /admin/api/2024-01/products.json, /admin/api/2024-01/orders.json. The authentication header is the same: X-Shopify-Access-Token. The payload shapes match. If you diff src/lib/adapters/ecommerce/shopify.ts against src/lib/adapters/ecommerce/picocart.ts in the Autonnel repo, the Picocart adapter is essentially the Shopify adapter with a different base URL and a thin transform layer - because Picocart’s REST surface is the Shopify Admin REST 2024-01 subset.
The practical consequence: Autonnel ships the Picocart adapter built-in. You don’t write integration code. You switch the Settings → Ecommerce provider to Picocart, point it at your Picocart Worker, and the funnels-to-orders path works - against the same product-fetch and order-create shapes that already run in production against Shopify.
Compare that to Medusa. Dropping Medusa in as the commerce backend means writing a medusa.ts adapter. The Medusa API uses different URL paths, different payload shapes, different authentication, different webhook payloads. Writing the adapter isn’t enormous work - probably a week - but it’s adapter maintenance forever. Every time Autonnel’s expectations change, the Medusa adapter needs a corresponding change. Two codebases moving in parallel with a hand-written translation layer between them.
Shopify’s API is not the most elegant REST surface in the world. Some of the payload structures are awkward historical artifacts. Some of the endpoint conventions are inconsistent in ways that make you wonder what was going on in Shopify HQ when that endpoint shipped. But it has one immense practical advantage: it’s the API Autonnel already speaks, and it’s the API thousands of developers already know. When a user brings their Shopify adapter experience to Picocart, the mental model transfers directly.
This is a case where I chose compatibility over elegance, and I think it was the right call.
What Picocart explicitly accepts as trade-offs
I want to be honest about what Picocart is not, because the list is long enough to matter.
No payment processing. Autonnel already has Stripe, PayPal adapters. Payment is Autonnel’s job. Picocart records orders; it doesn’t charge cards. If you’re expecting a payment provider plugin system, look at Medusa instead.
No shipping rate calculator. Autonnel doesn’t surface real-time shipping rates at checkout. If you need “show me rates from FedEx, UPS, and USPS before the customer confirms,” that’s a Medusa-shaped problem, or a dedicated carrier integration (EasyPost, Shippo). Picocart ships orders; it doesn’t price them.
No tax engine. If you need automatic tax computation by jurisdiction - EU VAT, US sales tax by state, the full compliance stack - use Medusa or a dedicated service like TaxJar or Avalara. Picocart stores a tax amount on the order if you pass one in; it does not compute one.
No storefront UI. Autonnel pages are the customer-facing storefront. Picocart has no customer-facing layer at all. It’s admin-only: product management, order management, inventory counts. If you want a storefront built on Picocart data, Autonnel is doing that; Picocart just holds the data.
These aren’t weaknesses we’re planning to fix in a future release. They’re deliberate scope decisions. Picocart is a specific tool for a specific deployment shape, not a general commerce engine making its way toward parity with Medusa. The goal is to stay narrow enough to be useful without becoming the thing it’s not trying to be.
Who should use which
If none of the above was subtle enough, let me be direct.
Use Medusa if serious headless commerce is your primary stack. You need multi-location inventory, a real tax module, shipping rate calculation, fulfillment routing, and a plugin ecosystem that already covers most integrations you’ll need. Medusa is a well-engineered piece of infrastructure built by people who thought hard about these problems. It will serve a commerce-first architecture better than anything Picocart will ever be.
Use Shopify if you want a polished managed SaaS path and you’re comfortable paying for it. The $39/month plan covers most small stores. The transaction fees and the limited ability to modify the checkout experience are the real costs; if those are acceptable, Shopify is a very complete product.
Use WooCommerce if you’re already committed to WordPress and the plugin ecosystem that comes with it. The CartFlows funnel layer on top of WooCommerce works. Autonnel’s WooCommerce adapter connects to it if you’re mixing them.
Use Picocart if you want Autonnel and a commerce backend that share the same edge stack - Cloudflare Workers, Postgres, Apache-2.0 - without introducing a separate runtime to operate, you’re comfortable with the limits above, and the Shopify-compat subset is enough for the products you’re selling and the funnels you’re building. Autonnel ships a built-in Picocart adapter, so wiring them up is a config change, not an integration project. For a single DTC store selling a handful of SKUs through an Autonnel funnel, Picocart should cover everything you need with a deployment footprint that stays inside the Cloudflare free tier.
The honest summary is that Picocart is not a better version of Medusa. It’s a narrower version of “the ten commerce endpoints Autonnel needs,” shaped to deploy alongside Autonnel on the same edge stack instead of forcing you into a second runtime. If that’s your situation, it should fit cleanly. If it isn’t, use the right tool.
More on Picocart itself at /picocart, and on the funnel layer it sits under at funnel builder for Shopify if you would rather keep an existing store as the source of truth.
- github.com/autonnel/autonnel · Issues and feedback welcome.