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 AN AGENCY EARNS THE BUILD
OWNERSHIP / EXTENSIBILITY / CONTROLA MedusaJS development agency is not a Shopify shop with a different logo. The job is to design the backend, the storefront, the data move, the payment path and the operating interface as one system the merchant owns. Hollow Point is an official Medusa Expert doing that work in the UK, including Shopify to MedusaJS migrations for stores that cannot stay on a rented platform.
MedusaJS 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 MedusaJS.
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
THE FOUR PROOFS, NOT A SLIDE
PAYMENTS / ERP / INTEGRATION / PIMThe test for a MedusaJS agency is not whether it can recite the docs. It is whether it has built the hard parts: payments, warehouse, verification, and the content model the merchant actually edits. These four are the capability case. Developer, plugin, module, storefront and Admin work sit underneath them, not in competing headlines.
PAYMENTS
CyberSource-class 3-D Secure, not a checkout app
A custom Medusa payment provider with hosted fields so card data never touches the commerce engine. Device fingerprint, frictionless and step-up challenge, then server-authoritative capture, void and refund.
Restricted-commerce payments ↗ERP
Linnworks stays the warehouse
Medusa becomes the channel Linnworks already polls: orders out, inventory back, behind switches that only enable after reconciliation. You do not replace the warehouse to leave Shopify.
How we migrate the operating stack ↗INTEGRATION
Age verification as a checkout state machine
KYC wired into fulfilment, fail-closed if the check does not map to a real held order. Completed verifications can come across so returning customers are not asked again on an unfamiliar site.
Verification as engineering ↗PIM
Merchant-editable content off Shopify metaobjects
Page sections, FAQs, blog, navigation, media and redirects with an approved-vs-live flow. Staff stage content and publish it. The storefront is not a theme file.
URL and content parity ↗03
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
MedusaJS 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 MedusaJS proposal.
Explore ecommerce migration ↗04
THE WORK UNDER THE AGENCY PROMISE
HOW THE BUILD IS ACTUALLY OWNEDA credible MedusaJS 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. Plugin, module, Admin, storefront and integration work is how that promise is kept — secondary coverage on this page, not a second pitch.
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 MedusaJS 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
MedusaJS 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
Medusa Cloud 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.
Published MedusaJS plugins, not slideware.
Some of that module, Admin and integration work is already public — five open-source MedusaJS v2 plugins, each extracted from a live build. GitHub is the public source of truth. The full catalog, with what each plugin does, lives on the MedusaJS plugins page.
- RedirectsThe redirects store of truth MedusaJS core has no primitive for.GitHub ↗
- Media libraryA browsable record of every upload the File Module leaves untracked.GitHub ↗
- NavigationMenus with Shopify link-list parity, instead of hardcoding them.GitHub ↗
- KlaviyoConsent-first Started Checkout and Placed Order events.GitHub ↗
- Staff permissionsServer-enforced View/Manage grants across eight business areas, recovery owners and an atomic audit trail — the RBAC MedusaJS core keeps for Enterprise.GitHub ↗release ↗
Source on GitHub, not a slide.
Each is MIT-licensed. Read the code in the public repos; do not install from a GitHub archive. The four utility plugins remain on the @hollowpoint-io npm scope for install. Staff permissions ships as a tagged GitHub release with the verified build artifact attached. That is the standard the client module work is held to. The plugin catalog has the longer description of each.
05
EVIDENCE WITHOUT A COMPLETION CLAIM
VAPE RETAIL FLAGSHIP / PRE-LAUNCH VERIFICATIONOur flagship vape-retail build 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: the build 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 flagship verification record and the Shopify vape ban write-up for the current evidence trail.
orders included in the flagship vape-retail pre-launch verification.
line items included in the flagship vape-retail pre-launch verification.
customer records included in the flagship vape-retail pre-launch verification.
orphan records observed in the current flagship pre-launch verification.
06
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.
This is the MedusaJS agency page, not a holding URL.
If you are deciding whether to hire a MedusaJS development agency, this is the decision surface. The headless commerce guide explains the wider model; the migration assessment is the next step when the constraint is still unnamed.
07
FREQUENTLY ASKED QUESTIONS
PLAIN ANSWERS / MEDUSAJS AGENCYWhat is a MedusaJS agency?
A MedusaJS agency designs, builds and then runs commerce on MedusaJS: the open-source backend, a custom storefront, data migration, payments, search and the operating interface the merchant actually uses. It is not a theme shop and it is not a plugin installer. Hollow Point is a UK MedusaJS development agency that takes that work as one connected BUILD and RUN engagement.
Are you an official Medusa Expert?
Yes. Hollow Point is an official Medusa Expert. That is a third-party credential from Medusa, not a performance guarantee. The work is still scoped, priced and verified against the merchant’s constraints.
Can MedusaJS replace Shopify?
Yes, when the constraint is ownership, a bespoke operating model, payments, compliance or a platform policy the merchant cannot live with. It is the wrong answer when a standard Shopify store and a conventional theme still meet the commercial need. The migration assessment names that distinction before a MedusaJS build is proposed.
Do you build MedusaJS stores in the UK?
Yes. Hollow Point is a UK MedusaJS development agency and an official Medusa Expert. The flagship reference is a £4.5M UK vape retailer rebuilt off Shopify onto Medusa Cloud, with 511,740 historical orders included in the pre-launch verification.
How is a MedusaJS agency different from a Shopify agency?
A Shopify agency works inside a rented platform. A MedusaJS agency builds a stack the merchant owns: data, checkout path, admin, search and the conditions under which the store can keep trading. That is more work, and it is only justified when that ownership changes the commercial outcome.
How much does a MedusaJS build cost?
Hollow Point does not publish a price band. Catalogue size, historical order volume, payments, compliance and the URL map are what move the number, and a store with a small catalogue can be a larger project than one with a big catalogue. Scope is written against a paid assessment of the real data rather than a tier picked in advance. A cheap MedusaJS theme with no data work is not a replacement for a store you already trade on.