Headless commerce

Headless commerce is an architecture where the storefront and the commerce engine run as separate applications, connected by APIs. The shopper sees a single integrated site. The team operates two systems, each with its own release cycle, infrastructure, and team ownership. The naming comes from the head-and-body metaphor. The "head" is the storefront, what shoppers see and click. The "body" is the commerce engine, where the product catalogue, cart logic, checkout flow, and order management live. A monolithic platform ships both as one piece. A headless setup decouples them. The split matters because the two systems change at different rates. The commerce backend changes slowly. Product data, pricing logic, checkout integrations, tax handling. These need stability and audit trails. The frontend changes constantly. Brand campaigns, page layouts, content updates, performance tuning, new device support. Forcing both onto the same release cycle slows the frontend down to the pace of the backend. ## Common reasons merchants pick headless Flexibility on the frontend. Custom page types, unusual product configurators, content-rich brand storytelling. A monolith's theme system has a ceiling. A headless frontend does not. Performance. The frontend can ship as a static site, an edge-rendered app, or a server-rendered Nuxt application. Performance becomes a frontend engineering problem with clear levers, not a platform constraint. Multi-channel. The same backend can serve a web storefront, a native mobile app, a B2B portal, a marketplace integration. Each is a separate head against one shared backend. Multi-market. Localised storefronts share one operational stack. Stock, pricing, product data come from one place. Languages, payment methods, and brand expression vary per market. ## The honest tradeoffs More moving parts. The frontend, the backend, the CMS, the integrations all run as separate systems. Operational complexity is higher than a templated platform. Higher build cost upfront. A custom headless frontend takes 4 to 9 months. The work shifts from theme customisation to frontend engineering as a discipline. Team requirements change. The merchant needs access to frontend engineering capacity, either in-house or through a partner. The platform vendor no longer ships the storefront for free. ## Where Frntkey fits A productised headless frontend like Frntkey targets the middle ground. The frontend is decoupled from the backend (headless benefits) but comes pre-built with the storefront, components, and integrations already shipped (monolith-style time-to-launch). Most Frntkey storefronts go live in 6 to 12 weeks instead of the 4 to 9 months a fully custom headless build takes. Norce, Shopware, Shopify, Magento, BigCommerce, and Centra all support headless deployment. Each exposes APIs that a separate frontend can consume. The choice of backend depends on the merchant's existing setup, B2B vs D2C needs, and Nordic vs international focus. Frntkey ships native support for Norce and Shopware, with Shopify (via Storefront API) and Magento (via GraphQL) also supported. The architectural decision is not "should I go headless." It is "what is the cheapest, fastest path to the storefront flexibility I need." For simple D2C on a single market, a monolith often wins. For B2B, multi-market, or merchants whose ambitions outgrow theme systems, headless wins. For most B2B and Nordic D2C merchants, a packaged headless frontend like Frntkey is the cheapest path to those benefits.