Headless CMS and composable commerce: what profile do you need?

For years, a large part of enterprise web projects was built around a central platform that managed content, presentation, and, in some cases, e-commerce functionalities. This model continues to be valid for numerous projects, but it begins to feel restrictive when an organization needs to operate multiple channels, integrate specialized tools, or evolve each component at different paces.

Headless CMS and composable commerce propose a different architecture. Content, the frontend experience, the e-commerce engine, and other services can function as independent components connected via APIs. This separation offers greater flexibility, although it also increases the importance of correctly defining integrations, responsibilities, and technical ownership.

Therefore, when a company decides to adopt a headless or composable architecture, the decision about talent is rarely resolved by simply looking for a “headless developer.” The right profile depends on which layer of the architecture needs to be built, integrated, or operated.

From a traditional CMS to a headless architecture

In a traditional CMS, the content management system and the layer that presents that content to the user are usually closely related. Editors manage information from the CMS, and the same platform determines how pages, templates, and components are rendered.

A headless CMS separates these responsibilities.

The CMS retains the management and structuring of content, while its distribution is done through APIs. The frontend can then be developed using technologies like React or Next.js and consume that content independently of the system used to manage it.

This separation allows for the reuse of the same content source across different experiences: a website, a mobile application, an internal platform, or any other channel capable of consuming the API.

For the tech team, the development model also changes. Frontend developers take control of an independent experience layer, while the CMS becomes another component within a broader architecture.

Headless CMS, headless commerce, and composable commerce are not the same

The three concepts are related, although they describe different levels of decoupling.

A headless CMS primarily separates content and presentation. Platforms like Contentful, Sanity, Contentstack, or Strapi can provide structured content via APIs for different applications to consume.

Headless commerce applies a similar principle to e-commerce. The engine responsible for products, cart, promotions, orders, or other commercial capabilities can operate independently of the frontend that the customer uses.

Composable commerce further expands this logic. The digital platform can be built by combining different specialized capabilities instead of relying on a single provider to solve all e-commerce needs.

The result can integrate components such as:

• CMS for content and editorial pages;

• commerce engine for catalog, cart, and orders;

• PIM for structured product information;

• DAM for multimedia resources;

• search and recommendation engine;

• payment, identity, or personalization services;

• independent frontend responsible for building the final experience.

This composition allows for selecting tools based on business needs, but each new component incorporates a relationship that must be designed, maintained, and monitored.

The CMS & e-commerce developer remains a central piece

Adopting headless does not eliminate specialization in CMS or e-commerce. It changes some of their responsibilities.

CMS & e-commerce developers can work on platform configuration, content modeling, catalog, extensions, editorial workflows, and commercial capabilities.

Content modeling becomes particularly important in a headless architecture. If the information is structured with a specific page in mind, part of the model's flexibility disappears. The content should be reusable from different interfaces without being overly dependent on how it is presented in one of them.

In e-commerce, a similar situation occurs. Products, variants, prices, promotions, and availability need a structure that can be consumed from the frontend experience and, when applicable, from other channels.

Knowledge of the platform remains necessary, but it must now coexist with a greater understanding of APIs and integrations.

The frontend developer controls a much more important layer

A direct consequence of decoupling is that the frontend is no longer conditioned by the CMS's template system.

This provides greater freedom to design experiences, optimize performance, and use modern frameworks, but it also shifts responsibilities to the frontend team.

The developer needs to manage API calls, loading states, caching, rendering, routing, editorial previews, and different page generation strategies. They must also consider what happens when any of the services used by the experience does not respond correctly.

In applications based on frameworks like Next.js, decisions about server-side rendering, static site generation, or hybrid strategies can affect performance, scalability, and SEO.

The frontend thus ceases to be merely a visual layer. It becomes one of the main integration points between content, commerce, and the user.

Integrations may require a backend developer

A relatively simple architecture may allow the frontend to consume certain APIs directly. As the number of systems increases, the need for an additional layer often arises.

Backend developers can develop services responsible for integrating platforms, transforming information, implementing business logic, or providing an API specifically tailored to the frontend's needs.

For example, a product page might need to combine information from the CMS, catalog, inventory, prices, and recommendations.

Performing all those operations directly from the browser can increase coupling between the experience and the providers used. A backend layer can centralize part of that logic and provide the frontend with a more stable interface.

Patterns like backend for frontend (BFF) can be useful when different experiences need specific data or behaviors.

This layer also allows for controlling authentication, caching, response aggregation, and certain security policies without transferring all the complexity to the client.

Composable commerce turns architecture into a strategic decision

When a company combines CMS, e-commerce, PIM, DAM, search, payments, identity, and other services, the project quickly exceeds the scope of an individual implementation.

Each platform can function correctly on its own and still produce an architecture that is difficult to maintain when the relationships between them are not well defined.

This is where the need for software architecture arises.

The architectural work consists of establishing what responsibility belongs to each system, how information is exchanged, and what the authoritative source is for each type of data.

If the price belongs to the commerce engine, for example, other components should avoid creating independent versions of that same information without a specific reason. The same applies to inventory, content, identity, or product information.

Defining ownership reduces inconsistencies and prevents different platforms from starting to assume overlapping responsibilities.

API-first needs stable contracts

In a composable architecture, APIs become an essential part of the technological product.

Changing the structure of a response or removing a field can affect frontends, mobile applications, integrations, and internal services. The evolution of these contracts requires versioning, documentation, and mechanisms that reduce incompatible changes.

REST and GraphQL can address different needs, but the choice of protocol is less important than establishing understandable and stable contracts.

It is also necessary to determine how the system responds to partial failures. If the recommendation engine stops working, the product page should probably remain available. If the pricing service fails, the decision may be different.

These priorities are part of architectural design.

The risk is building a distributed monolith with composable tools

Acquiring different specialized solutions does not guarantee a decoupled architecture.

A company can implement CMS, PIM, commerce engine, DAM, and various SaaS services and end up with a platform where any modification requires coordinated changes across numerous systems.

The result retains the operational complexity of a distributed architecture without achieving sufficient independence.

This scenario is related to the distributed monolith that also appears in microservices architectures. The physical separation exists, but the dependencies remain too strong.

Some signs can help identify this problem:

• every product change requires simultaneous modifications in several systems;

• different platforms maintain inconsistent copies of the same information;

• the frontend knows too many internal details of each provider;

• replacing a component forces modifications to a large part of the architecture;

• integrations depend on manual processes that are difficult to reproduce;

• a secondary failure can prevent the entire experience from functioning.

A well-designed composable architecture should allow certain components to evolve or be replaced with a controlled impact on the rest of the ecosystem.

DevOps and cloud emerge when the number of components increases

A traditional platform may have a relatively centralized pipeline. In headless and composable, frontend, APIs, serverless functions, backend services, and different external platforms can coexist.

The operation needs to adapt to that ecosystem.

DevOps engineers can automate pipelines, deployments, testing, and observability to reduce friction between the different components.

Cloud also becomes important when part of the architecture runs on the company's own infrastructure. CDN, caching, serverless functions, APIs, and integration services need to be scaled according to availability and traffic.

Cloud engineers can work on this layer to design scalability, resilience, and costs.

The advantage of using multiple managed services quickly disappears if the team cannot determine which component is failing when the experience presents a problem. Logs, metrics, tracing, and monitoring must provide a sufficiently integrated view.

What profile does each project really need?

The composition of the team depends on how many responsibilities have been decoupled and the complexity of the integrations.

A corporate website that needs to distribute content from a headless CMS may primarily require a CMS specialist and a frontend developer.

An e-commerce platform that connects catalog, inventory, content, payments, and ERP probably needs additional backend capabilities.

When multiple systems and different teams are working on them, the architecture acquires enough complexity to justify a software architect.

DevOps and cloud gain weight as the number of components the company needs to deploy and operate directly increases.

The chosen technology also influences the profile

“Headless experience” can mean very different things depending on the stack.

A company that uses Shopify for commerce and Contentful as a CMS may need different knowledge than another that builds on commercetools, Contentstack, and custom services deployed on AWS.

For this reason, a job description based solely on technology names can be too restrictive or too generic.

It is preferable to first identify the responsibilities that the professional will have: modeling content, developing interfaces, building APIs, integrating platforms, defining architecture, or operating infrastructure.

From those responsibilities, the specific technologies that they really need to master can be determined.

This approach also facilitates team expansion. Instead of looking for a single profile that knows frontend, backend, CMS, e-commerce, cloud, DevOps, and architecture, specific capabilities can be incorporated based on the project's needs.

Headless and composable need clear boundaries more than an extensive stack

The main advantage of a headless or composable architecture appears when its components can evolve with sufficient independence.

Separating frontend and CMS can provide flexibility. Dividing commerce, content, search, and product can increase it even more. But each separation adds an integration that the team will need to maintain throughout the platform's lifecycle.

The architectural goal should be to ensure that this independence compensates for the added cost.

For some companies, a headless CMS with a modern frontend will be sufficient. Others will need to incorporate commerce, PIM, DAM, and specialized services to build a complete composable platform.

The team must evolve in the same way.

CMS & e-commerce developers, frontend developers, and backend developers cover different layers of implementation. Software architects help maintain coherence as the number of components increases. DevOps and cloud provide the operational capacity necessary to sustain the platform.

In 2026, adopting headless CMS or composable commerce will have less to do with accumulating technologies and more with properly distributing responsibilities among systems and people.