Two platforms replaced by one storefront the brand controls end to end

Pashmina.com ran commerce on Magento and editorial on WordPress. Nanostuffs replatformed both onto VTEX headless with a Next.js storefront in front, joined by a GraphQL middleware layer built before the pages that would depend on it.

A pashmina shawl has always been sold in the hand — its weight, its warmth, the way a real one passes through a ring. Online, nobody can touch anything. The storefront has to do the work the hand used to do.

Pashmina.com logo
Pashmina.com logo
Luxury Craft Retail · VTEX Headless + Next.js · 8 Languages

How the headless storefront works

Video coming soon

At a glance

32 → 75
Google PageSpeed, before and after
85%
of sales come from overseas buyers
45%
of customers come back and buy again
8
languages, so buyers shop in their own

Client

Pashmina.com LLP, New Delhi — handwoven Kashmiri pashmina, certified by the Ministry of Textiles, shipping worldwide

Challenge

Commerce on Magento, editorial on WordPress, and a storefront that couldn't carry the brand's proof of authenticity

Solution

VTEX as the headless commerce engine, a Next.js storefront, and a GraphQL middleware layer between them

Result

Commerce and content unified into a single headless platform, with PageSpeed up from 32 to 75, for a business with 85% international sales

The Challenge

Two platforms, one brand, and a product that sells on proof

Pashmina.com is a New Delhi–headquartered luxury house built on a craft rather than a category. The fibre comes from the underbelly of Changthangi goats grazing at high altitude in Ladakh; artisans in Kashmir hand-spin and hand-weave it into shawls, wraps and scarves using techniques — Kani, Jamawar, Sozni, Kalamkari, Zari and Tilla — where a single piece can take months. The company works with more than a hundred artisan families, reinvests a share of every sale back into them, and has each piece tested and certified by the Crafts Development Institute under the Ministry of Textiles.

In this category, the storefront is not a shopfront; it is the evidence. Eighty-five per cent of the business comes from outside India, which means the persuading happens at a distance — to a customer who cannot touch the fabric, often reading in a second language, deciding whether a piece worth hundreds is genuine. Machine-made blends are sold worldwide under the same word, so that is the one question standing between them and the purchase. And with forty-five per cent of customers returning, the experience is not a single transaction to get right; it compounds.

The systems underneath were working against that. Commerce ran on Magento, while the editorial library — the asset carrying much of the organic traffic and most of the authenticity argument — lived separately on WordPress. Two platforms, two content models, and a storefront experience assembled across a seam the customer could feel. It was also slow. The storefront scored 32 out of 100 on Google PageSpeed Insights when the engagement began — a number that costs most on exactly the traffic this business runs on: international buyers, on mobile connections, a long way from the server.

Engagement Snapshot

Industry
Luxury craft retail
Headquarters
New Delhi, India
Markets
Worldwide, 8 languages
Migrated from
Magento + WordPress
Commerce engine
VTEX (headless)
Storefront
Next.js, App Router
Certification
Ministry of Textiles (CDI)
Why VTEX Headless + Next.js

Why the commerce engine moved, and why the storefront left the platform entirely

Two decisions sat inside this project, and they are worth separating because most replatforms only make the first one. The first was to consolidate commerce onto VTEX. The second, harder decision was not to use VTEX's own storefront layer at all.

VTEX exposes its commerce capabilities as headless APIs, which means the catalog, pricing, promotions, cart and order lifecycle can be driven by a frontend the brand owns outright. For a commodity retailer, that freedom is a luxury. For a house selling handwoven pieces at luxury prices, it is the whole argument: the storefront is doing the persuading that a shopkeeper unfolding a shawl across a counter used to do. Provenance, weave detail, artisan story and government certification all have to be designed, not slotted into a template's product-page fields.

So the line was drawn deliberately. Anything that is genuinely commerce logic stays in VTEX, where it is maintained by people whose job is maintaining it. Everything the customer sees, and everything determining how quickly they see it, moves into a Next.js codebase.

What VTEX Headless + Next.js handles natively

  • Catalog, product hierarchy and specifications, modelled during migration to fit the brand's craft taxonomy rather than a generic apparel structure
  • Pricing, promotions, coupons and discount rules, including product- and category-level offers
  • Cart and order lifecycle, checkout, and the connector layer into payment providers
  • Storefront content and media through VTEX CMS

Where custom engineering was needed

Considerably more than the platform's marketing suggests. Social login isn't exposed through the headless APIs, payment connectors carry their own constraints, and VTEX CMS has no blog or article model — which matters for a brand whose organic traffic depends on long-form editorial. That gap is the subject of the Hard Problem section below.

The Platform

What we built

01 · Layer

VTEX, headless

Catalog, product specifications, pricing, promotions, cart, checkout and order lifecycle, with the merchandising team working in the VTEX admin. Categories were bulk-imported by CSV against an architecture mapped to VTEX specifications first.

VTEX

02 · Layer

A GraphQL layer, built first

A single translation layer between platform and website — and the one place every platform gap and workaround lives. Change something here and the whole site follows; change the platform and only this layer has to adapt.

GraphQL

03 · Layer

Next.js, App Router, TypeScript

The customer-facing experience, owned outright by the brand rather than bounded by platform templates — so provenance, craft detail and certification can be designed rather than squeezed into fixed product-page fields.

Next.js
The Hard Problem

Headless VTEX gives you the commerce engine, not everything the storefront was doing

Every platform is sold on what it can do. What rarely comes up in the sales cycle is how much of that only works if you also use the platform's own website templates — and this project deliberately did not.

The gaps surfaced one at a time. Letting customers sign in with a Google or Facebook account is a single settings screen on a standard VTEX store; on a custom storefront it simply is not offered, and had to be built from scratch. Payment connection problems during integration forced a change of payment provider partway through the build. And the platform's content tools, capable as they are for shop pages, cannot host a blog at all — which for a brand whose customers arrive through articles on how to identify real pashmina is not a detail.

Each of those is a mid-project surprise, and mid-project surprises are where budgets and launch dates go. The instinct is to solve each one where you find it. That works until the fourth or fifth, at which point the fixes are scattered across the site and every future platform update risks breaking them all at once.

Going headless doesn't just remove the storefront. It removes everything the storefront was quietly doing for you.

The alternative was to go looking for the gaps before building on top of them. In the first fortnight the team mapped what the platform would and would not do through its connection layer, deliberately ahead of feature work, so the surprises arrived during planning rather than during delivery. A single translation layer was then built between the platform and the website, and every gap, workaround and custom piece was put there. The website was built against that layer rather than against VTEX directly — which is why changing payment provider halfway through cost days instead of derailing the schedule, and why the brand is not locked to today's platform behaviour tomorrow.

Before

  • Commerce on Magento, editorial on WordPress — two platforms, two content models, one seam the customer could feel
  • Google PageSpeed 32, recorded at the start of the engagement
  • Every platform gap solved wherever it was found, in page code

After

  • One headless commerce engine on VTEX, one Next.js storefront the brand controls outright
  • Google PageSpeed 75 — 43 points gained on the same measurement
  • Platform quirks contained in a single GraphQL middleware layer rather than spread through page code
The Approach

How we delivered it

Roughly six months from handover to launch, with the unglamorous foundation work deliberately done first.

01

Take over without starting over · Oct 2023

The brand already had a partly-built storefront. Restarting would have cost months and thrown away work already paid for. Instead the existing codebase was stabilised and brought up to current standards inside the first week, and a performance score was recorded on day one — 32 on Google PageSpeed Insights — so every improvement afterwards could be measured against a real starting point rather than claimed.

02

Structure the catalogue around how people buy · Oct–Nov 2023

A handwoven shawl is not a t-shirt. Customers shop by craft — Kani, Jamawar, Sozni — and by occasion, not by generic apparel categories. That structure was designed and agreed before a single product was loaded, because changing it later means redoing product data, page addresses and search rankings together. The merchandising team can now run the catalogue themselves, without a developer in the loop.

03

Build the foundation before the shop floor · Oct 2023–Feb 2024

The connection layer between the commerce platform and the website was built first, ahead of any page a customer would see. It produced nothing visible for two weeks and it is the reason the rest of the project stayed predictable: when the payment provider had to change partway through the build, it was a contained change rather than a rebuild. Pages followed — homepage, product browsing, product detail, accounts, basket and checkout.

04

Turn a website into a working business · Feb–Apr 2024

Payments, international shipping through FedEx and DHL, cancellations and refunds, promotions and gift cards, customer reviews and marketing tools. Then the step most replatforms underestimate: mapping every old web address to its new one, so years of accumulated search visibility survived the move. Tested with the client, and released in April 2024.

The Outcomes

What changed for Pashmina.com

Real numbers only — pending metrics await client-approved data.

32 → 75

Google PageSpeed, measured the same way at both ends

+43

points gained on the same measurement

2 → 1

platforms, one place to run the business

8

languages live, including Arabic with full right-to-left support

Consolidated commerce and editorial from separate Magento and WordPress platforms into a single Next.js and VTEX headless architecture, more than doubling storefront PageSpeed from 32 to 75 — for a business where 85% of sales come from international exports and 45% of customers return.

Stack
VTEXVTEX Headless APIsVTEX CMSNext.js (App Router)TypeScriptReactGraphQLVercelFedExDHLVTEX Live Shopping
Questions & Answers

VTEX Headless + Next.js — common questions

Considering a headless replatform?

The gaps are knowable before you commit. Let's map what your platform will and won't give you headless — and where the middleware line should sit.

Discuss a Headless Replatform

Explore our Full-Stack AI Engineering, or start with a scoped AI Sprint.