Stop Building Ecommerce Admins From Scratch

TL;DR

• Every ecommerce team needs an admin. The options — build from scratch, buy SaaS, use a component library — all have a hidden cost
• Medusa Admin is open source, fully responsive, and ships with every standard ecommerce module already built: orders, products, inventory, promotions, multi-region, currencies
• Building just the orders module from scratch takes 15+ days. Medusa Admin gives it to you on day one
• It runs as a standalone React SPA — no Medusa backend required
• We run it across multiple India D2C brands including TWT, Foxtale, Swaraa, Music Tribe, Avimee, Mayavi, Comet

The wall every ecommerce team hits

Every ecommerce team hits the same wall eventually. Ops needs to manage orders. Finance needs revenue visibility. The business team needs to configure promotions. Logistics needs to handle returns. Someone needs to create a manual order for a customer without going through the storefront.

The question is always: how do we build this without it consuming the entire engineering roadmap?

There are three standard answers. All of them have a catch.

Build it from scratch. Full control. Also: building the orders module alone — status transitions, fulfillment, returns, refunds — takes 15+ days before a single custom feature. That's just one module. Products, inventory, customers, promotions, multi-region pricing — each one is another sprint. By the time you have a functional base, you've spent months on infrastructure that isn't differentiated.

Use a SaaS admin or closed platform. Faster to start. Until you need something the platform doesn't support — then you're filing support tickets, waiting on roadmaps, building workarounds for workflows the platform was never designed for. You don't own it. The ceiling is whatever the vendor decided.

Use a UI component library. Ant Design, MUI, Chakra — these solve the visual layer but nothing else. An ecommerce admin isn't a UI problem. It's a domain model problem: order state machines, variant hierarchies, inventory reservations, tax rules, sales channels. A component library gives you a table. It doesn't know what an order is.

Why Medusa Admin ships what you'd spend weeks building

Medusa Admin is an open-source React SPA purpose-built for ecommerce operations. It ships with every standard module an ops team needs:

• Orders — full lifecycle: creation, editing, fulfillment, returns, refunds, status transitions
• Products — variants, inventory, sales channels, media management, pricing
• Customers — profiles, order history, segmentation
• Promotions — discount rules, conditions, targeting, usage limits
• Regions and currencies — multi-region pricing, tax configuration, currency management
• Inventory — stock locations, reservations, low-stock alerts
• Settings — user management, team roles, store configuration

Our ops team was navigating order detail pages on day one — no walkthrough, no training session. The UI handles standard ecommerce workflows the way ops teams actually think about them, not the way a generic admin template would model them. That's the difference between a domain-specific tool and a component library with a theme applied.

And it's open source. You fork it. You own it. No vendor lock-in, no pricing tier that gates features, no platform decision that limits your roadmap.

You don't need Medusa's backend to use Medusa Admin

Most teams assume you need Medusa's commerce backend to use Medusa Admin. You don't.

Medusa Admin is a React SPA. It communicates with a backend through a configurable SDK. Whether that backend is Medusa's own server, a custom Node API, or a separate commerce engine — the admin doesn't care. Point it at your backend URL, wire up authentication, and the entire UI works against your system.

This separates two decisions that are usually conflated: "what commerce engine should we run" and "what should our ops team use to manage it." Medusa Admin answers the second question independently of the first. You can adopt it whether you're running Medusa's backend, building your own, or migrating from something else.

The deployed artifact is a static build — S3 bucket behind a CDN, no server process at runtime.

How we went from zero to a custom ops admin in under a day

Before this admin, ops was creating manual orders through a closed platform with no extensibility. Each non-standard order — a gift bundle, a replacement, a manually applied discount — meant navigating a UI built for a different use case, no visibility into the order once created, and no way to tie it to loyalty or fulfilment without a separate step. Every edge case was a support ticket to engineering.

The setup for Medusa Admin standalone was: clone the packages/admin/dashboard subtree from the Medusa monorepo, configure the backend URL and JWT auth, deploy the static build to S3. By the end of the same day, the default admin was running against our backend and ops had access to a working order management interface.

That's the part that's easy to underestimate. The onboarding cost is near-zero because the tool models ecommerce the way ops already thinks about it.

From that foundation, we built 14 custom modules on top — loyalty, BYOB bundles, workshops, EDD, manual orders, analytics, freebie rules, and more — across multiple D2C brands including TWT, Comet, and Avimee. At TWT alone: 999 orders/day and ₹40 lakh in daily revenue running through the admin. The base handled it. The custom layer is what makes each brand's ops workflow distinct.

The one cost worth knowing before you fork

Forking means you own the upgrade path. Medusa ships updates to the admin regularly — new modules, bug fixes, UI improvements. Those updates don't land automatically in a fork. You pull them in deliberately.

For teams that want zero maintenance overhead on the admin layer, the fully managed path is the right call.

For teams that want control — over the UI, the data access, the deployment, the feature roadmap — the fork is worth it. You trade managed updates for complete ownership. Across multiple brands, we haven't found a reason to regret that trade.

When Medusa Admin standalone makes sense

Use it when:

• You're building an ecommerce product and need an operational admin fast
• You have (or are building) your own backend and want the admin layer independent
• You need modules that don't exist in any off-the-shelf admin
• Vendor lock-in is a concern
• You're at a scale where closed platforms create friction faster than they solve problems

Skip it when you want fully managed updates with no maintenance overhead, or when you're running Medusa's full backend without heavy customisation and the default setup already covers your needs.

Build your admin layer, not someone else's

Before your team spends the next sprint rebuilding order management, ask what you're actually buying with that time.

An orders module built in-house gives you the same outcome as one that was already built, tested, and maintained by a team whose entire job is to build it well. The only difference is 15+ days and the ongoing maintenance burden.

Medusa Admin is not a shortcut. It's a better starting point. The modules you build on top — the ones specific to your business, your ops workflows, your users — that's where the engineering time should go.