Spryker Oryx vs. a Production-Ready Frontend: What Actually Matters in 2026Spryker introduced Oryx, …
When Not to Go Fully Composable
For a few weeks now, a single line has been circulating through industry outlets like CX Today, Elogic, and VDPL, generating unusually much discussion for a summer lull: composable commerce is a business architecture decision, not a default setup. The core claim of the discourse is that most businesses should not go fully composable. That is not a eulogy for MACH architecture. It is a maturity statement after several years of composable hype. The market is getting more sober about it, and that is a good thing.
For retailers, that raises an uncomfortable but important question: if not everyone needs to go fully composable, who does? And what do you do if you want the benefits without taking on the full transformation?
What the summer 2026 discourse is actually saying
The current industry discourse is not a one-off hot take. It is a recurring observation across several publications: composable architecture delivers real advantages, backend agnosticism, best-of-breed selection, scalability across markets. It also requires real prerequisites: dedicated platform teams, high change frequency, a backend that already thinks API-first, and governance processes built for many services instead of one system. Without those prerequisites, composable commerce turns into an integration project with no end date instead of a growth architecture.
We agree with that read, with one addition: the decision is rarely binary. Between "go fully composable" and "leave everything in the monolith" sits a third path that the current discourse rarely names, but one we see with customers every day: frontend-first.
When composable actually wins vs when it doesn't
Composable commerce is not a yes/no feature. It is a fit question. The table below shows when the full rebuild pays off, and when it doesn't, yet:
| Criterion | Composable wins | Composable doesn't win (yet) |
|---|---|---|
| Team size and roles | Multiple dedicated frontend and platform teams in place | One or two developers, no dedicated platform role |
| Change frequency | Multiple releases per week across many touchpoints | A handful of campaign updates per month |
| Backend maturity | API-first backend with stable contracts | Monolith with tight coupling, still evolving |
| Time-to-value expectation | 12-to-18-month architecture investment accepted | Results expected in weeks |
| Governance scope | Multiple brands or markets, complex compliance | One brand, one market, manageable compliance |
| Budget reality | Dedicated architecture budget exists | Marketing budget has to cover frontend changes too |
If most of your answers land in the right-hand column, a full-stack decompose is the wrong project right now, not the wrong goal. Composable remains a valid target architecture, just not the next step.
The frontend-first shortcut
The part of the composable stack that actually solves most customer problems is rarely the backend. It's the frontend: how fast can you ship a landing page, adjust a campaign layout, or roll out a new market setup without waiting on a developer ticket?
That's exactly where frontend as a service comes in: you adopt the frontend layer, marketer-editable and fast, without pulling forward the full backend rebuild. The backend stays whatever it is, Shopify, Shopware, a monolith, a custom build, while the frontend gets modernized independently of it. If the need for a full composable rebuild shows up later, the frontend is already decoupled and doesn't need to be rebuilt from scratch.
That's the practical difference between a composable headless frontend as an entry point and a full MACH transformation as an eventual goal. Both are composable in the technical sense, but only one of them requires a dedicated platform team on day one.
How to make the call
Four questions get you a first-pass answer:
- How often does your frontend change per month, and how often does a developer ticket block that change?
- Is your backend already API-first, or would a composable rebuild need a backend rebuild first?
- Do you have a team that can run a multi-service architecture long-term, or would that be a one-time project effort?
- Do you need the outcome in weeks, or is a 12-month investment realistically budgeted?
If two or more answers land on "not yet ready," that isn't a failure. It's a good reason to start with the frontend and decide the rest later.
Where Laioutr fits
Laioutr is built for the frontend layer, not for the full composable stack. If you want to replace an entire MACH suite including PIM, OMS, and payment orchestration, that's not our lane. If you want to modernize the frontend layer without switching your backend, that's exactly what Laioutr is built for: a frontend management platform that runs on any backend and stays composable-ready if you decide to go further later.
Further reading
To understand the composable stack in full, two deeper perspectives are worth reading: why composable commerce needs a frontend management platform to succeed, and which pitfalls to avoid during a MACH migration.
If you'd rather talk through your own decision than answer four questions on paper, you can find more detail and contacts on the Laioutr homepage.