Choosing your approach

Partners build on Propeller from different starting points. Some want a storefront running today. Some have an existing site on a CMS with its own frontend framework. Some need full control over every line of UI. The Storefront SDK supports three common approaches. Pick the one that fits your project, then follow the linked guides.

Approach A: Start from an Accelerator boilerplate

Scaffold a complete storefront with the create-propeller-shop CLI, then customize it. The boilerplate owns routing: commerce pages (product, category, cart, checkout, account) are file-system routes, and on Next.js a catch-all route serves content pages from a CMS.

npx @propeller-commerce/create-propeller-shop@latest my-shop --stack=next --mode=hybrid --cms=none

Uses every layer: the SDK, the core layer, a UI library and, on Next.js, an optional CMS.

Best for new projects, a short time to market and pre-sales demos. Available for Next.js, Vue and Nuxt. Start with the Accelerator quickstart.

Approach B: Add the packages to an existing app

Install the SDK and the UI library for your framework, add a GraphQL route on your server, mount the providers and use components and hooks in pages you already own. Add the SDK to your app walks through it.

Uses the SDK plus the React or Vue UI library. Add the CMS renderers if your CMS drives page structure.

Best for teams with an existing site, a CMS that owns routing or a design system to integrate with. If you keep your own components, use the headless hooks only: they hold the state and make the API calls while your components do the rendering.

Who owns the page

Approach B comes in two shapes, depending on who owns the page URL:

• Commerce-led. Your app owns the URLs and routing, as the Accelerator boilerplates do. Propeller components render the commerce pages, and content from a CMS is pulled in where needed.
• CMS-led. Your CMS owns all pages, URLs and routing. Propeller components are blocks that editors place in CMS templates. This suits multi-brand and multi-site setups where editors manage everything in one place.

Approach C: Use the SDK headless

Use the SDK services (and the formatters in the core layer) directly and build all UI yourself. No Propeller components. This is also the approach for a framework without a Propeller UI library, such as Angular, Svelte or Web Components: the SDK works in any JavaScript or TypeScript project. The component reference lists what the UI libraries offer, which makes a good checklist of what to build.

Uses the SDK only.

Best for strict architectural requirements, a framework without a Propeller UI library or full control over the frontend.

If you prefer no SDK at all, write your own queries against the GraphQL API: see Build directly on the GraphQL API.

Decision table

Your situation	Recommended approach
New storefront, speed is the priority	A: scaffold a boilerplate with create-propeller-shop
Prototype or demo quickly for pre-sales	A: scaffold a boilerplate
Existing React app, want pre-built commerce UI	B: install @propeller-commerce/propeller-v2-react-ui and the SDK
Existing Vue or Nuxt app, want pre-built commerce UI	B: install @propeller-commerce/propeller-v2-vue-ui and the SDK
Existing React or Vue app with your own design system	B, hooks only: your components render, the headless hooks hold state and call the API
Your CMS owns routing and page structure	B, CMS-led: components as blocks, the CMS handles pages and URLs
You manage multiple brands or sites from one CMS	B, CMS-led
A framework with no Propeller UI library (Angular, Svelte)	C: SDK services and your own UI, with the component reference as a checklist
You need full control over every part of the UI	C: SDK only
A B2B portal that hides prices until login	Any: set the portal mode to semi-closed (see B2B capabilities)

Next steps

• Accelerator quickstart for Approach A
• Add the SDK to your app for Approach B
• SDK services for the data layer every approach uses
• Keys and security for the keys a storefront needs
• CMS integration for connecting a CMS