Field Note
Composable is not the same as simpler
Composable gives a company more choices. Choices are not the same thing as a simpler system.
I have spent plenty of time around storefronts that needed more flexibility than a single platform could reasonably provide. Better search, content, payments, experimentation, and frontend delivery can each create real value. I have also seen “composable” become a polite word for buying six products and hoping the integration diagram counts as a plan.
Sometimes that is the right trade. Sometimes it is an expensive hobby.
Complexity moves
A suite concentrates decisions inside one vendor and one operating model. A composable system distributes them across contracts, APIs, data flows, deployment pipelines, and teams.
That can be the right trade. It is still a trade.
When a company replaces a platform limitation with a specialized service, it gains control in one place and accepts responsibility somewhere else. Somebody now owns the integration, failure behavior, observability, upgrades, and the disagreement between two vendors when the system breaks.
If that ownership is missing, the architecture is not modular. It is merely fragmented.
Start with the capability, not the category
“We need a composable stack” is not a useful requirement.
What does the business need to do that it cannot do today? Does search quality limit discovery? Is content trapped in release cycles? Are payment constraints affecting conversion or expansion? Does the current frontend make ordinary change unreasonably expensive?
Those questions create a boundary around the problem. The answer may be a specialized service. It may also be a configuration change, a better interface, or deleting a customization nobody needs anymore.
The category should follow the constraint.
Evaluate the operating cost
Product demos make components look independent. Production systems are not.
Before adding a service, I want to know:
| Question | Why it matters |
|---|---|
| Who owns the integration? | Shared ownership often means no ownership. |
| What happens when it is unavailable? | Graceful degradation has to be designed. |
| Where is the source of truth? | Duplicate state creates reconciliation work. |
| How is it deployed and observed? | A working API is not an operating model. |
| What does replacement require? | Composable should preserve options, not create a new trap. |
| What can the business operate directly? | Flexibility is wasted when every change still needs engineering. |
The license cost is usually the easiest number to find and the least complete one.
Use modularity where it removes a constraint
Composable architecture is useful when a capability is strategically important, changes at a different pace from the core platform, or benefits from a specialized product the organization can actually operate.
It is less useful when the company has no owner, no integration discipline, and no reason for the capability to vary independently.
In a masterclass on modern Salesforce frontends, I moderated a discussion with people from Algolia, Netlify, and Stripe. The useful part was not that each product could be connected. It was understanding what search, delivery, and payments each needed to do for the business, and what operating responsibility came with the choice.
A smaller stack can be more modern
Modernization is not measured by the number of boxes in the diagram.
Sometimes the better architecture is a focused platform with fewer exceptions. Sometimes it is a deliberate set of services with clear boundaries. I want the answer that gives the company useful control without creating more system than it can own.
Call it composable, modular, headless, MACH, or whatever we rename it next.
Just make sure it works.