Going Headless: A Double-Edged Sword
Why the most flexible e-commerce architecture is not necessarily the right one, and why AI is changing the equation.
Frank Ricciardi
Founder & Principal Advisor
Five to seven years ago, headless commerce became one of the hottest topics in e-commerce architecture.
The promise was compelling.
Unlimited flexibility.
Freedom from the constraints of the traditional commerce platform.
Complete control over the customer experience.
The ability to choose the best technologies for different parts of the commerce stack.
And an architecture capable of evolving as quickly as the business could imagine new experiences.
For companies frustrated by the constraints of monolithic commerce platforms, headless felt like the future.
And in many ways, it was.
But flexibility came with a price.
You could build almost anything you wanted.
You just had to build it.
That meant product specifications, engineering resources, integrations, testing, quality assurance and ongoing technical ownership.
As companies pursued increasingly composable architectures, they also assumed responsibility for making independently selected technologies operate as one coherent commerce experience.
That was the other edge of the sword.
Today, something important has changed.
The architectural tradeoffs still exist.
But the economics surrounding them are changing dramatically because of AI.
That makes this a good time to reconsider what going headless actually means, what it buys you, what it requires from you, and perhaps most importantly:
How much flexibility do you really need, and when do you need it?
Headless is not one thing
Before making an architectural decision, it helps to separate several terms that are often used together.
Headless commerce separates the presentation layer, the customer-facing “head,” from the underlying commerce functionality. The experience can be developed independently and communicate with the commerce engine through APIs.
API-first goes further. The underlying capabilities are designed from the beginning to be exposed and consumed through APIs. APIs are not simply added to the platform. They are a fundamental part of how the platform is designed to operate.
Service-oriented architecture organizes functionality into discrete services with defined interfaces. Microservices are one way of implementing that broader architectural concept.
Composable commerce allows an organization to assemble its commerce environment from different components and providers. Commerce engine, content management, search, payments, promotions, personalization, loyalty, product information, subscriptions and other capabilities can potentially come from different systems.
And MACH architecture describes a particular set of architectural principles: Microservices-based, API-first, Cloud-native SaaS and Headless.
These concepts overlap.
They are not synonymous.
And understanding the differences matters because “headless” has increasingly become a broad label applied to architectures offering very different degrees of flexibility.
Think of flexibility as a spectrum
I find it more useful to think about commerce architecture along a flexibility spectrum.
On one side sits the traditional monolithic commerce platform.
The storefront, commerce functionality and much of the business logic are designed to operate together.
The platform may expose APIs, potentially quite a few of them.
But there is an important distinction between a platform that has APIs and one that was designed API-first.
Moving across the spectrum, hybrid approaches begin decoupling particular elements of the experience.
Perhaps the storefront becomes independent.
Then search.
Content.
Personalization.
Payments.
Promotions.
Or some other capability where the business needs greater control.
At the other end sits an API-first architecture in which the underlying services are designed to be consumed independently.
Conceptually:
Monolithic + APIs → Hybrid / Progressively Decoupled → API-first
Figure 1
The Flexibility – Ownership Continuum
+ APIs
Progressively Decoupled
+ APIs
Progressively Decoupled
Greater architectural freedom brings greater responsibility for building and operating the experience.
As you move down, architectural flexibility generally increases.As you move to the right, architectural flexibility generally increases.
So does your ability to create differentiated experiences.
But historically, something else increased with it:
The amount of responsibility you assumed for building and operating the experience.
That is why the question should never simply be:
“Should we go headless?”
A better question is:
Where on the flexibility spectrum should we be?
Flexibility is valuable. But it is not free.
A highly flexible commerce architecture can create enormous advantages.
You can design experiences unconstrained by a platform’s native storefront.
You can serve multiple channels from the same underlying commerce capabilities.
You can introduce specialized technologies without replacing the entire platform.
You can potentially evolve individual components independently.
And you can differentiate in places that matter strategically to the business.
But every additional degree of freedom creates something the organization must own.
Someone owns the architecture.
Someone owns the integrations.
Someone owns performance.
Someone owns security.
Someone owns testing across services.
Someone owns observability.
Someone owns API changes.
Someone owns data consistency.
Someone owns vendor coordination.
Someone owns what happens when one component changes and three others are affected.
And someone owns the problem when Vendor A says the issue belongs to Vendor B while Vendor B says it belongs to Vendor C.
Ultimately, someone has to make the whole thing behave like one commerce platform even though it isn’t one.
That is the price of composability.
And for years, one of the largest components of that price was engineering.
We changed the economics once before
As software development requirements grew, companies found ways to change the economics.
One of the most significant was moving development offshore.
If building differentiated digital experiences required more engineering capacity, one solution was to reduce the cost of that capacity.
That changed the economics.
AI is changing them again.
But this time, the change may be more fundamental.
AI-assisted development is beginning to collapse some of the distance between product management and engineering.
A technically capable Product Manager can increasingly prototype experiences, interact with APIs, create workflows, generate code, troubleshoot, test ideas and iterate without waiting for every idea to move through the traditional development lifecycle.
That does not eliminate engineering.
Nor should it.
Production architecture still matters.
Security matters.
Scalability matters.
Reliability matters.
Performance matters.
Data integrity matters.
Complex integrations matter.
Technical governance matters.
But AI changes where highly skilled engineering resources need to spend their time.
The traditional model often looked something like:
Product Requirement → Specification → Engineering Roadmap Schedule → Development → Testing → Iteration
Increasingly, we can imagine:
Product Intent → AI-Assisted Build / Prototype → Test → Learn → Iterate → Engineering Hardening and Governance Where Required
Figure 2
AI Changes the Development Model
Traditional
AI-assisted
(as required)
(as required)
AI compresses the distance between intent and a working prototype, while engineering remains essential for production quality.
That changes the cost and speed of exercising architectural flexibility.
And that matters enormously for headless commerce.
AI changes the economics of building headless
Five years ago, a company evaluating an API-first commerce platform might reasonably have concluded:
“We can create almost anything we want, but we are going to need substantial engineering resources to do it.”
That assumption increasingly deserves to be revisited.
AI-assisted product development can reduce the human engineering effort required to explore an idea, create an experience, interact with APIs and test whether something actually works.
The flexibility inherent in headless architecture may therefore become much more economically accessible.
But there is an important caveat.
AI is dramatically changing the economics of building headless. It does not eliminate the economics of owning headless.
It may become dramatically easier to connect services.
That does not make the dependency disappear.
It may become faster to create an integration.
That does not eliminate the need to monitor it.
It may become inexpensive to generate code.
That does not eliminate security, scalability, reliability or technical debt.
It may become possible for a Product Manager to build functionality that previously required significantly more engineering involvement.
That does not mean the Product Manager should become responsible for production architecture.
AI changes the equation.
It does not repeal the laws of software engineering.
A real example: Maavee Health
Maavee Health, a FARVENTURES client, provides a useful example.
When Maavee began approximately six years ago, it was a bootstrapped startup with an ambitious vision: make it easier and more valuable for people to pursue well-being.
The product envisioned to deliver on that mission was a digital health and well-being platform that combined commerce, community and media to drive engagement in a person’s well-being journey.
The commerce component itself was not a traditional storefront. Maavee envisioned a highly differentiated customer experience built around a zero-inventory marketplace.
It had a proprietary wallet for commerce transactions. That wallet was funded by employers and, eventually, other stakeholders with a vested interest in the user’s well-being. Over time, incentives and rewards would also come into play.
Maavee needed a checkout experience capable of combining funds available in the Maavee wallet with a credit card in a single transaction.
And that was only the beginning of the vision.
As the product evolved, Maavee needed the ability to create different product catalogs for different clients.
Workflows could vary by client.
Experiences could vary by user.
Personalization became increasingly important. In fact, Maavee aspired to hyper-personalized experiences.
The commerce experience was becoming part of a much broader product rather than simply a place to browse products and complete transactions.
A traditional out-of-the-box storefront would have imposed significant constraints.
So Maavee chose flexibility.
It went headless and composable.
The decision gave the company extraordinary freedom over what it could create.
Figure 3
Maavee Health: Commerce as Part of a Broader Product
Maavee needed to deliver personalized experiences that converged content, community, commerce, and distinguishing features.
But there was another reality.
Maavee was bootstrapped.
Every differentiated experience still needed to be conceived, specified, designed, developed, integrated and tested.
Engineering resources were expensive.
Priorities competed for capacity.
Experiments took time.
The architecture gave the company the freedom it needed.
But the company could not always afford to exercise that freedom at the speed it wanted.
That distinction matters.
Would Maavee make the same decision today?
I believe it would.
Given the same product vision, the fundamental need for architectural flexibility would still exist.
What would be dramatically different is the relationship between product vision, product management and engineering.
Product specifications could become working prototypes much earlier.
APIs could be explored directly.
New experiences could be tested before consuming substantial engineering capacity.
Interfaces and workflows could be iterated rapidly.
Product leaders could move much closer to the actual creation of the experience.
And engineers could concentrate more of their expertise on the areas where engineering expertise creates the greatest value: architecture, security, reliability, scale, complex integrations and production hardening.
The architecture decision might be the same.
The development model would not be.
And that brings us to a much more important question than whether headless is better.
How much flexibility do you really need, and when do you need it?
Technology architecture discussions have a tendency to begin with the destination.
What might we eventually want to build?
What channels might we eventually support?
How many markets might we enter?
How personalized might the experience become?
What services might we eventually want to replace?
Those are legitimate questions.
But architecture should also reflect the lifecycle of the company.
A scaled enterprise with established product-market fit, significant transaction volume, multiple brands, multiple geographies and sophisticated engineering capabilities faces a very different architectural decision from a bootstrapped startup trying to determine whether customers actually want what it is building.
The startup may eventually require enormous flexibility.
That does not necessarily mean it requires all of that flexibility today.
On the other hand, if the differentiated product hypothesis itself cannot be tested using a more constrained architecture, starting with the monolith simply because it is easier may be equally shortsighted.
So perhaps the questions for an early-stage company should be:
What is the minimum architecture required to test the differentiated hypothesis?
And:
How can we test it at the speed of light?
Product-market fit is testing by a thousand cuts
Before product-market fit, the objective is not architectural perfection.
It is learning velocity.
Change something.
Test it.
Observe.
Learn.
Adjust.
Repeat.
Again.
And again.
And again.
Product-market fit rarely emerges from one grand experiment.
It is discovered through hundreds, potentially thousands, of observations, experiments, adjustments and decisions.
If product-market fit is testing by a thousand cuts, your architecture should make each one faster, easier and less expensive.
That changes how we should think about speed.
The important question is not simply:
“How quickly can engineering ship?”
It is:
How quickly can the business learn?
This is also where the double-edged nature of headless becomes particularly interesting.
A headless architecture may theoretically give a startup enormous freedom to experiment.
But if every experiment requires a detailed specification, engineering prioritization, a development sprint, integration work and QA, the architecture that promised flexibility may actually slow learning because exercising that flexibility is too expensive.
AI has the potential to change that relationship.
The combination of architectural flexibility and dramatically faster experimentation may allow companies to test differentiated experiences at a pace that would have been economically unrealistic only a few years ago.
But only if the underlying architecture is proportionate to the problem being tested.
Don’t architect for every possibility
This leads to a principle I believe deserves much more attention:
Don’t architect for every possibility your vision can imagine. Architect for the flexibility your business needs at the stage when it needs it.
That does not mean every startup should begin with a monolith.
It does not mean every enterprise should become fully composable.
It does not mean API-first is inherently superior.
And it certainly does not mean MACH is the inevitable destination of every commerce architecture.
It means architecture should be intentional.
A company searching for product-market fit should optimize heavily for learning.
A company that has demonstrated fundable product-market fit may need to begin investing ahead of scale.
A rapidly scaling business may need architectural flexibility to prevent its technology from constraining growth.
A mature enterprise may value composability because different markets, brands, channels and experiences genuinely require different capabilities.
Different stages create different architectural requirements.
Progressive composability may be the answer for many companies
This is why I find the idea of progressive composability compelling.
Architecture does not have to be an ideological choice between monolithic and fully composable.
A company can deliberately decouple where flexibility creates meaningful business value.
Perhaps the native storefront is the constraint.
Decouple it.
Perhaps the approach to loyalty is strategically differentiating.
Replace it.
Perhaps content management needs to serve multiple channels.
Separate it.
Perhaps payments, promotions or personalization require capabilities the commerce platform cannot provide.
Introduce them when the business case exists.
Figure 4
Illustrative Progressive Composability Scenario
The objective is not to move as far right on the flexibility spectrum as possible. (see Figure 1)
The objective is to occupy the right place on the spectrum for the business you are building today, while understanding what it will take to move tomorrow.
That last part matters.
Because today’s expedient architectural choice can become tomorrow’s constraint.
But tomorrow’s theoretical requirement can also become today’s unnecessary expense.
Good architecture balances both.
Architecture is also an organizational decision
There is one more question that should be asked before moving toward greater composability:
Can your organization operate what you are designing?
Highly composable environments require more than technology.
They require architectural discipline.
Product management.
Engineering capability.
Testing.
Observability.
Security.
Vendor management.
Release management.
Clear ownership.
Governance.
And an operating model capable of coordinating the pieces.
AI can augment many of these capabilities.
It can dramatically increase the leverage of the people performing them.
But it does not eliminate organizational responsibility.
The most elegant architecture diagram in the world is irrelevant if the organization cannot operate the architecture reliably.
That is why architectural flexibility should never be evaluated independently from organizational capability.
So, should you go headless?
Maybe.
That is the point.
Headless is not inherently better.
Monolithic is not inherently outdated.
API-first is not inherently superior.
Composable is not automatically more sophisticated.
MACH is not a business strategy.
They are architectural approaches with different advantages, constraints and operating requirements.
Before choosing among them, I would ask:
What are we building that is genuinely differentiated?
How much flexibility do we actually need?
Which flexibility do we need now?
Which might we need later?
Where are we in the company lifecycle?
Are we searching for product-market fit, proving it, scaling it or optimizing an established business?
How quickly do we need to learn?
What can we now build differently because of AI?
What engineering capability do we actually have?
What complexity are we willing and able to own?
And ultimately:
Does the additional flexibility create enough business value to justify the additional responsibility?
That is the decision.
The sword still has two edges
The headless conversation began with freedom.
Break apart the monolith.
Own the customer experience.
Choose the best technologies.
Build whatever you can imagine.
That promise remains compelling.
Perhaps even more compelling now that AI is fundamentally changing the economics and speed of software development.
But flexibility has never been free.
AI may make exercising that flexibility dramatically less expensive.
It does not make architectural complexity disappear.
So the goal should not be the most modern architecture.
Or the most composable.
Or the most technically elegant.
The goal should be the minimum architecture that gives your business the flexibility it needs to differentiate, learn and grow at the speed required for the stage you are in.
Because architecture should not exist to prove how sophisticated your technology is.
It should help you discover, build and scale what your customers actually value.
And especially before product-market fit, that means one thing above all:
Test at the speed of light.
Learn by a thousand cuts.
And make sure your architecture is helping you move faster, not making every cut more expensive.
Written by
Frank Ricciardi
Founder & Principal Advisor, FARVENTURES