Integrations in Minutes: App Store, Not Engineering TicketTime-to-market is rarely decided in the ar…
Pre-Integration Is the Real Time-to-Market Currency
Pre-Integration Is the Real Time-to-Market Currency
Backend modularization shortens the time to your first module, not the time to your first revenue. The reason is arithmetic: in a modular stack, integration effort grows multiplicatively with the number of modules, channels, and tools, not additively. That curve is what decides time to market, and it does not flatten in the backend. It flattens in the frontend layer, provided that layer is already pre-integrated.
The market has solved the backend half
Since July, commercetools has been selling its platform in individually bookable modules: Core Commerce with cart, order, checkout, customer, and B2B on one side, Product Catalog with product modeling, pricing, inventory, and search on the other. CEO Doug McNary's reasoning is sober and correct: companies "can no longer afford to wait years to modernize" (commercetools press release).
When the leading composable vendor starts slicing its core product into purchasable pieces, the market direction is unambiguous: modernization runs incrementally, not as a big-bang replatform. That is a sound move, and it shifts the bottleneck. Because a module without a surface is not a feature. It is an API endpoint.
Why effort grows multiplicatively
The common expectation about modular purchasing goes like this: I buy module two, so I pay module-two effort once. Additive. In practice the effort does not sit in the module, it sits in its touchpoints. A catalog module does not simply get "connected". It has to show up per channel in listing, detail, search, filtering, cart preview, and checkout context. Each of those points carries its own data shapes, error states, caching rules, and consent logic.
Put formally: the number of integration points scales with n modules times m delivery channels times k connected tools. Every expansion adds a factor, not a summand. That is the difference between a sprint and a quarter.
Model calculation (not measured project data)
The list below is a pure model calculation meant to illustrate the growth order. It rests on disclosed assumptions, not on collected project figures: n = booked backend modules, m = delivery channels with their own surface, k = connected third-party systems such as search, analytics, consent, or payment. An integration point is the place where a module meets a channel and a tool and needs its own behavior.
- Start: n = 2 modules, m = 1 channel, k = 3 tools. Integration points (n × m × k): 6. Additive expectation (n + m + k): 6.
- Second module booked: n = 3 modules, m = 2 channels, k = 4 tools. Integration points: 24. Additive expectation: 9.
- Multi-brand rollout: n = 4 modules, m = 3 channels, k = 5 tools. Integration points: 60. Additive expectation: 12.
The point of the list is not the specific number, it is the order of growth. Between the first and the third stage the additive expectation doubles, while the count of actual touchpoints rises by a factor of ten. If you do not break that curve, every additional module gets paid for with its own glue sprint. How far that math has already moved into leadership territory is something we covered in speed to market as a non-negotiable.
Where pre-integration actually applies
Pre-integration does not mean "we have a connector". It means the multiplication gets cut off at a defined place. At Laioutr that place is the Orchestr and Connect layer: an abstraction that normalizes product, inventory, category, and order data from the connected backends into one unified, frontend-consumable data model. More than 50 backends are supported through it (source: laioutr.com/why-laioutr).
For the commercetools case that means a standard GraphQL connection: the layer talks to the commercetools GraphQL API directly instead of building a separate client tier per module. Anything a standard connector does not cover goes through a custom GraphQL fallback into the same data model. That is the architecturally decisive part: the fallback does not create a second data path, it lands in the same contract your components already consume.
This changes the arithmetic. An additionally booked backend module no longer meets m times k open integration slots. It meets an existing schema and a component library that already renders that schema. The k factor gets capped on the same level: more than 300 integrations sit pre-integrated in the App Store (verified August 29, 2026), from search to analytics to payment, configurable instead of implementable.
We wrote up what this implies for project sequencing in more depth using the commercetools case: what the experience layer still needs.
What this means for architecture teams
Three consequences that translate straight into decisions.
First, evaluate frontend options by marginal cost, not by starting cost. The relevant question is not how long the first module takes to reach a surface, it is how long the fourth takes. An in-house frontend often has low starting cost and constantly high marginal cost per module and channel. A pre-integrated layer moves effort forward and keeps the marginal cost small.
Second, draw the abstraction boundary deliberately. If every component knows the native schema of a module, coupling in the frontend is just as hard as it used to be in the monolith, only more distributed. A unified data model is not a convenience feature, it is the precondition for backend modules staying genuinely swappable.
Third, separate integration from configuration. Anything a marketing or growth team can connect without a deployment never enters the n times m times k calculation in the first place. That is precisely the purpose of an app store model: it converts integration work into configuration work. Details on the data model and the composables live in the developer docs.
FAQ
Is pre-integration just another word for standard connectors? No. A connector solves the connection to a system. Pre-integration additionally solves normalization onto a shared schema and the question of which components already render that schema. Without the second part, work remains per module and per channel.
Do I lose access to backend-specific features? No. The custom GraphQL fallback remains the path for anything a standard connector does not cover. The difference is that those special cases land in the same data model instead of opening a second path.
Does the math still hold with only one channel? With m equal to one the channel factor drops out, but the multiplication of modules and tools remains. The effect is smaller, not absent. It grows as soon as a second brand, a second language, or a second touchpoint arrives.
Do I have to replace my backend to benefit? No. The layer sits on top of the existing stack. That is the whole point: you keep the modularization in the backend and hand off the multiplication in the frontend.
Next steps
If you are booking modules individually right now and want to know how many integration points your setup actually produces, we will work through it with you in an architecture session: against your real n, m, and k, not against the model.
More from the Laioutr Platform
About the author: Sebastian Langer is CTO and co-founder of Laioutr, where he owns the architecture of the Frontend Management Platform.