A store differs from a site in that it has money, stock and obligations to a buyer in it. Which makes the choice of platform costlier than a mistake in the markup: changing it a year later means moving products, customers, orders and search rankings all at once.

I build stores on Medusa. Below is what it is, and how it compares with the four alternatives usually lying on the table beside it.

What Medusa is

An open commerce platform written in TypeScript and published under the MIT licence. The core covers what is the same for everyone: products and variants, cart, orders, discounts, stock, sales regions and taxes, and the interfaces for payment and delivery providers. The admin panel is included. The storefront is a separate Next.js application that talks to the core over an API.

Only two enterprise features are licensed separately and commercially: role-based access control (RBAC) and single sign-on (SSO). Everything an ordinary store is made of is covered by MIT.

SaaS platforms: convenient right up to the first requirement

Shopify and Russian platforms such as InSales or Ecwid honestly solve the problem of getting started: sign up, upload your products, sell. While the store is standard, that is the best way to test demand.

What becomes a problem later:

• The fee grows along with turnover. On top of the subscription comes a percentage of sales — Shopify takes it on every order unless you use its own payment service. The work of setting a store up is one-off; the commission is forever, and the point where it outweighs everything arrives sooner the better the sales are going.
• Customization stops at the boundary the platform drew. A non-standard order scenario, your own delivery calculation or your own discount logic is either provided for or it is not.
• The data and the customers live inside the platform, and leaving it is a migration project of its own.
• A foreign platform is separately inconvenient for a Russian merchant: accepting payments and fiscalization under 54-FZ is not what an overseas service concerns itself with.

Off-the-shelf solutions: 1C-Bitrix and the like

The strong side is obvious: integration with 1C, plenty of contractors on the market, an interface everybody knows. If the company’s entire accounting lives in 1C, that is an argument worth taking seriously.

The weak side is the way you extend it. Your own logic is added by editing somebody else’s components inside a PHP monolith, and every such edit makes the next platform update more expensive. Plus a licence that has to be renewed in order to keep receiving those updates.

In Medusa what is yours lives beside the core rather than inside it: a separate module or workflow attaches to the platform through its own extension points. A core update does not overwrite what you wrote, because what you wrote is off to one side.

The practical difference is audible on the very first non-standard requirement. On an off-the-shelf platform the answer is “that cannot be done”. Here it is “that needs a module”.

WooCommerce: a store as a plugin to a blog

Starting is cheap, and that is its main argument. After that the store starts accumulating plugins: one for delivery, another for payment, a third for product variants — from different authors, on different update cycles, some of them paid annually. Each adds its own code to the server, and the sum of the yearly licences quietly catches up with the cost of proper development.

On top of that comes maintaining WordPress itself, and on a large catalogue or during a sale, performance, which then has to be fixed with caching.

Magento and Adobe Commerce

A powerful enterprise-grade platform, and that is exactly why it is not an option for most: the server requirements and the development costs are sized for large retail. For a store with a few hundred items that is expensive infrastructure and expensive specialists.

The open-source competition: Vendure, Saleor, Sylius

The fairest comparison is with the ones built along similar lines. Sylius is built on PHP and Symfony, Saleor on Python with GraphQL, and Vendure — also TypeScript — is the closest of them.

Why I chose Medusa out of that group:

• One language across the whole project. TypeScript in the core, in the modules written on top, and in the Next.js storefront. One codebase, one set of types from the database to the Buy button — and, more to the point for the owner, one developer instead of a PHP backend developer plus a frontend developer.
• Modules and workflows as the intended way to add logic, rather than as a workaround.
• The admin panel and the storefront exist from the start: a working dashboard is included, along with a ready Next.js starter store, rather than only an API you have to write an interface against from scratch.
• MIT with no caveats on everything an ordinary store is made of. Licences vary between open platforms more than people expect, and that is worth checking before the work starts rather than after.
• An active community and thorough documentation — what decides whether an answer to a rare question exists, and whether another developer can be found later.

In one table

What this gives you on the Russian market

Payment and delivery integrations in Medusa are providers with a described interface, not patches over somebody else’s logic. So a store is assembled for the Russian market with the platform’s own tools:

• Payment — YooKassa or Robokassa, with fiscalization and a receipt for the buyer under 54-FZ.
• Delivery — ApiShip: CDEK, Russian Post, Boxberry and other carriers in a single integration, plus pickup and a cost calculation right in the cart.
• Taxes and sales regions — rates, price display and rules for different cities are configured in the admin panel.

What the platform itself costs

Nothing. No installation fee, no subscription, no percentage of turnover. The costs are a server with a database and the payment provider’s commission for processing a payment — that is, for work done, rather than for the fact that a store exists.

The server, the domain and the repository are in the store owner’s name, and so is the code. Medusa is not a bespoke system: another developer will be able to carry on, because there is open documentation and a large community behind the platform.

When Medusa is not needed

• Twenty products, ordinary delivery and no special requirements. A builder is cheaper, and I will say so plainly.
• All the selling happens through marketplaces. Then what you need first is a shop window or a landing page, not a second sales channel with a cart of its own.
• The store is needed tomorrow and without a developer. Medusa is a development platform, not a website builder.
• All the accounting is in 1C and you need integration out of the box. Exchange with 1C can be built with Medusa, but it is work, whereas Bitrix already has it.

A live example

The demonstration store runs at dtc.sourcemap.ru — a storefront and an admin panel, both deployed by me. It is a demonstration of what is possible, not a client project: the design for a particular store is developed separately. What the demo shows, and what is deliberately left unconnected in it, is on the Online store solution page; what the work includes is on the Online stores service page.

If you already have a store and the question is whether to move, write to me: the review is free, and sometimes the honest answer to it is “stay where you are”.