Building Medusa Stores with Claude Code: My Workflow

I build and operate a production Medusa marketplace with 10,000 products and 50 vendors, and Claude Code sits at the center of how that happens day to day. This article is the working shape of that setup: the tools, how they divide the labor, and what changed. Where the honest answer is "I did not measure it", that is the answer you will get.

What the Claude Code setup looks like

Four pieces, each with one job:

The Medusa side installs in minutes and is official, not community glue: medusajs/medusa-agent-skills is the marketplace (/plugin marketplace add medusajs/medusa-agent-skills, then /plugin install medusa-dev@medusa), and the docs are queryable through the official MCP endpoint at docs.medusajs.com/mcp. Why Medusa cooperates so well with agents — typed surface, predictable file patterns, markdown-exported docs — is a framework property, and I unpacked it separately in the Medusa and AI agents guide; how skills, MCP servers, and plugins layer together as concepts has its own explainer too. This article is the operator's view: what it feels like to work this way on a commerce stack that takes real orders.

The part that changed the most: infrastructure stopped being narrated

Before the Railway MCP server, the loop had a human bottleneck shaped like me: the agent would propose a change, I would deploy, watch logs, copy the interesting lines back into the conversation, and let it continue. Every round trip through my clipboard was latency and lost detail.

With the MCP server in place, Claude Code inspects the infrastructure itself. It lists the services, checks whether the deploy went green, reads the log stream of the worker instance rather than my summary of it, and correlates what it sees with the code it just wrote. The GitHub server does the equivalent for the repository side. My role in the loop shifted from courier to reviewer, and that is the single biggest qualitative change in the whole workflow — bigger than any improvement in the code the agent writes.

Two production facts give this loop its rhythm, both from the deployment setup I run: individual services build in two to three minutes and deploy in parallel. A tight build loop matters more in agent-assisted work than in solo work, because Claude Code's natural mode is many small verified steps, and a deploy that costs three minutes instead of thirty keeps those steps genuinely small.

Skills and instructions carry the Medusa conventions

A coding agent on a framework it half-knows produces plausible code in the wrong idiom. Medusa's agent skills exist to prevent exactly that: they encode how the framework wants modules, workflows, and API routes to be structured, so the agent follows the paved road instead of inventing a parallel one. On top of the official skills, my repository carries its own instructions files — the project-specific layer: how this marketplace models vendors, what the commission logic assumes, which patterns are load-bearing.

The division of labor is worth stating plainly, because it is the part I see teams get wrong: official skills teach the agent the framework; your instructions teach it your project. Neither replaces the other. When both layers are present, the agent's first draft lands inside the conventions; when either is missing, you spend the review correcting structure instead of substance.

Documentation became a side effect

The unglamorous win, and the one I would defend hardest: internal documentation for a six-service stack went from a postponed chore to something that happens as part of the work. When Claude Code finishes a change, having it update the relevant doc is one more sentence in the request. Because the agent just made the change, the doc reflects what is actually there rather than what someone remembered a month later.

How deploys run, what the worker owns, where the images live — all of it now exists in the repository instead of my head. For a small operation, that is worth more than any velocity gain.

What I will not tell you

No token counts here, no "40% faster". I built and operate a marketplace while this workflow evolved underneath it; I never froze a control group, so any speed number would be a feeling laundered into a statistic. I publish what I can stand behind — the same rule that runs through my platform comparisons.

The tooling earned its place the way Redis did: it is simply part of the stack now. And the directional claim I will make, because I would repeat it across a table from you, is that infrastructure-aware agents changed my daily pace more than code completion ever did.

Review isn't optional either. Claude Code writes and investigates; a human reads the diff before anything that touches orders, payments, or customer data ships. A good workflow does not remove that line — it makes the work arriving at it better prepared.

Where this fits in the bigger picture

If you came here from the commerce side, the surrounding decisions live in their own articles: the open source platform field guide for choosing the stack, the case study for what running it actually costs, and the deployment comparison for where to put it. If you came for the workflow side, the dev-workflow topic page collects the rest of this series.

And if you are setting up something similar — a commerce stack meant to be operated with agents rather than despite them — that intersection is precisely what I do for a living. Book a call or start with a two-week PoC Sprint; either way you get the version of this article that answers to your repository instead of mine.