01 / FIT SIGNAL
You need to own the operating model
The business needs control over commerce data, integrations, release decisions and the conditions under which the store can keep trading.
01
WHEN MEDUSA EARNS ITS COMPLEXITY
OWNERSHIP / EXTENSIBILITY / CONTROLMedusa is not the answer because a merchant wants a newer stack. It earns its place when the business needs to own the parts of commerce that a rented platform keeps behind policy, templates, app boundaries or an unsupported checkout path. That can mean a complex catalogue, a bespoke operational workflow, an integration that has become commercially critical, or a payment and compliance requirement that needs to be treated as architecture rather than an afterthought.
For restricted commerce, that ownership can be especially important. Platform rules, payment approval and compliance controls are not abstract technical preferences when they determine whether a store can keep trading. The same is true for established merchants whose product, B2B, data or fulfilment requirements have become too consequential to manage through accumulated workarounds.
The decision is still not a platform pitch. A merchant that needs better execution on its current store may be better served by ecommerce management or Shopify optimisation. A merchant that needs to decide whether any replatform is justified should start with the ecommerce migration assessment, before committing to Medusa.
02 / FIT SIGNAL
The catalogue or workflow is genuinely bespoke
Complex product relationships, B2B requirements, custom fulfilment logic or operational rules have outgrown a layer of theme and app workarounds.
03 / FIT SIGNAL
Payments and compliance shape the architecture
A restricted or regulated vertical needs payment continuity, age or eligibility checks, compliance controls and an owned path when platform policy becomes an operating risk.
04 / FIT SIGNAL
The team can support a more capable stack
The merchant has the appetite to treat the platform as a product: clear owners, a release discipline and a realistic budget for build and ongoing operation.
02
WHEN MEDUSA IS NOT THE RIGHT ANSWER
NO PLATFORM SCRIPT / NO FORCED REPLATFORMNOT A FIT
A standard storefront is the whole requirement
If native platform features and a conventional theme meet the commercial need, custom architecture can add cost and operational weight without returning enough control.
NOT A FIT
The constraint is execution capacity, not the platform
A backlog, slow merchandising or weak technical ownership may call for the ongoing RUN service rather than a replatform.
NOT A FIT
The team cannot own the result after build
Self-hosted commerce is not a way to remove responsibility. Without named operational ownership and a sustainable run model, the stack becomes another dependency.
NOT A FIT
The project starts with a price-only brief
Medusa is not a cheaper version of a hosted platform. It is appropriate when the ownership, integration, payments or compliance case earns the investment.
UNQUALIFIED / START HERE
Do not choose an implementation before you have named the constraint.
If the current problem could be solved by better operating ownership, theme-level work, a contained integration or a clearer platform decision, the responsible next step is a migration assessment, not a Medusa proposal.
Explore ecommerce migration ↗03
THE CAPABILITY HAS TO REACH OPERATIONS
MODULES / DATA / ADMIN / SEARCH / PAYMENTSA credible Medusa build does not stop at a storefront. The value of an owned stack is that the commerce model, operational interface and delivery path can be designed together. That is why the work spans the implementation layers below rather than treating the backend, search, payments and operations as separate projects with no shared owner.
The specifics are scoped to the merchant. No payment provider, compliance path, data treatment or deployment pattern is promised before the business and technical constraints are understood. The point of the fit process is to decide which of these capabilities need to exist, how they are owned, and what must be proven before release.
Ownership does not mean recreating every commodity service from scratch. It means making deliberate boundaries: what Medusa should own, what a specialist provider should own, how data moves between them, what happens when an integration fails, and who has authority to change the commercial rules. Those decisions reduce hidden dependency rather than replacing one form of lock-in with a collection of unmanaged services.
The storefront is therefore only one expression of the system. The same architecture needs to support the people maintaining products, resolving exceptions, reviewing payment or compliance conditions, preparing releases and deciding what changes next. That is the practical standard for a build that can be run after the project team has stepped back.
MODULES
Commerce logic with boundaries
Medusa modules let commerce logic be composed around the business rather than buried inside a theme. Product, pricing, promotion, fulfilment and integration work can have explicit boundaries and owners.
DATA
Migration as governed data
Products, variants, customers, orders, content and relationships need a mapped destination, transformations, validation and exceptions. A usable store begins with data the operating team can trust.
ADMIN
Operations need an interface
Admin extensions should expose the decisions and workflows the merchant actually needs to run: catalogue maintenance, controlled exceptions, operational context and role-appropriate access.
SEARCH
Search belongs in the architecture
Search behaviour, indexing, merchandising and relevance need to be designed with the product model and storefront journeys, not bolted on after the catalogue has been imported.
PAYMENTS / COMPLIANCE
The checkout path is part of the stack
Payment providers, eligibility checks, age verification and compliance rules are assessed as business-critical integrations. The right answer depends on the merchant, vertical and approval path.
DEPLOYMENT
Release with a recovery path
Environment configuration, release checks, monitoring and rollback conditions are part of delivery. A handover is not complete because code has reached a host.
OWNERSHIP
Build and run stay connected
The operating model continues after the build: prioritisation, implementation, observed issues and the next decision remain visible to the people responsible for the store.
04
EVIDENCE WITHOUT A COMPLETION CLAIM
GREY HAZE / PRE-LAUNCH VERIFICATIONGrey Haze is the relevant implementation reference for this kind of work because the delivery question crosses data, admin operations, search, payments and compliance, deployment and ongoing ownership. Its status is deliberately limited: Grey Haze remains in pre-launch verification, and production cutover has not been verified.
The figures here are verification scope, not a declaration of a completed migration or a promise of a comparable result. They show why module boundaries, data validation, operational controls and a staged release path need to be designed as one system. Read the Grey Haze verification record for the current evidence trail.
orders included in Grey Haze pre-launch verification.
line items included in Grey Haze pre-launch verification.
customer records included in Grey Haze pre-launch verification.
orphan records observed in current Grey Haze pre-launch verification.
05
A 360 SERVICE MEANS THE BUILD HAS AN OWNER
BUILD / RUN / RESPONSIBILITY01 / DELIVERY
Assess the platform decision
We begin by separating the actual constraint from the desired technology. The migration assessment records the commercial, data, search, payment, compliance and operational questions before a target stack is assumed.
02 / DELIVERY
Design the operating system
Architecture includes the storefront and backend, but also the data model, integrations, admin workflow, search behaviour, payment path, release controls and the people who will operate them.
03 / DELIVERY
Build and verify in stages
The work moves through scoped implementation, mapped data, integration checks and a staged release plan. Acceptance checks and rollback conditions are named before a cutover window.
04 / DELIVERY
Keep the ownership practical
After the build, the same decision discipline applies to the operating queue. Hollow Point can continue as a senior commerce partner where the merchant needs connected technical and commercial ownership.
Restricted commerce is a proof-rich fit, not the only fit.
Merchants in restricted verticals can need stronger ownership of payments and compliance. Read the restricted-commerce approach when those are the central constraints. Other complex merchants can face the same architectural questions through B2B, data, integrations or operating workflow.
Traffic to this page comes from our Medusa guides, not this URL — here is why we still built it.
This is a decision page for technically aware, referred and partner-led visitors. The headless commerce guide explains the wider model; this page makes the delivery and ownership standard explicit for people already considering Medusa.