How do you build a production B2B storefront with MedusaJS and Next.js?
A practical guide to B2B storefronts: MedusaJS v2 as commerce core, Next.js as the buying portal, customer groups, price lists, sales channels, ERP/PIM and implementation cost.
For a CTO, COO or ecommerce leader, MedusaJS + Next.js fits when B2B needs owned pricing rules, buyer roles, ERP/PIM/WMS integrations and control over the order flow. The starter accelerates setup, but it does not replace domain ownership, customer-data isolation, synchronization rules or checkout regression tests.
First definition: a B2B storefront is not just "a shop with login"
A B2B storefront is the buying layer for business customers: catalogue, prices, availability, cart, checkout, order history and buyer roles. In simple D2C, most users see the same price and checkout. In B2B, the same product can have a different price, minimum order quantity, availability, payment term and approval workflow for each company.
That is where MedusaJS + Next.js becomes useful, but only after responsibilities are separated. MedusaJS v2 owns the commerce core: catalogue, cart, pricing, customer groups, sales channels, regions, orders and workflows. Next.js owns the experience layer: search, buying lists, reorder, quick order, customer dashboard and SEO content. ERP/PIM/WMS remain systems of record for data that already lives outside the storefront.
At GMI Software we start these projects with DDT. We do not ask "which UI component?" first. We ask "which system owns price, stock, customer, credit limit and invoice?". Without that map, even a beautiful storefront becomes an expensive front-end for manual sales work.
What MedusaJS v2 gives B2B teams
Medusa documents storefronts as separate applications hosted independently from the backend. That matters in B2B: you can evolve the buying portal, mobile app and sales-rep console without mixing them with commerce-core logic.
The key B2B modules are Customer, Pricing, Sales Channel, Cart, Inventory, Region and Workflow. The Customer Module stores customers and organizes them into groups. The Pricing Module supports prices in multiple currencies and regions, price lists, rules and best-price calculation in a given context. The Sales Channel Module supports B2B stores, product availability by channel, cart/order scoping and inventory availability per channel.
This does not mean Medusa gives you a full enterprise B2B product by clicking one button. It means it has the right domains to build custom B2B on: contracts, customer segments, credit limits, net/gross pricing, ERP integration and non-standard approval flows.
What Next.js adds in a production storefront
Next.js is a strong fit for B2B because the buying portal has two different workloads: public SEO pages and logged-in operational screens. Public catalogue, categories and landing pages must be fast for Google and AI Overviews. Logged-in views must handle tables, filtering, quick order, reorder and customer-specific prices.
The official Next.js documentation notes that the Image component automatically serves correctly sized images, modern formats, lazy loading and layout stability. For commerce this is not a detail. Product photos, campaign banners and category lists can destroy Core Web Vitals if dimensions, priority and cache strategy are weak.
In practice, GMI designs a Next.js storefront so public data is cacheable while customer data is fetched without leaking contract prices. That usually means separate paths for public content, channel-available catalogue, authenticated prices, cart and checkout.
Reference architecture: who owns what
The healthiest model looks like this: Next.js renders the experience, MedusaJS v2 runs commerce core, NestJS or custom Medusa modules handle company-specific rules, PostgreSQL stores transactional data, Redis/cache accelerates reads, and ERP/PIM/WMS remain sources for invoices, base prices, product data and stock.
The storefront should not ask ERP for price on every click. That creates slow UX and fragile checkout. Instead, prices, stock and customer data need a clear sync model: synchronous where an error blocks the order, asynchronous where freshness in minutes is enough.
Medusa Workflows matter because the documentation describes them as a mechanism for tasks spanning many systems, with step tracking, rollback logic and asynchronous actions. That is the B2B problem exactly: an order can touch Medusa, ERP, payment, trade credit, email, PIM and WMS.
B2B features that are not just UI add-ons
Quick order is not just an SKU input. It must check availability by sales channel, minimum quantity, customer price list, packaging units and product status from PIM. Reorder is not a "buy again" button. It must handle discontinued products, changed prices, missing stock and new credit limits.
A buying list is not a normal wishlist. In B2B it can be a template for a branch, buying team or recurring delivery. Customer account is not just a profile. It means roles, shipping addresses, approval paths, invoice history, limits, buyers and assigned sales rep.
That is why a production B2B storefront needs scenario tests, not only component tests. A useful test says: customer from group A in channel B sees product C, price D, stock E and can place the order only when condition F is true.
Implementation cost: what actually moves the budget
There is no defensible fixed price for a B2B storefront without knowing its price lists, buyer roles, product data and integrations. The same screen set can describe a simple catalogue portal or a system that must enforce contracts, credit rules and ERP exceptions.
Budget grows because of five things: pricing complexity, product-data quality, ERP/PIM/WMS integrations, custom approval/credit workflows and performance requirements for large catalogues. The Next.js layout itself is rarely the biggest cost. The expensive part is the domain decisions nobody wants to name early.
GMI can prepare an initial range after the first review. We set a fixed price only after workshops establish the process, data, integrations, scope and risks. A precise quote before that would be guesswork.
Common mistakes in Medusa + Next.js B2B projects
Mistake one: starting from the starter without deciding which elements are public and which depend on the customer. In B2B, caching public categories is good; caching contract prices without customer isolation is a business and legal risk.
Mistake two: treating ERP as the API for every screen. ERP is often the system of record, but not always the system for real-time UX. You need read models, queues, retries, alerts and reconciliation so the storefront is fast and data remains correct.
Mistake three: no operating owner on the client side. A B2B storefront touches sales, warehouse, finance, IT and customer service. If nobody decides exceptions, the development team starts guessing the business process.
When to choose Medusa + Next.js, and when to stay on SaaS
Choose Medusa + Next.js when B2B is part of advantage: contract pricing, customer-specific catalogues, ERP/PIM/WMS integrations, custom checkout, sales-rep portal, mobile app on the same API or rising SaaS workaround cost.
Stay on SaaS if you have a standard catalogue, simple checkout, few integrations and the team needs fast launch more than owned architecture. Shopify documents companies, locations, catalogues, pricing and payment terms, so many standard B2B needs do not require a custom commerce core.
The best decision is not "Medusa always". It is: choose the simplest stack that removes a measured constraint. For one client that is Shopify B2B. For another, headless-light. For a third, MedusaJS v2 + Next.js + ERP/PIM and a mobile roadmap.
- MedusaJS + Next.js: when custom workflows, integrations and code ownership create advantage.
- Shopify B2B: when standard companies, catalogues, pricing and payment terms cover the process.
- Adobe Commerce: when the organization needs a broad B2B suite and accepts its operating weight.
- Custom engine: only when sales rules are genuinely unique and the team can own the full domain.
Pre-development checklist
Before development, answer 12 questions: which system owns products, prices, stock, customers and invoices; which buyer roles exist; which prices are public; which data needs real time; where checkout can stop; how integration errors are measured.
Add non-functional requirements: Core Web Vitals, cache invalidation, checkout monitoring, ERP sync alerts, price logs, cart regression tests, API key security, admin permissions and rollback plan after launch.
If those decisions are clear, the Medusa and Next.js starter can accelerate delivery. If they are not clear, the starter gives you a fast demo and a late invoice for undefined processes.
How GMI runs a B2B storefront project
We start with DDT: buying process, roles, catalogue, pricing, ERP/PIM/WMS, mobile, analytics, security and maintenance cost. Then we design architecture, and only then close fixed price.
A typical GMI stack: MedusaJS v2 as commerce core, Next.js as storefront, NestJS or custom modules for company rules, PostgreSQL, Redis, queues, ERP/PIM/WMS integrations, monitoring and checkout tests. If the client has a mobile plan, we design the API so React Native does not duplicate logic.
The goal is not to build the "most headless" platform. It is to remove a measured process constraint and give the client code and data ownership under the agreed delivery model.
Sources and further reading
Medusa Next.js Starter documentation: https://docs.medusajs.com/resources/nextjs-starter
Medusa storefront development: https://docs.medusajs.com/learn/storefront-development
Medusa Customer Module: https://docs.medusajs.com/resources/commerce-modules/customer
Medusa Pricing Module: https://docs.medusajs.com/resources/commerce-modules/pricing
Medusa Sales Channel Module: https://docs.medusajs.com/resources/commerce-modules/sales-channel
Medusa Cart Module: https://docs.medusajs.com/resources/commerce-modules/cart
Medusa Workflows: https://docs.medusajs.com/learn/fundamentals/workflows
Next.js Image Optimization: https://nextjs.org/docs/app/getting-started/images
Shopify B2B documentation: https://help.shopify.com/en/manual/b2b
Shopify B2B features: https://help.shopify.com/en/manual/b2b/getting-started/features
Shopify B2B catalogues and pricing: https://help.shopify.com/en/manual/b2b/catalogs/index
Adobe Commerce B2B shared catalogues: https://experienceleague.adobe.com/en/docs/commerce-admin/b2b/shared-catalogs/catalog-shared
Medusa B2B ecommerce guide: https://gmi.software/blog/medusa-b2b-ecommerce-guide
MACH B2B ERP/PIM integrations: https://gmi.software/blog/mach-b2b-ecommerce-integrations-erp-pim
Frequently asked questions
- Is MedusaJS + Next.js enough for B2B ecommerce?
- Yes, if B2B means owned price lists, sales channels, customer groups, cart and integrations, not a packaged enterprise suite with every module prebuilt. A production project still needs ERP/PIM/WMS, cache strategy, checkout tests and an operating model.
- How much does a MedusaJS and Next.js B2B storefront cost?
- Cost depends on price lists, product-data quality, ERP/PIM/WMS integrations, approval flows and performance requirements. GMI gives an initial range after the first review and sets a fixed price only after workshops establish the process, data, scope and risks.
- Is the Medusa Next.js Starter suitable for production B2B?
- It is a good starting point, but not a finished B2B portal. You still need buyer roles, contract pricing, channel-based availability, integrations, monitoring, regression tests and customer-data isolation.
- How should MedusaJS connect to ERP in B2B?
- Not every storefront action should call ERP synchronously. We usually build a hybrid model: sync prices, stock and customers into Medusa/read models, validate synchronously only where an error blocks the order, and use queues, retries and alerts for exceptions.
- When should you not build a B2B storefront on MedusaJS?
- Do not build it if catalogue, checkout and pricing are standard and the team needs fast launch more than owned architecture. Shopify B2B, BigCommerce or headless-light can have better TCO in that scenario.
- Does the client own the code after a GMI project?
- Yes. After paid milestones we transfer rights to frontend and backend code. This matters in B2B because price lists, integrations and buying process are part of operating advantage, not just the shop appearance.
Content updated: September 4, 2026
Google Preferred Sources
See GMI more often in Google
Add gmi.software as a preferred source. Google may highlight our new articles more often in Top Stories and supported AI experiences.