Why we picked Medusa for Maisōn Harry George

Maisōn Harry George needed one product catalog feeding a retail storefront, a wholesale portal, and an admin dashboard, with room for a mobile app later. The off-the-shelf options each had a way to fake it. None had a way to do it properly. We built it on Medusa. This is the post we wanted to read before we started.

Maisōn Harry George had been handling wholesale clients off the site, phone calls, emails, manual order entry, the kind of process that works for a year and breaks the moment the business grows. They wanted that workflow pulled into the website. Same product catalog as retail, but with B2B-specific pricing, minimum order quantities, account-based logins, and a clean operational view for the team. They were also already thinking about a mobile app and a list of features for future phases that we knew would test whatever we built.

Translation: a single source of truth, three tailored experiences on top of it, and headroom for whatever comes next.

This is the question every founder asks first, so we'll answer it first.

Shopify is excellent at what Shopify is for. If you're selling D2C, you want a hosted platform, and you don't plan to fight the system, it's the right answer. We use it. We recommend it. We've shipped successful Shopify stores.

For Maisōn Harry George, it wasn't the right answer and the reason was less about features than about direction. The client teased a mobile app. They had wholesale workflows that wanted to live inside the same product model as retail, not next to it. They had a list of features for later phases that would each push a Shopify build closer to its limits. We've seen that movie before. You start by paying for apps to plug the gaps. Then you start writing custom code around the apps. Then you hit a wall on the part of Shopify you can't customize, and the rebuild conversation begins.

We look ahead from the first conversation. The question we ask first is where the brand wants to take this. The operation you run today and the operation you'll run in three years are two different jobs to design for. When a brand is planning to grow into something custom, we start it that way from day one.

That's where Medusa came in.

Medusa is an open-source, headless commerce platform. Headless meaning the backend, products, pricing, orders, customers, payments, is decoupled from the frontend. Open-source meaning we own the code, host it where we want, and modify any part of it without asking anyone's permission.

The architecture is modular by design. The same Medusa backend can power as many frontends as you want, a Next.js storefront, a separate B2B portal, a mobile app down the line, and every one of them reads from the same catalog, the same inventory, the same customer records. Pricing rules, customer groups, and sales channels are first-class concepts in the system, not bolt-ons.

For a brand with B2C, B2B, and admin needs sharing one product catalog, that's the architecture you'd draw on a whiteboard if you were starting from scratch. Medusa just happens to ship with it.

That flexibility goes deeper than the data model. Medusa lets developers override core services like pricing engines, cart logic, and fulfillment flows, without forking the platform. And when a project calls for something genuinely custom, like non-standard order states, split payments, or complex checkout logic, those workflows are built in as first-class concepts. It's the difference between adapting your product to what a platform permits, and building the platform around what your product needs.

We built three interfaces on a single Medusa backend.

The storefront is the public-facing site. Retail customers browse, add to bag, check out. Built on a modern React stack, mobile-first, with the polish you'd expect from a fashion-house client, fluid typography, considered transitions, a search dialog and bag dialog that feel native rather than templated.

The wholesale portal is what changed how the business actually runs. B2B clients are assigned their own customer group in Medusa, which unlocks account-based logins, their own pricing through Medusa price lists, and minimum-quantity rules enforced at the cart level. Some retail-only features like gift cards are disabled entirely for wholesale accounts. Where clients used to email an order in and wait for confirmation, they now place it themselves and the team gets notified the second it lands.

The admin dashboard is where the team manages everything, products, inventory, orders, pricing, the lot. One backend, one interface, one place to look. No more reconciling a Shopify export against a wholesale spreadsheet against a notepad on someone's desk.

If there's one part of the build worth dwelling on, it's this one.

Wholesale software is its own genre, and most of it is ugly. The challenge wasn't the data model, Medusa handles customer groups and price lists out of the box. The challenge was making the experience feel as considered as the consumer side. A wholesaler logging in to place a bulk order should feel like they're using a tool built for them, not a retail site with a coupon code stapled on.

The trickiest part wasn't the UI, it was designing the underlying functions that encapsulate the B2B business logic. An isWholesaler getter that a dozen other checks depend on: validating wholesale purchases, enforcing minimum quantities, gating gift cards. Get that abstraction right and every downstream requirement becomes a one-liner. Get it wrong and you're patching edge cases forever. This is the work that doesn't show up in a demo but determines whether the system is maintainable two years later.

For notifications, we wired in Resend. It was one of the last components added, since email isn't critical to core function but matters a lot to the people using it. One important nuance: Medusa doesn't send transactional emails automatically. It provides the events and the data. The email logic is yours to implement, which gives you full control over what triggers what. In practice, Resend handles three flows: password reset links, registration confirmation, and order completion details. Both sides of the transaction know where things stand at all times.

The result is that the studio's clean-interfaces principle, the thing we apply to every storefront we build, got applied to the boring half of the business too. That's where we think the work matters most.

Most ecommerce builds either ignore ERP integration entirely or bolt it on as a panicked afterthought. We did the opposite.

In the discovery phase, before any design work started, we evaluated which ERP made sense for Harry George's operations and which one played nicest with Medusa. We wanted compatibility to be a deciding factor, not a fix-it-later problem. We landed on a recommendation that integrates cleanly with the Medusa backend, which means the inventory, orders, and customer data flowing through the storefront and the wholesale portal can speak directly to the system the team uses to run the rest of the business.

This is the kind of decision that doesn't show up on a website but determines whether the website is a tool or a tax.

A real signature of how we work shows up in the corners of the site.

The gift card is one of the harder pieces we built. We chose pure CSS over video because it gives us more control over quality, performance, and behaviour at every screen size. The structure is an envelope made of three parts: a top flap, a middle body, and a bottom layer. The top and bottom sit above the middle, which acts as the background. When the animation runs, the card enters from below; the top and middle sections merge as it slides in, then separate as the top flap rotates 180 degrees to close. Getting all three elements to align correctly across every viewport took close collaboration between design and development. More iterations than we'd planned, but the kind of problem worth solving properly.

Lottie animations across the site change colour based on the background they sit on. Fluid sizing means the layout doesn't break at awkward widths. Page transitions are tuned, not stock. A search dialog and a bag dialog that respond at the speed your hand expects.

These are not features anyone briefs you on. They're the things you ship because the alternative is "fine," which is what the rest of the internet is full of.

If you're starting your first Medusa project, the most important thing we can tell you is this: prioritize scalability and system integrity from day one. It's easy to move fast and cut corners early. It's much harder to unpick those shortcuts once the project is live and the client wants to expand. On a platform like Medusa, where you're building a real commerce system, not a brochure site, small architectural decisions compound. The investment in abstraction, structure, and upfront planning pays for itself many times over.

A few honest trade-offs from the build, since most case studies skip these:

Admin customization can be frustrating. If you need to extend an existing component, like adding a custom field for product measurements, you can't modify the default widget directly. You have to create a custom widget and mount it alongside the existing one. It works, but it's more effort than you'd expect, and it adds up across a complex build.

Media uploads in the Admin were previously capped at 1MB, which is limiting for real-world e-commerce where product images routinely exceed that. This has been addressed: you can now configure the maximum file size directly in Medusa settings. Worth knowing before you start, and worth checking the current version docs, since this is an area the team is actively improving.

The positive side of both those points: Medusa is evolving fast. The team ships meaningful updates regularly, and the trade-offs we encountered early in the build had already been partially addressed by the time we finished. That trajectory matters when you're choosing a platform to build on for the next few years.

We work in a sea of sameness. Most ecommerce sites today look the same, move the same, and break in the same places. The competitive edge for any brand worth building isn't features, it's the combination of speed and experience. Speed is engineering. Experience is design. Most agencies are good at one and outsource the other. Hooman exists because we think you have to do both, in the same room, on the same project, from the first conversation.

For founders thinking about a build like this, that's the real takeaway. The framework and stack you pick on day one decides what you can ship on day eight hundred. Get the right insight into what you actually need, not just for launch, but for the version of the business you'll be running in three years, and pick the tools that won't fight you when you get there.

If you're building something serious, build it on something serious.

The site launched in April 2026 after a build that ran from discovery in late September 2025 through development sign-off in mid-April. Sixty-five tasks across design, development, and post-launch. A few revisions, a lot of detail work, and a backend that's quietly waiting for whatever the brand wants to ship next.

The mobile app the client teased? The architecture is already ready for it. New sales channels, new markets, new customer types, same backend, same catalog, same source of truth. That's the whole point.