medusa is good software. it also wants a server, a postgres instance and redis running around the clock, before you have sold a single thing. for a real catalogue with inventory and warehousing, that is the right tool. for a merch drop, a print-on-demand shop, or a demo store, it is paying for idle infrastructure so the shop feels legitimate. the shop does not need to feel legitimate. it needs to take money and ship product.
there is a leaner shape for that class of store, and no server stays on in it.
the shape
three parts, each owned by something that already does the job:
- catalogue and fulfilment live in printify. it holds the products, prints them on demand and ships them. no inventory, no warehouse, no stock to reconcile.
- payment lives in stripe. stripe checkout takes the card, handles the compliance surface and the receipt.
- the glue is a single serverless function. when stripe confirms a payment, the function tells printify to make and ship the order.
nothing runs between orders. there is no instance to patch, no database to back up, no redis to keep warm. cost scales with sales, not with time. an empty day costs nothing.
(this is how the imelabs shop itself runs, and how we would build a lean shop for a client who does not need medusa's machinery.)
why this is the right call, when it is
the win is not just the hosting bill, though £0 idle versus £25 to £45 a month for managed infrastructure is real money on a shop that is not yet selling. the bigger win is operational surface. a static storefront plus two hosted services is almost nothing to maintain. an always-on commerce stack is a security and uptime liability the moment you stop paying attention to it, and a small shop owner will stop paying attention to it.
where it stops working
honest version, because pretending otherwise sets up a nasty surprise. you need a real backend once:
- returns and exchanges happen at any volume. without order state of your own, every return is a manual hunt across stripe and printify. fine for a trickle, painful past it.
- customers expect accounts and order history. the serverless loop is stateless by design; accounts mean state, and state means a database that stays awake.
- tax and shipping get complicated. multiple regions, vat rules, live carrier rates. checkout can carry some of this, but past a point you want logic you control.
- the catalogue gets large, or you add subscriptions, bundles, or stock you actually hold. that is medusa's job, and you should hand it to medusa.
the trigger is not revenue, it is statefulness. the day the shop needs to remember things between visits, the serverless loop has done its tour and it is time to graduate.
want the actual wiring, signature checks, idempotency, the failure case? that's the technical walkthrough.
thinking about a shop and not sure which side of this line you are on? we'll tell you straight.