Electric bicycle retail

Gleecycle

Gleecycle is a multi-brand European e-bike retailer. Its core challenge is normalizing cross-brand specifications, filtering by ride use and coordinating language, local inventory and installment payments.

Visit the live project

Official public brand visual

Core implementation review

Three storefront journeys from model choice to purchase

Gleecycle retails multi-brand e-bikes into Europe: city, off-road, fat-tire and cargo sit in one catalog, with multilingual shopping and local-warehouse fulfilment. The work is not a longer spec sheet. Ride purpose has to cut first, then power, torque, range, sensor and availability have to mean the same thing across brands, while the product page keeps media, configuration and the buy action on one bike. Catalog, PDP and market copy are maintained separately, but they have to read as a single selection path.

Project context

Define how customers choose before defining the storefront

Buying decision

Use case—commuting, off-road, touring, leisure or cargo—routes the journey, followed by frame, rider height, power, sensor, range, brakes and budget. Brand, EU inventory, delivery, Klarna, warranty and support complete selection.

Delivery boundary

WESWOO prioritizes cross-brand data standards and scenario guidance: normalize specifications first, then build filtering, comparison and service content so selection remains efficient as inventory grows.

01Ride-led browsing

Cut the assortment by commute, off-road or cargo before a brand is chosen

Shoppers should enter a use-case or bike-type collection, then compare candidates on shared specification fields, instead of hopping brand pages to decode the same numbers.

01Enter by ride use or bike type
02Narrow with shared specification fields
03Compare from product cards
04Open a shortlisted product page

Implementation

Shopify products, variants and collections carry brand and ride-use as crossing dimensions, so city, off-road and cargo do not each need a new page type.
Power, torque, battery, range, sensor and frame live in a comparable field set; colour and sellable configuration stay on variants rather than in unfilterable description copy.
predictive-search.js calls the Predictive Search API and returns products and collections while the shopper types, routing them into the right range first.

Deployment and acceptance

Filters, card parameters and search consume the same field model, so a new brand is mainly catalog data rather than a copied browse template.
High-SKU collections stay templates, sections and blocks; search keeps loading and empty states so merchandising can add brands without rebuilding the IA.

ResultWhat changes after implementation

A shopper can build a cross-brand shortlist from the ride they need, without already knowing a logo.
As inventory grows, the same use-case entry and specification grammar still apply.

View script and Shopify API evidence

predictive-search.jsShopify Predictive Search APIproduct-card.js

02Product confirmation

Keep comparable facts and the live configuration visible on a long e-bike page

Riding photography can keep brand character, but motor, range, sensor, fit and availability have to sit in one layout with colour and sellable configuration—not disappear behind a gallery or a wall of specs.

01Read the first-screen spec and availability cluster
02Change colour or sellable configuration
03Inspect large riding media
04Expand frame, sizing and long specifications
05Add the configuration still on screen

Implementation

Cards and the PDP share one grammar for specification icons, price hierarchy and availability; riding photography carries brand character without inventing a second spec language.
variant-picker.js broadcasts the active configuration so product-price.js, product-inventory.js, product-form.js and the sticky purchase bar stay on the same bike.
media-gallery.js, photoswipe-gallery.js, photoswipe-wrapper.js, fslightbox.js and drag-zoom-wrapper.js put outdoor frames in a dismissible zoom layer, so large images never trap the specification cluster.
accordion-custom.js and show-more.js collapse long specification blocks, keeping motor, range, sensor and stock readable in a compact first screen.

Deployment and acceptance

sticky-cart-bar.js restates only the active variant, price and primary action. It does not grow a second option picker that competes with the original buy box.
After Shopify section events in the theme editor, variant, gallery and purchase modules rebind so the comparison cluster does not freeze on a stale choice.
Trust marks sit beside the purchase control without displacing sizing or range figures.

ResultWhat changes after implementation

Colour or configuration changes keep media, price, availability and cart identity on one bike, with comparable facts still in view.
Shoppers can study riding images and still recover the live configuration and add action, including on small screens.

View script and Shopify API evidence

variant-picker.jsproduct-price.jsproduct-inventory.jsproduct-form.jssticky-cart-bar.jsmedia-gallery.jsphotoswipe-gallery.jsphotoswipe-wrapper.jsfslightbox.jsdrag-zoom-wrapper.jsaccordion-custom.jsshow-more.jsShopify section events

03Checkout readiness

Settle language, warehouse notes and installment context before the bike is added

A high-consideration European e-bike sale also depends on seeing delivery, local-inventory language and installment messaging in the current market, then picking compatible add-ons without leaving the cart path.

01Confirm region and language
02Read local-warehouse, delivery and warranty notes
03See installment messaging next to purchase
04Add compatible accessories and continue to checkout

Implementation

localization.js and the header localization form own market switching; variant-picker.js only consumes the sellable configuration already in the catalog.
Warehouse, delivery and warranty notes stay in editable content sections. Power and speed wording can change by destination while core specification fields are reused across languages.
product-recommendations.js calls the Product Recommendations API from the current bike; product-form.js submits the add, and cart-drawer.js treats returned Cart Ajax JSON as the source for lines, quantity and discounts.

Deployment and acceptance

Installment messaging loads as a configurable storefront integration beside the purchase cluster, not inside variant-selection logic.
Quantity and discount updates continue through Cart Ajax change and update; recommendation failure never blocks the host product or checkout entry.

ResultWhat changes after implementation

Shoppers can check warehouse and installment context in the current market before add-to-cart, rather than meeting fulfilment surprises on the checkout page.
Accessories extend the same cart as the host bike instead of opening a second unexplained catalog.

View script and Shopify API evidence

localization.jsproduct-recommendations.jsProduct Recommendations APIproduct-form.jscart-drawer.jscomponent-cart-items.jscart-discount.jsCart Ajax: addCart Ajax: changeCart Ajax: update

Operational handoff

The operating team can continue after launch

Catalog and content

Collections cross bike type with ride use; brand remains a filter, not the only way in.
Power, torque, battery, range, sensor and frame are shared comparable fields; colour and sellable configuration sit on variants.
Accessories and spare parts attach by model context for recommendations, not as unstructured PDP lists.

Market operations

European multilingual shopping and EUR pricing are owned by the localization form and editable market content; checkout preload currently surfaces an en-DE locale context.
Local-warehouse, delivery and warranty notes live in content sections so operations can change fulfilment copy without touching variant or cart scripts.
Sellable models and power or speed wording stay merchandiser-editable by destination; installment messaging remains a configurable integration beside purchase.

Research notesPublic sources and verification boundary

Public research sources

Content verification

Industry, product and observable feature notes are verified against the brand site. Apps, admin configuration and commercial data that cannot be confirmed from the storefront are not inferred. WESWOO scope is stated only from project records and client authorization.

Public information last reviewed: 2026-08-12

Public research sources

Content verification

Turn your storefront into infrastructure for sustainable growth