Choosing a Medusa implementation partner: criteria instead of a ranking

Judge a Medusa partner on how they treat the core, on who answers the phone after launch, and on whether they can name a client whose store is live. A directory badge, a wall of logos and a place in somebody else’s round-up tell you less than they appear to. Below are six criteria you can test in an hour of conversation, before anyone issues an invoice.

Most buyers arrive here holding four agency names from Google and one question: which of them is best. The answer nobody enjoys hearing is that those four cannot be ranked honestly, and we would be no better at ranking them.

They can be told apart, though. That happens to be a different job.

The scope is narrower than the title suggests. Whether to hire an agency, a freelancer or an in-house team is a separate decision, covered separately in who should build your platform. Here we assume you have settled on hiring a firm to build on Medusa.

Why an agency ranking is the wrong format

An honest ranking needs comparable evidence about things invisible from outside: code quality, delivery against dates, what happened on the project that went sideways. No agency holds that evidence about its competitors, having never worked with them. So “top N Medusa agencies” lists get assembled from websites and marketing pages, and the ordering follows whoever published the list.

One example makes the point checkable in a single click. “Top 4 Best Medusa JS Agencies in 2026” was published by the agency Weframe Tech, bylined to Vipul Uthaiah, described on the page as CSO and co-founder of Weframe Tech. The order runs: Weframe Tech, RigbyJS, Agilo, Cloudflight. Page date 17 January 2026, checked at source on 23 September 2026. The same publisher also runs separate rankings for B2B, marketplaces, New York and San Francisco.

No accusation of dishonesty here. The authorship and the ordering are both simply visible.

Our own ranking would place us near the top for exactly the same reason. Hence a guide to criteria instead: criteria apply to any firm, ours included, and you can verify the answers yourself.

What the Medusa Experts badge actually certifies

Start with the numbers, since the directory is the credibility proof most often waved around in this market. The post “Doubling our Expert Network”, dated 2 June 2025, announces nine new partners and “a total of 18 trusted implementation partners”. On 23 September 2026 the official medusajs.com sitemap carries 21 partner profile URLs, excluding the directory index and the application form.

One methodological note, because this count is easy to get wrong. The directory page shows client case tiles alongside partner cards, so counting by eye returns a figure several times higher. We counted profiles in the sitemap, last modified 22 September 2026.

Eighteen partners in June 2025, twenty-one in September 2026. The list grows slowly.

The entry condition is published. The application page says: “If you have experience building with Medusa and have launched one or more projects on Medusa Cloud, you can apply to become a Medusa Expert.” The form asks for your current Medusa Cloud plan, your Medusa Cloud organisation, links to live production projects, the regions you operate in and a typical project budget range. The June 2025 post adds a third condition: wanting Medusa to be your primary commerce platform for clients.

So the signal is narrow and quite concrete: this firm has shipped Medusa into production and runs it on the vendor’s paid hosting. The programme is commercial on both sides, since Medusa lists the benefits as a directory listing, collaborative marketing, early product access and client referrals.

One question the badge answers. On six others, the ones that decide how a project ends, it stays quiet:

• Whether they work on the core: a listing says nothing about building with modules versus maintaining a private fork.
• Who owns the code and the data: ownership is settled by your contract with the supplier, never by a vendor directory.
• Who answers after launch: profiles carry neither a response window nor on-call arrangements.
• How the code gets written: tests, reviews and CI pipelines go unverified on that list.
• Whether your project size suits them: the two profiles we opened state a budget floor of $50,000.
• Whether the firm exists in three years: nobody knows, the firm included.

The fair other half: at 21 profiles the list works as a genuine filter rather than an open register. For a European buyer the strongest entry belongs to Rigby, whose profile states 45+ developers, budgets from $50,000 and authorship of the open-source MercurJS. Agilo, described in its profile as the first official Medusa experts, states a team of 15 and the same budget floor.

Disclosure: we are absent from that directory

Seedlight does not appear in the Medusa Experts directory, and we would rather you heard that from us. The reason is mundane. Our application waits on the first build we can describe with a client name and a link to a working store, instead of an example build from a portfolio.

A listing before then would be a page about us rather than about delivery.

So rather than asking for trust on credit, here is what to demand from us:

• Ask for repository access before signing, and look at the tests, the CI pipeline and the code review history rather than at slides.
• Require an ownership clause covering code, data and database, together with the right to take all of it elsewhere at any point.
• Ask about the first named build and when it lands in our portfolio. A vague answer is itself information.
• Put us against Rigby or another directory partner on these same six criteria. Where they score better, hire them.

A vendor directory listing is the easier thing to display. Code somebody can inspect is the harder thing to fake.

Six criteria specific to Medusa

Generic advice about choosing an agency is everywhere and changes little, because it skips whatever drives your Medusa costs two years out. The six questions below apply to this stack alone. Each has an answer you can verify rather than merely sense.

Our criteria, drawn from implementation work on Medusa. The “how to verify it” column deliberately contains only things checkable before a contract is signed. As at 23 September 2026.

A fork closes the upgrade path

Medusa is designed so the core stays untouched. The documentation defines a module as “a reusable package of functionalities related to a single domain or integration” and states that custom modules integrate into the application “without affecting the existing setup”, living in the src/modules directory of your project. Domain logic therefore has a home beside the core rather than inside it.

Our engineering conclusion, offered as ours and not as a vendor position: a supplier who forks the core hands you the standing cost of merging every subsequent Medusa release. After a year an upgrade stops being a terminal command and becomes a project. After two it usually stops happening, and the store settles on a version nobody patches.

Who deploys the patch on a Sunday

The question looks trivial and settles more than architecture does. A maintenance contract should name three things: the response window for a critical incident, the route for raising one outside office hours, and the person permitted to deploy to production without waiting for anybody. A proposal that offers “support” and none of those three is selling goodwill. How responsibilities divide after launch is set out in our piece on the eCommerce team after launch.

A named build weighs differently from an example build

Medusa portfolios are often collections of demonstrations: a sample store, a theme, an internal project. In a firm that is starting out that makes sense, and we sit in exactly that position, as said above. Understandable does not mean equivalent. A build with a client name behind it carries the information that somebody signed off on delivery and the store survived its first trading season.

Red flags visible in the proposal itself

Four signals show up before the first technical meeting, in the document alone:

• A quote with no specification. A figure produced after an hour-long call describes the supplier’s hope rather than a scope. It ends in change orders, or in quality cut where nobody looks.
• Silence on tests and CI. Where a whole proposal contains no sentence about tests, code review and automated deployment, that usually means none exist.
• Selling hours instead of scope. Billing on “time and materials, let us see” transfers the entire estimation risk to you. We take the two models apart in our piece on fixed scope versus hourly.
• Promises about sales results. Conversion depends on assortment, price and marketing. A supplier answers for a working store, never for your commercial outcome.

A fifth signal is subtler. A supplier who agrees with everything you say in the first meeting is probably selling rather than designing. A good partner says “I would not do that” at least once at this stage.

Questions to ask before you sign

Seven questions, and the whole set fits into one conversation. Write the answers down, because in six months they will be the only record of what was agreed:

• Does the Medusa core stay untouched? Where it does not, ask for the reasoning and for a three-year upgrade plan.
• Where do the repository and database live on launch day? “With us, and we hand over later” has consequences at the point of parting.
• How many people know this project? One means continuity risk, whatever the size of the firm.
• What exactly does maintenance cover? Ask for the line items: monitoring, upgrades, patches, bug fixes, an allowance for small changes, on-call.
• What is the process when something breaks on Black Friday? Who calls whom, within what time, holding which permissions.
• Which integrations do you write and which do you buy? Payment gateway, carriers, parcel lockers and the ERP are usually the largest budget line.
• What happens if we end the engagement halfway? An honest answer is specific, rather than “we do not anticipate that”.

Compare the answers across proposals rather than the totals. Two quotes that differ by half usually describe two different projects.

Our side of the same bargain

We build eCommerce platforms on Medusa and call the result BEAM: Blueprint settles what to build and whether to build at all, Engineering delivers it, and Maintenance & Growth keeps it running afterwards. Builds start at 60,000 PLN net and typically land between 80,000 and 200,000 PLN, AI automation is scoped per workflow from 6,000 PLN, and ongoing care starts at 3,500 PLN a month. The scope of the work is set out on Medusa development.

We close the migration of a trading store in roughly 30 days, counted from the end of the Blueprint to the traffic switch. The sequence that makes that possible without a trading gap is set out in migration without stopping sales. Code, data and database are yours from the first commit.

Scored against those same six criteria we land here: no fork of the core, commercial logic written as modules and workflows, the repository on the client side, and our approach to tests and CI described in how we build. The fifth criterion, a named build, is still empty in our column.

When you should hire somebody else

This section exists because without it the whole piece would be a leaflet. Five situations where we will say so ourselves rather than take the project:

• You need named references today. Where a board requires a list of builds at companies your size, hire a directory partner. Rigby and Agilo both publish named cases and budget floors from $50,000 in their profiles.
• You run a standard B2C store on a budget under 60,000 PLN. Staying on SaaS is often the sounder call. When that stops being true is covered in outgrowing your SaaS platform.
• You want a supplier billed by the hour with no closed scope. We work in stages against a closed scope, so the two of us would simply never agree.
• Your bottleneck is sales channels rather than the platform. Amazon and Allegro account work is run by our sister brand Amazonway, and the store can stay exactly where it is.
• The arithmetic lands on your current platform. The Blueprint then ends with a recommendation to stay, and we write it down in those words.

Limits of this guide

Stated plainly, so the piece can be used as a source:

• The quality of named firms. We have worked with none of the directory agencies and pass no judgement on their builds.
• The full partner count. The directory page renders in the browser, so we counted profiles in the official sitemap: 21 URLs, as at 23 September 2026.
• What other suppliers charge. We know the floors from the two profiles we opened. Our own ranges we publish in full; other people’s we do not estimate.
• Anything after publication. The directory, the network expansion post and the application terms were checked on 23 September 2026, and we return to them quarterly.

An agency round-up answers a question that is easy to ask. The six criteria above answer the one that will cost you money two years from now: who maintains this store, on whose code, and on what terms. More decisions of this kind sit on our comparisons hub, and if the platform itself is still open, start with Medusa versus Shopify or Medusa versus Magento.