Headless describes software that has a body without a head. The body is the back end, where products, content, orders and customers are stored and where the business rules run. The head is the front end, the website or app people actually see and click. In a headless setup, the two are separated, and the front end gets everything it needs from the back end through an API.

The word comes up when founders talk to agencies, when brands compare ecommerce platforms and when developers pitch a "modern stack". This page explains what headless means in plain words, how headless commerce and headless CMS work, what they cost and how to tell whether your business needs one.

What is headless?

In a traditional, or coupled, platform, the admin where you manage products and the website that displays them come as one package. You pick a theme, edit it and publish. The platform controls both sides.

In a headless platform, the back end has no website of its own. It exposes its data and actions through an API, and a developer builds the front end separately, often with a modern framework like Next.js, Nuxt or Astro. The same back end can then feed several heads at once, such as a website, a mobile app, a kiosk in a store, a smart TV app or a partner's site.

You will meet the word in a few combinations.

  • Headless commerce: an ecommerce back end (catalog, cart, checkout, orders) used without its default storefront. Examples include commercetools, BigCommerce used headless, or Shopify with a custom front end built on its Storefront API or its Hydrogen framework.
  • Headless CMS: a content management system that only stores and serves content, such as Contentful, Sanity, Strapi or Payload. Developers decide how and where the content appears. Our CMS entry explains the traditional side.
  • Composable commerce: a step further, where a business assembles several specialized headless services (search, CMS, checkout, reviews) instead of one platform.
  • Headless browser: a different meaning. It is a web browser that runs without a visible window, used by developers for automated testing, screenshots and scraping. Chrome and Firefox both have a headless mode.
  • Headless server: a computer that runs without a monitor, keyboard or mouse, managed remotely.

Headless is not the same as API-first design. API-first describes how a product is built, with the API designed first. Headless describes how you use it, with your own front end. API-first products make headless setups easier, but you can use them with their standard front end too.

Why it matters

Headless matters because it changes who builds and maintains your website, and therefore your costs and your speed.

Take a brand selling skincare with $40,000 a month in revenue. On a standard hosted store with a theme, the website is part of the subscription, maybe $39 to $300 a month, and the founder can change a banner in five minutes. If the same brand goes headless, a developer or agency builds a custom front end, often $20,000 to $80,000 for a first version, plus hosting and maintenance that can reach $1,000 to $3,000 a month. In return, pages can load faster, the design has no theme limits and the same catalog can feed a mobile app.

If that speed and freedom lift the conversion rate from 2.0% to 2.3% on 100,000 monthly visitors with a $60 average order, revenue rises by about $18,000 a month, and the investment pays back within a few months. If conversion does not move, the brand has added a large fixed cost and a dependency on developers for every change.

That trade-off, more control in exchange for more cost and complexity, is the heart of every headless decision.

How it works

A headless setup follows a simple flow.

  • The back end stores everything. Products, variants, prices, stock, content, customers and orders live in the commerce engine or CMS.
  • The API exposes it. The back end offers endpoints, often REST or GraphQL, such as "list products in this collection" or "add this item to the cart".
  • The front end asks for data. When a visitor opens a page, the website or app calls the API and receives the data it needs.
  • The front end renders the page. The developer's code decides the layout, design and interactions. Many headless sites pre-render pages in advance for speed.
  • Actions go back through the API. Adding to cart, logging in or paying sends a request back to the back end, which applies the business rules and stores the result.
  • Other heads reuse the same API. A mobile app, an in-store screen or a marketplace connector can use the same back end without duplicating data.

The checkout is often the trickiest part. Many headless stores keep the platform's hosted checkout because it handles payments, taxes and fraud checks securely, and only customize the pages before it.

Benchmarks and examples

  • Large retailers and fast-growing brands go headless to run a website, apps and stores on one catalog, to reach top page speed or to build experiences a theme cannot handle, such as product configurators.
  • Media and content-heavy brands use a headless CMS to publish the same articles on a website, an app and newsletters.
  • Agencies often recommend headless for projects above roughly $1 million in yearly online revenue, where a small gain in conversion covers the cost.
  • Creators and small stores rarely need headless. A hosted storefront with a theme or a link-in-bio page with checkout covers most needs at a fraction of the cost.
  • Build timelines for a first headless store typically run from 2 to 6 months, compared with a few days to a few weeks for a themed store.

Common mistakes

  • Going headless for the buzzword. If you have one website and a small team, you add cost without a clear benefit.
  • Forgetting ongoing costs. The build is only the start. Every new feature, app integration or design change now needs a developer.
  • Losing built-in features. Apps and theme features from the platform often stop working on a custom front end and must be rebuilt.
  • Ignoring the marketing team. If marketers can no longer edit pages or launch promotions without a developer, campaigns slow down.
  • Underestimating SEO work. Redirects, metadata, structured data and page speed must be handled carefully during the move.

Best practices

  • Start from a business reason. Write down what headless must achieve, such as a mobile app, faster pages or a second brand on the same catalog, and how you will measure it.
  • Check your numbers. Estimate the build and monthly costs, then calculate the conversion gain needed to pay them back.
  • Keep the hosted checkout if you can. It reduces security and compliance work and keeps payments reliable.
  • Give editors a visual tool. Pair the front end with a CMS so non-developers can update content and landing pages.
  • Plan the migration. Map every old URL to a new one, test speed and tracking, and launch in a quiet period.
  • Own your code and contracts. Make sure the front-end code, hosting accounts and documentation belong to your business.

In Roctify

Roctify is not something you need to go headless with. It gives you a ready front end, a link-in-bio page and a full storefront, both built on one shared catalog. Your products, variants, stock, prices, customers and orders are the same on every channel, and stock updates everywhere at once. That gives you the main benefit people look for in headless commerce, one back end feeding several channels, without paying for a custom front end or a development team.

Roctify does not offer a public API today. Businesses with advanced integration needs can discuss custom options on the Enterprise plan.

FAQ

What does headless mean in simple terms?

Headless means the part of a system that stores data and runs the rules is separated from the part people see. The visible website or app gets its data through an API. This lets one back end feed several front ends, but someone has to build each front end.

Is headless commerce worth it for a small business?

Usually not. A headless build often costs tens of thousands of dollars plus monthly maintenance, while a themed store or a link-in-bio store costs a small subscription. Headless starts to make sense when you have several channels, a technical team and enough revenue for a small conversion gain to cover the cost.

What is the difference between a headless CMS and a traditional CMS?

A traditional CMS includes both the editing interface and the website that displays the content. A headless CMS stores and serves content only, through an API, and developers build the website or app that shows it. Headless gives more freedom to reuse content across channels, but requires more technical work.