Skip to content
PRS India

MACH · Composable · Headless

Headless & Composable Commerce

Headless commerce splits a fast custom storefront from the commerce engine. Composable commerce puts together the best tool for each job (a MACH stack) behind it. We build both. We make Next.js storefronts on commercetools, Medusa or a headless Shopify, with search, CMS and payments joined in. They are for brands that sell in many places and have truly outgrown a single platform. We will tell you if you have not.

Last updated

Start a project See related work
  • Next.js storefronts decoupled from the commerce engine
  • Composable MACH stack: best-of-breed, API-first, assembled
  • One catalogue and cart across web, app, kiosk and ONDC
  • commercetools, Medusa or a headless Shopify / BigCommerce engine
Why headless & composable

For the brand that sells everywhere at once.

There is a point where one platform tries to be your storefront, catalogue, search, content system and checkout. At that point it stops helping and starts holding you back. Headless commerce splits off the storefront. Then you can build any look and feel you like on top of one engine. Composable commerce goes further. You put together the best tool for each job (commerce, search, content, payments). You can swap any one later without rebuilding everything. That freedom is real. So is the cost. This setup pays off for brands that sell on web, app, in-store, marketplace and ONDC, and that have the tech team to run many connected parts. For everyone else it is costly and hard to manage. On the first call, the most useful thing we do is tell you honestly which kind you are.

Talk to a commerce architect
MACH
The composable model

Microservices, API-first, Cloud-native, Headless. The best part for each job, joined together, not one platform doing everything.

1engine
Many storefronts

One catalogue and cart for web, app, kiosk, marketplace and ONDC, from a single commerce backend.

0
Vendor lock-in

Swap any part, such as search, CMS or payments, without rebuilding the whole store.

BFF
One clean API

A backend-for-frontend gives one steady API, so the storefront never has to talk to five services itself.

How we actually approach headless and composable

Composable commerce is the most over-sold idea in shop technology. For the right business, it can change everything. The gap between those two is all about whether you needed it. Here is how we decide, and how we build it when the answer is yes.

We argue you out of it first

Honestly, most businesses asking for composable commerce would be better served by a well-built single platform or a simple headless setup. A composable setup adds to the number of systems you run, watch, protect and keep in sync. It also needs a platform tech team that many teams do not have and should not have to build. So the first thing we do is try to talk you out of it. If the reasons still hold, you can trust the build, because it was proven needed rather than sold.

Headless first, composable only if warranted

Going headless means a custom Next.js storefront on top of a commerce engine. It gives most of the front-end gain people want: a fast, custom look, Core Web Vitals you control, and one design across all touchpoints. You can do this on top of Shopify or BigCommerce and keep their steady, managed service. Full composability means swapping the single engine for a set of best-of-breed services. Take this step only when a single engine truly cannot serve your business, or when being able to replace any part without a rebuild is worth real money to you.

The engine choice: managed MACH or open-source you own

When composable is needed, the big choice is the commerce engine. commercetools is the main managed MACH platform. It is API-first and powerful, with a licence fee to match. It suits large companies that want the power without running the servers. Medusa is an open-source commerce engine you host and own fully. It suits teams that want composability without a per-order licence fee and have the tech skill to run it. We build on both. The right answer depends on your size, your team and whether you prefer to pay a licence or own it.

Orchestration is the whole discipline

The big risk of composable commerce is the distributed monolith. This is five services that must all be up for anything to work, with no clear owner of data matching and no view of which one is slow. We avoid it on purpose. A backend-for-frontend gives the storefront one steady API. Connections are asynchronous and idempotent, so a slow provider cannot break checkout. One part owns data matching between engine, search index and CMS, with checks rather than hope. And distributed tracing runs across the whole stack. Composability without this is all of the cost and none of the gain. This page exists to help you avoid exactly that.

The honest part

When to go composable — and when to stay put.

  Go headless / composable Stay monolithic
True omnichannel: web, app, in-store, marketplace, ONDC Yes. One engine for many touchpoints is exactly what it was built for. A single web storefront gains little and pays a lot for the extra freedom.
You have a platform engineering team Yes. A setup with many parts needs people to run it well. Without that skill, a single platform or managed headless is much safer.
Custom front-end experience matters Go headless. But you may not need full composability to get it. A themed single-platform storefront is enough for most brands.
Small catalogue, simple model, tight budget No. This is costly and hard to manage, and you do not need it. Shopify, Magento or WooCommerce. Launch and grow first.
You fear vendor lock-in at scale Composable lets you swap any part without a rebuild. At a smaller size, lock-in costs less than a setup with many parts.
Fastest time to launch No. Putting a stack together and making it work as one takes real time. A hosted single platform is live in a fraction of the time.
What we build

Headless and composable work we take on.

From a headless storefront on your existing engine to a fully assembled MACH stack.

Headless storefronts

A fast, custom Next.js storefront on top of Shopify, BigCommerce or a dedicated engine, using the Storefront API. This is the best first step.

Composable architecture

A full MACH stack put together: commerce engine, search, CMS and payments. Each is the best pick for its job, and each can be swapped without a rebuild.

commercetools builds

The main managed MACH platform, set up and connected, for large companies that want the power without running the servers.

Medusa builds

An open-source commerce engine you host and own fully, for teams that want composability without a per-order licence fee.

Backend-for-frontend

A layer that joins the services and gives the storefront one clean, steady API instead of making it talk to five services.

Search & discovery

Algolia or a similar engine connected for instant search that forgives typos, with filters and product display, across every touchpoint.

Omnichannel & ONDC

One catalogue and cart for web, app, kiosk, marketplace and the ONDC network, from a single commerce backend.

Observability & tracing

Tracing and monitoring across the whole stack, so a slow checkout points to one service and not a guess.

Monolith to headless migration

A move off a single platform in steps, storefront first, with URLs 301-mapped and the engine split off, with no sudden big switch.

India, specifically

Composable commerce in the Indian context.

India adds touchpoints and rules that make the case for selling everywhere stronger. They also make careful joining of the parts more important.

  • ONDC is a composable network

    The Open Network for Digital Commerce is itself an API-first, split-apart model. A composable stack fits ONDC easily, as one more touchpoint on the same engine.

  • UPI and Razorpay as a layer

    Payments are a part you can swap: Razorpay, Cashfree or a set of providers. UPI intent, cards and wallets sit behind one clean payments API.

  • GST across touchpoints

    One tax and invoice service applies HSN-based CGST/SGST/IGST and e-invoice IRN the same way, whether the order came from web, app or ONDC.

  • Web, app and in-store as one

    A single catalogue and cart behind a headless engine keeps online and shop sales truly as one, not matched up later.

  • WhatsApp as a channel

    Chat-based selling and alerts on the WhatsApp Business API, treated as another front end on the same commerce engine.

  • Data residency and the DPDP Act

    Where the law or a buyer needs it, parts are chosen and hosted so customer data stays in your region, and the answer on rules is honest.

How we ship it

Storefront first, engine decoupled, never big-bang.

A composable move that tries to replace everything at once fails. We do it in steps.

  1. 01

    Justify the architecture

    Weeks 1–2

    We test hard whether you need composable at all. We compare the cost with a single platform or simple headless. We go ahead only if the reasons hold. You get a choice you can defend, not a build you were sold.

  2. 02

    Decouple the storefront

    Weeks 3–10

    A Next.js storefront goes in front of the existing engine using its Storefront API, with URLs 301-mapped. You get the front-end gain right away, before any back end is touched.

  3. 03

    Compose the back end, one service at a time

    Weeks 8–22

    Search, CMS and payments come in as swappable parts behind a backend-for-frontend. Each has its own owner for data matching and its own idempotent connection. Never all at once.

  4. 04

    Instrument, and add touchpoints

    Weeks 20–34

    Tracing and data checks across the stack. Then new channels (app, ONDC, in-store) are added on the same engine, now that the base can be trusted.

The stack

What a composable build is assembled from.

The best part for each job, joined through a careful layer that makes them work as one.

Next.js
React
TypeScript
Vercel / Edge
The trap

The distributed monolith, and how we avoid it.

The worst result of a composable project is not a build that fails to launch. It is one that launches and then slowly turns into a distributed monolith. That means five services that must all be healthy for anything to work, no single owner of data matching, and no way to see which one is slow when a customer complains. You pay all the cost of composability and get none of the gain.

We plan against it from the first sprint. A backend-for-frontend means the storefront depends on one API, not five. Asynchronous, idempotent connections mean a slow provider slows down gently instead of breaking checkout. One part owns data matching between the engine, the search index and the CMS, and it checks instead of hoping. Tracing across the whole stack shows where the slowness is. This careful work is what you really get. The list of parts is the easy bit.

  • A backend-for-frontend, so the storefront sees one API
  • Idempotent, async connections that slow down gently
  • One owner of data matching across services
  • Tracing so you can see where slowness is
Proof

Headless and composable commerce we build.

Brands selling everywhere on one engine, without the extra cost of a distributed monolith.

All case studies
01
Turant Logistics — Logistics & Supply Chain

Cutting order-to-dispatch by 62% for a 400-truck 3PL

A fleet, ePOD and route-planning platform that works offline first, for drivers on roads with poor signal. The two ready...

62% faster
Faster order-to-dispatch on the ops floor
91% shorter
Shorter POD-to-invoice cycle (8.4 days to 19 hours)
18% lower
Fewer empty-run kilometres in the first full quarter
02
FealDeal — E-commerce — Ethnic Fashion

A high-catalogue ethnic-wear storefront for FealDeal

A Shopify store for a Surat ethnic-wear label. It has 200+ SKUs of lehengas, sarees and suits, sorted by type, colour, f...

Shopify
Platform
200+ SKUs
Catalogue
Mobile-first
Storefront
03
Collection by Rehan — E-commerce — Watches & Accessories

A brand-led watch and eyewear store for Collection by Rehan

A Shopify storefront for a Surat watch and eyewear retailer — where shoppers can browse by gender, brand, style and comb...

Shopify
Platform
Brand & style
Browse by
COD-ready
Checkout
FAQ

Headless and composable, answered straight.

Still have a question?

Headless means splitting the storefront from the commerce engine and joining them over an API, so you can build any front end on top of one backend. Composable goes further. Instead of one platform behind that API, you put together the best tool for each job: a commerce engine, a separate search provider, a separate CMS and a separate payments layer. All are joined by APIs. Composable is usually described as MACH: Microservices, API-first, Cloud-native, Headless. Headless is a choice about the front end. Composable is a choice about the whole back end. You can be headless without being composable, and we often recommend exactly that.

Probably not yet, and that is the most useful thing we can tell you. Composable is truly powerful and truly costly, in tech work, in joining the parts, and in the number of moving parts to watch and keep in sync. It pays off for large businesses selling on web, app, in-store, marketplace and ONDC, with the tech team to run it. For most stores, a well-built single platform or a simpler headless setup gives most of the gain at much less risk. We lead with that honesty because a composable build sold to a business that did not need one is a very expensive mistake.

A typical stack is a Next.js storefront, a commerce engine (commercetools for managed MACH, Medusa for an open-source engine you own), a dedicated search layer such as Algolia, a headless CMS such as Sanity or Contentful, and a payments layer such as Razorpay or Stripe — orchestrated through a backend-for-frontend that presents one clean API to the storefront. The point of composability is that any component can be swapped without replatforming the whole store, so you are never again captive to a single vendor's roadmap.

Yes, and for many businesses this is the sweet spot: keep the managed reliability of Shopify or BigCommerce as the engine, and put a fast, custom Next.js storefront in front via the Storefront API (Shopify Hydrogen or BigCommerce Catalyst are the vendor-blessed paths). You get the bespoke front-end experience of headless without the full complexity and cost of a composable back end. It is often the right first step, and sometimes the right destination — you do not have to go all the way to MACH to get most of what you came for.

By treating the joining of parts and the watching of them as top jobs from day one. A backend-for-frontend gives the storefront a single stable API rather than five services to juggle. Connections are asynchronous and idempotent, so one slow provider cannot break checkout. One component owns data consistency between engine, search index and CMS, with reconciliation rather than hope. And distributed tracing runs across the whole stack, so slowness points to a service rather than a guess. Composable without this discipline is how you get a distributed monolith with all the cost and none of the benefit.

A headless Next.js storefront on an existing Shopify or BigCommerce engine is typically 10 to 16 weeks from around INR 14,00,000. A full composable build — engine, search, CMS and payments assembled with orchestration and observability — runs 20 to 36 weeks and starts around INR 30,00,000, plus the SaaS licences of the components you choose. The variable is how many systems are composed and how omnichannel you truly are. We scope that hard in a paid discovery, because this is exactly the architecture where a number given too early is one someone regrets.

Considering headless or composable? Let us pressure-test it first.

Tell us your touchpoints, your catalogue and your team. A commerce architect replies within one business day. If a single platform or a simple headless setup suits you better, we will say so before you spend on a MACH stack you did not need.

Start a commerce project See our work
+91 93102 49840 aditi@prsindia.in

Proof

Shipped, measured, still running.

All case studies

Related services

Web Development

Live web applications built on Laravel, Next.js and Postgres. They are typed, tested, easy...

Explore

Mobile App Development

Flutter, React Native and native apps that keep working offline, on old phones and on a me...

Explore

Ecommerce Development

Commerce platforms where the checkout turns visits into sales and the back office numbers...

Explore

Let's talk headless & composable commerce

Bring us the hard version of the problem.

A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.

Start a project