Next.js storefronts that are not theme shells

“We need a Next.js storefront” often means three different projects:

1. A marketing site that pretends to be a store
2. A thin headless theme over Magento GraphQL
3. A real product surface with performance, a11y, and conversion paths owned by engineering

We only care about the third.

What a real Next.js commerce front does

• PDP and PLP that are fast under real catalog sizes
• Cart and checkout wired to Magento, Medusa.js, or Vendure - not mock JSON
• Auth and account with a login migration plan if you replatformed
• SEO - metadata, structured data, canonicals, and redirects as code
• Content - Sanity, Contentful, or headless WordPress for editorial, not blog posts stuffed into the cart DB

If the repo is mostly UI kit demos and a single “buy” button, it is not an enterprise storefront yet.

CMS split (the decision people skip)

WordPress Multisite or headless WP is still valid when editorial lives in WP. Sanity and Contentful win when content models are product-like and multi-channel.

Magento GraphQL first, engine second

A common phased exit from Magento 2 or Adobe Commerce:

1. Next.js against Magento GraphQL (stabilize UX)
2. Move catalog to Medusa.js or Vendure
3. Move checkout, then decommission Magento

That only works if inventory ownership and order truth are designed up front.

TypeScript and design systems

Enterprise Next.js is not “drop Tailwind and ship.” It is:

• Typed API clients
• Shared UI that marketing cannot accidentally break
• Environments, previews, and cache tags that match how content ships

See our Next.js practice for the scope we take on.

Start here

If you already have Magento or a next-gen engine and the front is the bottleneck, bring:

• Current Lighthouse / RUM on key templates
• Checkout funnel drop-offs
• CMS ownership map

We will tell you whether the fix is storefront engineering, commerce engine work, or both. Contact us.