Headless CMS in India: Real Costs Nobody Puts on the Pricing Page

Nilaya is a D2C skincare brand out of Bengaluru with a content team of two and a founder who reads a lot of engineering blogs. She came to us with a headless CMS comparison spreadsheet she had built herself: five vendors, monthly price, API limits, a tick-box column for image handling. Tidy work. It was also missing about 70% of what the project would actually cost her.

That gap is the whole point of this piece. A headless CMS comparison built on pricing pages will tell you which vendor charges less per seat. It will not tell you why the same project comes in at three times the budget once it is live. Let's walk Nilaya's numbers, illustratively, and put the hidden lines on the table.

What the Pricing Page Tells You

Seats, API calls, records, locales, environments. All real constraints, all easy to compare, and all secondary. Vendors compete on these numbers precisely because they are the cheap part of your project. Nobody puts "your developers will rebuild the entire rendering layer" on a pricing page.

The Costs a Headless CMS Comparison Usually Misses

Somebody Has to Build the Front End

This is the line that surprises people who came from WordPress. A traditional CMS ships a theme layer. Headless ships JSON. Every page type, every component, every empty state, every 404 and every sitemap has to be written. That is not a criticism; it is the deal you are making in exchange for control and reuse.

The practical consequence for an Indian SMB is that your CMS choice barely moves the budget, while your front-end framework and your component discipline move it enormously. Which is why a headless CMS comparison that ignores your development team is comparing the wrong variable.

Preview Is a Project, Not a Toggle

Editors want to see the page before they publish it. In headless, preview means running a draft-aware version of your front end, wired to draft API tokens, with its own hosting and its own cache rules. Every vendor supports it. None of them build it for you.

Nilaya's team lost three weeks here, not because it is hard, but because nobody had scoped it. Add scheduled publishing and multi-locale drafts and it grows again. Any honest headless CMS comparison should have a column for how much preview scaffolding the vendor's SDK actually gives you.

Editor Training and the Adoption Cliff

Here is the failure mode we see most. The build ships, it is fast, the developers are pleased, and six weeks later the content team is back to asking a developer to publish things for them. Structured content asks editors to think in fields and references instead of in a page. That is a genuine skill change and it needs training, written documentation and at least one person internally who owns the content model.

• Field-level help text written for every content type
• Two recorded walkthroughs, one for publishing, one for a new landing page
• A named content-model owner on the client side
• A sandbox environment editors can break safely
• A written rule for when a change needs a developer

A Headless CMS Comparison Scorecard That Works

Score each vendor out of 5 on these, weighted as shown. Notice that price is one line out of eight.

The Speed Claim in Every Headless CMS Comparison

It might make the site faster. It might also do nothing, and that is worth understanding before it becomes a budget line. Going headless removes the plugin-rendered markup that drags a typical WordPress page, so the floor rises. The ceiling is set entirely by your front end. A React build with three analytics scripts, an unoptimised hero image and a client-side fetch for navigation will lose to the site it replaced.

Speed comes from the image pipeline, a strict third-party script budget and a sane rendering strategy. All three are available on a traditional CMS too. If performance is the main argument in the pitch, you are paying several lakh for something a fortnight of optimisation would have delivered. Treat speed as a tiebreaker, not as the reason.

What It Looks Like When It Goes Wrong

Nilaya's near miss is the most useful part of her project. Her first content model kept "ingredients" as a free-text field on the product story, because that is how the old site displayed it. Nine months later, marketing wanted ingredient filtering and a landing page per hero ingredient. Free text does neither.

The repair: a new Ingredient content type, a reference field added to 140 product stories, three developer days for a mapping and migration script, then roughly two weeks of a content person checking every record by hand. Call it ₹1.6 lakh of work and a delayed campaign, all of it flowing from one field decided in an afternoon eleven months earlier.

That is the shape of nearly every headless regret we see. Not the vendor, not the subscription, the model. Which is why content model fit carries the heaviest weight on the scorecard above, and why a headless CMS comparison run without modelling your hardest page types is really just a comparison of marketing sites.

When Headless Is the Wrong Answer

If you have one content editor, twelve pages and a blog, headless is an expensive way to solve a problem you do not have. If you have no in-house developer and no retainer, you are buying a system whose every change requires one. And if your content model is genuinely a page with a headline and some paragraphs, structured content adds ceremony without adding reuse.

Headless earns its keep when the same content feeds several surfaces: a website, an app, in-store screens, a partner feed. That is the real qualifier, and it belongs at the top of any headless CMS comparison you run.

What Nilaya Actually Spent

Her spreadsheet said ₹11,000 a month. The first-year reality landed near ₹6 lakh once the front end, the migration of 140 product stories, the preview setup and two training sessions were counted. She would still make the same choice, because her content now feeds the website, the app and a retail partner feed from one place. But she would have negotiated the retainer up front.