Ecommerce platforms get a bad reputation in modern web circles. Magento is heavy. Shopify locks you in. WooCommerce is a plugin graveyard. The instinct, especially among teams comfortable with React, is to rebuild the cart from scratch in Next.js, throw Stripe behind it, and call it lean.
That instinct is usually wrong. Rebuilding ecommerce primitives means writing — and then maintaining — the worst parts of an ecommerce platform: inventory consistency, tax calculation per jurisdiction, refund logic, abandoned-cart recovery, customer accounts with order history, and a dozen other concerns that are uninteresting until they break. The platforms have a decade head start on all of them.
The work is the seam, not the build
What an ecommerce engagement actually is: a brand and a storefront experience that's specific to the product, glued to an ecommerce engine that handles the boring parts. The interesting decision is where to cut the seam. We've shipped enough variations on this — Pentamart on PostgreSQL + Node, Funflowers on OpenCart, biofideX on Postgres + tRPC — that the seam has shape now.
For Al-Bayt Elegance — a modest Islamic fashion brand in Dhaka serving bilingual EN/বাংলা shoppers with cash-on-delivery as a first-class payment method — the seam landed on a headless Next.js storefront over Magento. Here's what each side does and why the boundary lives where it does.
What Magento owns
- Catalog: products, variants, categories, price rules.
- Orders: cart state, checkout flow, payment provider integration, order history.
- Inventory: stock, reservations, low-stock alerts.
- Taxes: per-region rules, applied at quote and checkout.
- Customer accounts: signup, login, password reset, address book.
- Refunds and returns: a UI flow the merchant can operate without code.
Every item above is a primitive that's been built, broken, and rebuilt in Magento for fifteen years. We didn't touch any of it. The merchant operates these the way they always did, through the Magento admin.
What Next.js owns
- Every customer-facing page: home, category, product detail, search, checkout funnel, account dashboard.
- Brand expression: typography, motion, layout grids, photography treatment, microcopy.
- Bilingual content delivery: EN/বাংলা with one canonical URL per page, hreflang annotations, language switcher.
- Performance: static generation for product pages with on-demand revalidation; cart state hydrated dynamically against Magento's GraphQL API.
- Cash-on-delivery as a first-class payment option, not a 'more options' checkbox.
The seam itself
Next.js talks to Magento over GraphQL. Product detail pages render statically at build time with ISR; category pages revalidate every 5 minutes; cart and checkout are dynamic. The GraphQL queries are scoped to exactly what each page needs — no over-fetching, no waterfalls. A typical product page makes one query at render time and ships under 50KB of JS.
When a customer adds an item to cart, Next.js hits a Magento GraphQL mutation, gets back an updated cart object, and renders it. The cart state is Magento's source of truth, not Next.js's. This matters when the customer comes back the next day from a different device — their cart's still there because Magento never lost it.
The COD reordering — the change that paid for itself
The first checkout iteration asked for full delivery address before payment selection. COD-first shoppers — the majority of the catalog, in this market — bounced when they saw a long form before any trust signal. We re-sequenced the steps: payment method first, then address, then confirmation. COD completion rose materially in the first two weeks after the change.
When this pattern works
Headless on top of an existing engine works when the storefront experience is the differentiator and the ecommerce engine is competent at the primitives. That's most consumer ecommerce. It does NOT work when the engine's data model is fundamentally wrong for your product — say, a marketplace with per-vendor payouts that Magento doesn't model natively. For Pentamart we built a custom Node/Postgres engine because Magento's vendor model is a paid extension that doesn't fit Bangladesh's multi-vendor combined-cart logistics. Different shape; different cut.
The lesson, if there is one: the framework question isn't 'should we use Next.js or Magento.' It's 'what does your storefront need to express that the platform can't?' Build that part in Next.js. Adopt the rest.
If you're staring at a Magento or Shopify rebuild and trying to figure out whether to go headless, the discovery call is the cheapest way to map the seam for your specific product.