Frontend as a service, explained
Every headless commerce project rebuilds the same storefront: catalogue, product detail, cart, checkout, account, search, content blocks. Frontend as a service treats that surface as a product instead of a from-scratch build.
Frontend as a service (FaaS) is a productized model for delivering the storefront layer of a headless commerce project. Instead of building a custom frontend, the merchant licenses a pre-built, production-ready storefront and customizes it for their brand.
- Productized storefront
- Vue and Nuxt baseline
- Backend-agnostic
- Ships in 6 to 12 weeks
Benefits
Build time cut to weeks
The storefront, BFF layer, and most integrations are already built. The setup project covers configuration, brand customization, and your specific requirements — not construction from scratch.
Backend stays where it is
Norce, Shopware, Magento, or Shopify keeps owning products, prices, inventory, and orders. Frntkey connects via purpose-built adapters. The commerce backend does not change.
Integrations pre-wired
Klarna, Walley, Svea, Ingrid, Voyado, Hello Retail, Lipscore, GA4, GTM, and Cookiebot ship configured and ready to activate per project. No platform lock-in.
Predictable cost model
A productized frontend has a productized price. Monthly subscription covers the codebase, Storyblok CMS, maintenance, and support. Setup is a fixed-scope project quoted before kickoff.
What frontend as a service actually means
A frontend-as-a-service product ships a complete, working storefront. It covers the pages every ecommerce site needs: home, category listing, product detail, cart, checkout, account, and search. It includes a CMS for marketing pages and landing pages. It comes pre-integrated with the most common payment, shipping, search, and CRM vendors.
The merchant licenses the storefront as a subscription. A one-time setup project handles backend connection, brand customization, and any project-specific requirements. After go-live, the FaaS provider maintains the core codebase. Security patches, dependency upgrades, and core feature additions flow through the subscription.
The model is distinct from both a monolithic platform theme and a fully custom headless build. A theme is constrained to whatever the platform's frontend engine allows. A fully custom build gives complete freedom but requires a team to build and maintain from scratch. FaaS sits between: more flexible than a theme, lower build cost than fully custom.
How FaaS connects to headless architecture
FaaS is a delivery model for the presentation layer of a headless architecture. In a headless stack, the storefront and the commerce engine are separate systems that communicate through APIs. FaaS productizes the storefront side of that split.
The commerce backend stays as-is. Norce Commerce, Shopware, Magento, or Shopify continues to own the catalog, pricing, inventory, and order management. The FaaS storefront connects via adapters built for each backend. Changing the commerce engine in the future does not require rebuilding the storefront, provided the adapter layer handles the difference.
The backend-for-frontend (BFF) layer — the orchestration service that sits between the storefront and the commerce APIs — is typically included in the FaaS product. This is what makes a FaaS launch significantly faster than building headless from scratch.
What ships with a FaaS product
A production-grade FaaS product includes:
- Core storefront pages. Home, category, product detail, cart, checkout, search, account, order history. These are not templates to build from — they are working pages the merchant customizes on top of.
- CMS integration. A headless CMS (Storyblok in Frntkey's case) ships bundled. Marketing teams manage content without developer involvement.
- Pre-wired integrations. Payment providers (Klarna, Walley, Svea), shipping (Ingrid, Norce Checkout), search (Meilisearch), analytics (GA4, GTM, Meta Pixel), reviews (Lipscore), and CRM (Voyado) come configured and ready to activate per project.
- SEO foundations. Server-side rendering, structured data, canonical links, Open Graph tags, and automatic image optimization are built in. Core Web Vitals pass at launch.
- Design system. A base design with configurable logo, colors, and typography. Full brand migration and Figma-led design are available as scoped add-ons.
What FaaS is not
FaaS is not a website builder. The storefront is a production Nuxt.js application running on Vercel. Developers configure and extend it. Editors manage content through the CMS. It is not a drag-and-drop page builder for non-technical users.
FaaS is not a commerce platform. It does not own products, prices, inventory, or orders. Those stay in the commerce backend. FaaS is not a replacement for Norce, Shopware, or any other backend — it is the frontend that connects to them.
FaaS is not the right model for every project. If the storefront requires heavy custom logic that a productized frontend would constrain — unusual checkout flows, deep B2B-only workflows on a non-standard platform, or storefront experiences so distinctive that almost nothing reuses — a fully custom build on Alokai, Hydrogen, or a bespoke Nuxt application may be more appropriate.
When FaaS is the right model
FaaS earns its place in three situations.
First, when the headless commerce project is serious but the storefront is not radically differentiated. The merchant needs a fast, well-built, SEO-ready storefront on Norce or Shopware. They do not need to reinvent the product listing page. FaaS covers the solved problems; the team focuses on brand, content, and the integrations that are actually specific to them.
Second, when time-to-market matters. A fully custom headless build typically takes 4 to 9 months to reach launch quality. A FaaS project on Frntkey typically launches in 6 to 12 weeks because the storefront, BFF, and most integrations are already in place. The difference is configuration and customization, not construction.
Third, when the team does not have the capacity to maintain a bespoke frontend long-term. A custom storefront is a software product. It needs maintenance, dependency management, security patching, and ongoing development. FaaS shifts most of that to the provider. The team gets a maintained, up-to-date codebase without the overhead.
FaaS vs fully custom headless: the honest comparison
The decision between FaaS and a fully custom headless build comes down to four variables: how distinctive the storefront experience needs to be, how fast the project needs to launch, what the team can maintain, and total cost over a 2–3 year horizon.
A fully custom build on a framework like Alokai or a bespoke Nuxt application gives complete control. It takes longer to build, costs more upfront, and requires ongoing engineering investment. For storefronts where the UX is a genuine competitive differentiator, that investment is justified.
FaaS reduces build time and transfers maintenance responsibility to the provider. The tradeoff is that the storefront operates within the constraints of the productized platform. Those constraints are real but, for most B2B and B2C merchants on Norce or Shopware, they are not limiting.
How Frntkey implements FaaS
Frntkey is a frontend-as-a-service built on Nuxt.js, Vue.js, and Tailwind CSS. It ships with Storyblok bundled as the CMS and runs on Vercel. Native integrations exist for Norce Commerce and Shopware. The full integration set covers the standard Nordic commerce stack: Klarna, Walley, Kustom, Svea, Ingrid, Voyado, Hello Retail, Lipscore, Retain24, Awardit, GA4, GTM, and Cookiebot.
Frntkey is sold as a monthly SaaS subscription plus a one-time setup project. The subscription covers the codebase license, the Storyblok CMS license, ongoing maintenance, and support. The setup project covers backend integration, design customization, and go-live. Hosting on Vercel is billed at cost.
Implementation is delivered by Nordic Web Team, the agency behind the product.
Frequently asked questions
Ready to talk?
See how Frntkey fits your stack. Book a 30-minute demo.
Book a demo