Medusa is an open-source commerce framework built on Node.js and TypeScript. Instead of renting a hosted platform, you run a commerce backend whose product, pricing, cart, and order logic is code your team owns and can extend. It is the right choice when your business model needs logic a hosted platform cannot express: subscriptions with real rules, B2B pricing, marketplaces, or a checkout you control end to end.
← Our stack 
Medusa when commerce needs to be code.
An open-source commerce engine built on Node.js and TypeScript. When the business model is too custom for a SaaS platform, we build the commerce layer itself and own every part of it.
medusajs.com ↗How we use Medusa
Medusa is our commerce engine for stores that outgrow what a hosted platform allows. It is an open-source framework in the same TypeScript and Node.js stack as the rest of our work, so products, carts, pricing, inventory, and orders are modules we can extend in code rather than settings we work around. We customize the commerce logic through its module and workflow system, run the storefront on Next.js against its store APIs, and give the operations team the Medusa admin dashboard for day-to-day catalog and order management. Payments run through Stripe, data lives in Postgres, and the whole backend deploys as a persistent service on Railway.
When the business model does not fit a template, the commerce platform should be code you own.
Why Medusa
Medusa turns commerce into application code we own. When a client needs subscriptions, custom bundles, B2B pricing, or a checkout flow that no template supports, a hosted platform starts fighting back; Medusa lets us build exactly that logic in TypeScript, at the framework level, with no app-store workarounds and no platform transaction fees. Because it runs on the stack we already use everywhere (Node, TypeScript, Postgres, Next.js), the commerce backend is maintained like any other codebase instead of as a separate vendor silo. We still recommend Shopify when a managed platform fits; we reach for Medusa when the business model is the product.
Medusa.js development for custom commerce platforms
Teams come to us for Medusa development when their business model stops fitting the platforms built for standard retail: a subscription with rules no app supports, B2B pricing that changes per account, a marketplace, or a checkout that has to do something hosted checkouts refuse to. Medusa is built for exactly that work. It is an open-source commerce framework on Node.js and TypeScript, structured as modules (products, carts, pricing, inventory, orders, fulfillment, promotions) that we extend or replace in code, with a workflow engine for the custom order logic that makes each business different. The operations team gets a real admin dashboard for catalog and order management, so owning the platform does not mean living in a terminal. Because it is the same language and tooling as the rest of our stack, the commerce backend is reviewed, typed, tested, and handed off like any other application we build, not a black box a single vendor understands.
When we choose Medusa over Shopify
We build on both, and the honest dividing line is how custom the commerce logic needs to be. Shopify is the right call for standard retail: the managed admin, hosted checkout, and app ecosystem cover most stores better than custom code would, and we say so. Medusa earns its place when the model itself is nonstandard. Custom pricing engines, subscriptions with real business rules, B2B account structures, and checkout flows that need to be owned end to end are application problems, and Medusa lets us solve them in TypeScript at the framework level instead of bending a SaaS platform past what it wants to do. The trade is operational: with Medusa you own the hosting, the database, and the upgrades, which is why we deploy it as a managed, monitored service rather than handing a client raw infrastructure. Same discipline as the rest of our stack: the platform is chosen by the project, not by loyalty.
How we do it
How we build on Medusa
-
Model the commerce domain
We map products, pricing, customers, and order flow to how the business actually sells, and identify exactly where the model departs from standard retail. Those departures are the reason Medusa is on the table, so they get designed first, not patched in later.
-
Extend the framework
We implement the custom logic as Medusa modules and workflows in TypeScript: pricing rules, subscription behavior, fulfillment routing, and the order steps unique to the business. The customization lives at the framework level, typed and tested, rather than scattered through the storefront.
-
Build the storefront
We build the customer-facing store on Next.js against the Medusa store APIs, owning the whole experience through checkout. Stripe handles the payment itself, so card data stays inside the payment provider while every other step of the flow is ours to design.
-
Deploy and operate
The backend deploys as a persistent service on Railway with managed Postgres, and we monitor it after launch: logs, error rates, and order flow. Owning the platform only pays off if it runs boringly well, so we treat operations as part of the build.
Medusa vs Shopify: which we build on when
We build on both, and the choice comes down to how custom the commerce logic is. Shopify wins when a managed platform covers the model. Medusa wins when the model is the product and the logic has to be code.
| Medusa | Shopify | |
|---|---|---|
| Best fit | Custom models: subscriptions, B2B pricing, marketplaces, nonstandard checkout | Standard retail where the managed admin and app ecosystem cover the workflow |
| Where the logic lives | TypeScript modules and workflows you own, extended at the framework level | Platform configuration and apps, customized through the Storefront API |
| Checkout | Fully custom and owned end to end, with Stripe handling the payment | Shopify's hosted checkout, with payments and PCI scope inside Shopify |
| Cost and operations | Open source with no platform transaction fees; you own hosting and upgrades | Monthly plan plus transaction economics, with hosting and upgrades managed |
Where we use it
Custom Commerce Backends
Product, cart, pricing, and order logic extended as TypeScript modules for business models a hosted platform cannot express.
Bespoke Checkout Flows
Checkout owned end to end in the storefront, with custom steps and validation, while Stripe handles the payment itself.
Commerce Beyond the Storefront
B2B price lists, multi-channel selling, and custom fulfillment logic served through the same APIs as the main store.
Systems we pair Medusa with
Node.js
Medusa runs on Node, so the commerce backend lives in the same runtime as the rest of our server work. One language across the storefront, the APIs, and the commerce engine keeps the whole system maintainable by one team.
TypeScript
Medusa is TypeScript-native, and we extend it the same way we write everything else: typed modules and workflows, so a pricing rule or order change that breaks a contract surfaces at compile time, not in a customer order.
Next.js
Our usual Medusa storefront. Next.js renders product and checkout pages against the store APIs with the caching strategy each route needs, so a fully custom store still loads like a static site where it can.
Railway
Where our Medusa backends deploy. A commerce engine needs to stay alive between requests, so it runs as a persistent container with managed Postgres and Redis beside it rather than as a cold-starting function.
Stripe
Payment processing for our Medusa builds. Stripe owns the card data and the PCI scope while Medusa orchestrates the order, so a fully custom checkout never touches sensitive payment details itself.
Sanity
The content layer beside the commerce engine. Sanity owns editorial and marketing pages while Medusa owns products, carts, and checkout, composed into one storefront so the story and the store ship together.
Powers these services
Questions
