Headless commerce explained for Indian brands

Headless commerce means the storefront your buyers see is built separately from the system that runs products, stock, orders and payments, and the two talk through an API. It is worth it when you need a front end a theme cannot give you, such as a mobile app or a content led site, and you have a team to maintain it. For most Indian brands, a good theme with custom modules does the job at lower cost and with less upkeep.

The plain explanation

Every online store has two halves. The back end holds the catalogue, prices, stock, customers and orders, and talks to the payment gateway and couriers. The front end is what buyers see: product pages, cart and checkout.

In a traditional store, both halves come from one platform, and the front end is a theme. In a headless store, the front end is a separate application, often built with a modern web framework, and it asks the back end for data through an API. The back end becomes the "engine"; the front end can be anything that can call that API.

What headless lets you do

• Build a storefront with a design and interactions no theme supports.
• Serve the same catalogue to several front ends: a website, a mobile app, an in store kiosk, a dealer portal.
• Mix commerce with a content system, for brands whose pages are mostly editorial with products inside.
• Change the front end without touching orders and payments, and the other way round.

What it costs you

Headless moves work onto your side.

• Two systems to run. The front end needs its own hosting, monitoring and updates, in addition to the commerce back end.
• Features you rebuild. Search, filters, the cart, account pages and SEO tags that a theme gives you must be built and maintained in the front end.
• A team for the long term. Someone has to fix the storefront when a browser update breaks the checkout button during a festive sale.
• SEO care. A front end that renders pages only in the browser can hurt search visibility. Server rendering solves this, and it has to be set up deliberately.
• Slower changes for non technical staff. Merchandisers may need a developer for page changes they could make themselves in a theme.

None of this makes headless wrong. It makes it a decision with a running cost, which you should be able to name before you start.

When headless is worth it

You need more than one front end

If you are building a mobile app, a dealer portal and a website on one catalogue, one engine with several front ends avoids keeping three copies of the stock in step.

Your storefront is the product

Some brands sell through an experience: a configurator for custom furniture, a fabric visualiser, a content heavy site where stories carry the products. If a theme cannot deliver that experience, headless may be the right route.

You have, or will fund, a front end team

The question is less "can we build it" and more "who maintains it for the next three years". If the answer is clear, headless is viable.

When it is not

• Your catalogue and checkout are standard, and the goal is a nicer look. A well designed theme and custom styling cost much less.
• You do not have developers and do not plan to hire them.
• The real problem is operations: stock that goes wrong, COD returns, slow order processing. A new front end does not fix any of those.
• You want speed to launch. A headless storefront takes longer to build and test.

A middle path: extend the engine

Many brands that consider headless actually need specific logic: dealer pricing, subscription baskets, a custom product builder, a Tally sync. These can live inside the platform as modules, with the standard storefront kept for everything else.

ShopenUp supports both routes. API access, webhooks and custom modules are native, so a separate front end or app can read the catalogue and create orders, and outside systems can react to events such as a new order or a stock change. If you stay on the hosted storefront, mobile themes work on day one, and custom storefront branding is built for you as custom work. See API and extensions and storefront.

As an illustrative example, a Bengaluru electronics accessories brand wants a compatibility finder: pick your phone model and see the cases and chargers that fit. That can be built as a custom module on the standard storefront, without moving to headless. If the same brand later launches a mobile app, the app can use the same catalogue and orders through the API.

How to start small if you do go headless

You do not have to rebuild the whole storefront at once. Many brands start with one front end where the need is clearest, such as a mobile app or a single configurator page, and keep the standard storefront for browsing and checkout. Once that part has run through a busy season, you know the real cost of maintaining it and can decide whether to move more pages.

Keep checkout on the platform for as long as you can. Checkout carries payment, tax, COD rules and order notifications, and it is the part where a fault costs the most. A front end that hands the buyer to the platform's checkout keeps that risk low.

Questions to ask before you go headless

• Which specific buyer experience can our current theme not deliver?
• Who builds the front end, and who maintains it after launch?
• How will pages be rendered for search engines?
• What happens to checkout, payments and order notifications?
• What is the yearly cost of hosting and maintaining the front end?
• Could a custom module on the existing storefront solve the same need?

Data and security

A separate front end is another system that handles shopper data, which is personal data under the DPDP Act, 2023. Keep API keys on the server side, limit what each key can do, and log access. Card data stays with the payment gateway, which carries its own PCI DSS obligations. For your duties as a store owner, read shopper data and the DPDP Act, and confirm specifics with your lawyer.

Cost and next steps

Custom work on ShopenUp, including modules and storefront branding, is built by the Code Colonies technology team at INR 199 an hour with a 150 hour minimum, paid after you accept the work. The platform itself is on pricing, and the trade offs between builders, platforms and custom code are in store builder, platform or custom build. Terms such as API and webhook are in the glossary.

Book a demo to see the API, webhooks and a custom module working on a store like yours.