Integrations in Minutes: App Store, Not Engineering TicketTime-to-market is rarely decided in the ar…
Integrations in Minutes: App Store, Not Engineering Ticket
Integrations in Minutes: App Store, Not Engineering Ticket
Time-to-market is rarely decided in the architecture diagram. It is decided by a far more mundane question: who is allowed to connect a tool? As long as every search, analytics or personalization hookup starts life as an engineering ticket, your backend's modularity stays invisible to the marketing team.
The market is modularizing the backend. Then what?
Since July 2026, commercetools has been selling its platform in individually bookable modules. Core Commerce and Product Catalog can be adopted separately instead of as a full replatform. Doug McNary, CEO of commercetools, framed it this way in the Modular Commerce press release: "As the pace of commerce innovation accelerates, companies can no longer afford to wait years to modernize. Enterprises want to solve immediate business problems, prove value quickly and evolve over time."
The market move is unambiguous, and it is the right one. When even the composable heavyweight breaks its offering into modules, the message is clear: modernization runs incrementally, not as a big bang.
But that shifts the real question instead of answering it. A backend module delivers data. Business value only shows up once that data reaches the storefront and works alongside the tools marketing actually uses. That seam is where the bottleneck sits, and almost nobody addresses it in an architecture review.
Integration is not a technical question. It is a permissions question.
Look at what an average marketing team actually needs over the course of a quarter: Algolia for product search, Klaviyo for lifecycle email, Google Analytics 4 and Hotjar for behavioral data, Contentful for editorial content, Unzer for payments, Akeneo for product data. None of these hookups is technically unsolved. They are all documented, all backed by stable APIs, all implemented hundreds of times over.
Each one still takes weeks. Not because it is hard, but because it has to pass through a queue: write the ticket, get it prioritized in sprint planning, implement, code review, QA, deployment window. The effort per integration is manageable. The wait in front of it is not.
You probably recognize the outcome. Campaigns get planned around what is already connected, not around what would actually work. An A/B test on a new personalization vendor does not get killed because it is a bad idea, but because nobody budgets four weeks of lead time for an experiment. That is exactly what we mean when we say frontend management is the real time-to-market lever in e-commerce: an organization moves at the speed of its slowest approval path, not its fastest API.
What click-to-connect actually changes
The Laioutr App Store inverts that path. Instead of spinning up an integration project per tool, you pick the app in the Cockpit, drop in the credentials and configure where it takes effect in the storefront. The catalog currently lists more than 300 integrations (verified August 29, 2026), spanning search and analytics through content and PIM to payments. We launched it in January 2026 as the first app store for composable frontends and have expanded it steadily since.
One thing this is not: a free-for-all. Engineering still defines the guardrails, which apps are approved, what data fields they can see, and which environments they run in. Marketing composes inside those boundaries. Laioutr is low-code for marketing teams and code-ready for engineering, not a tool that replaces governance.
- Trigger - Classic path: Jira ticket to engineering. With the App Store: Selection in the Cockpit.
- Wait time - Classic path: Sprint cycle plus deployment window. With the App Store: No queue.
- Who decides - Classic path: Backlog prioritization. With the App Store: Marketing, inside the guardrails.
- Rollback - Classic path: Another deployment. With the App Store: Disable the configuration.
- Effort per tool - Classic path: One-off custom glue, ongoing maintenance. With the App Store: Configuration, centrally maintained.
The second-order effect is the more interesting one. When connecting gets cheap, trying gets cheap. A search provider that underdelivers in testing costs you a configuration instead of a quarter. That changes which experiments a team is willing to consider at all.
What you get out of it
The effect does not stop at integrations. It carries across the whole delivery side. According to the figures published on laioutr.com, time-to-launch for new landing pages runs 65 percent below a classic headless setup, and a migration with founder support took a median of under 14 days across Q1 and Q2 2026.
Both numbers share one cause. Not faster developers, but fewer handoffs. If you build pages yourself in the Visual Page Builder, maintain the content yourself through Content Management and connect the tools behind them yourself, a campaign consumes exactly zero sprint slots.
For teams currently modularizing their backend, that closes the loop. If you run commercetools, the headless frontend for commercetools connects over the standard GraphQL integration, and the apps sit in the same layer above it. The backend stays modular, and the delivery side keeps pace.
What this means for your team
If you own marketing or e-commerce, an uncomfortable inventory is worth the hour: how many of your last ten campaign ideas died at the integration, not at the idea? How many tools run in parallel at your company because the better one could not be connected?
The answer is not another tool decision. It is an architecture decision on the frontend side: does integration capability live in your storefront's code, or in a configuration layer above it? In the first case, every hookup stays a release. In the second, it becomes a setting.
FAQ
Does this mean we no longer need engineering? No. Engineering defines the guardrails, reviews new apps and builds anything beyond the catalog. What disappears is the sprint per standard integration.
What about tools that are not in the catalog? You still connect those individually, through the platform's standard interfaces. The catalog covers the standard case, not every edge case.
Do we have to switch backends for this? No. The App Store sits in the frontend layer and is backend-agnostic. Your commerce backend stays where it is.
How do we keep control over privacy and consent? Apps are approved and configured centrally, including consent coupling for tracking tools. Approval stays with the people accountable for it, not with whoever picks the app.
Next steps
Take a look at which of your current tools already sit in the Laioutr app catalog. If three or more of them need an engineering ticket at your company today, you have your business case for next quarter.