Bicycles and electric bicycles
AMZcycle
AMZcycle spans commuter, mountain, gravel and cargo e-bikes. The storefront connects high-spec differentiation, rider sizing and US local service within one high-value buying journey.
Visit the live project
Core implementation review
Three storefront journeys from model choice to purchase
AMZcycle sells commuter, mountain, gravel and cargo e-bikes. The job is not to advertise a maximum range figure, but to make models such as Defender and Paladin comparable by use, then turn rider height into a sellable frame size. The two journeys below are the ones that close that path.
Project context
Define how customers choose before defining the storefront
Customers enter through E-Urban, E-XC, E-Gravel or E-Cargo, then compare models such as Paladin, Ranger, Aerolife and Wildlife by use, rider size, power, range and capacity. Local shops, financing, warranty and delivery remove final risk.
WESWOO makes premium bikes understandable by use, size and specification while bringing local service into transaction trust. The store is not merely a catalog; it supports selection and ownership assurance.
Turn riding use into a comparable shortlist, not a stack of range claims
Shoppers entering through E-Urban, E-XC, E-Gravel or E-Cargo should compare motor, torque, range, weight and load on one field set, then open a dedicated model page.
- 01Enter by riding scenario or selection guide
- 02Align candidates on one specification set
- 03Open the model page for construction and on-trail proof
Implementation
- The live catalog is organised by use. Defender, Paladin and related models keep their own product pages, so shortlisting happens in collections and comparison—not inside an unfilterable description.
- Motor, range, weight and load live in a comparable content layer. Clean side profiles and data icons do the alignment; outdoor riding frames prove terrain capability without replacing the spec read.
- Predictive Search returns product and collection suggestions as the shopper types, so a model name or use-case term still lands in the right range.
Deployment and acceptance
- Scenario copy, specification fields and comparison cards stay in collection/product templates and theme settings, so a new gravel or urban model reuses the same structure.
- Home and listing carousels run on Swiper and re-initialise after Shopify section updates, so editor saves do not leave cards unable to swipe.
- Locks, bags and similar accessories attach by model fit after the host bike is chosen, rather than competing during the shortlist.
- Shoppers can cut the range by terrain, then arrive on a PDP with a clear use in mind.
- New models that follow the same scenario and specification fields enter browse, comparison and search without a separate selection template.
View script and Shopify API evidence
Predictive Search APItheme.jsswiper-bundle.min.jsSwiperShopify section eventsPut frame size on the cart line, not on a geometry chart that belongs to another option
Rider height has to drive colour, availability and the variant that enters the cart. Sizing guidance sits beside the control it affects, so a shopper never studies one chart and purchases another frame.
- 01Confirm the model and riding use
- 02Match rider height to a frame size
- 03Sync colour, price and availability
- 04Add that variant to the cart
Implementation
- Frame size and colour are Shopify variants on the purchase task. Sellable configuration lives on the product and variant objects, not in copy that cannot be submitted.
- Sizing guidance sits next to the option control. The product page loads SizingPlugin so geometry advice stays inside the buy area instead of sending the shopper to a disconnected chart.
- Cart Ajax add submits the active variant; Cart Ajax change updates quantity. The size and colour on the page and the line in the cart remain the same identity.
Deployment and acceptance
- Specifications, sizing notes, class language and service copy stay in templates and theme settings, not inside theme.js, so merchandisers can edit by model.
- Variant and form behaviour are bundled in theme.js; the buy area rebinds when a section reloads rather than assuming a single page-load pass covers editor updates.
- Unavailable sizes, sold-out states and add-to-cart are distinct. The sizing plugin loads per product page; native variant selection remains if the widget does not.
- Fit and purchase happen in one buy area: whether the bike suits the rider, and which size and colour will be ordered.
- New colours or sizes are merchandised as variants and inventory, without rebuilding a purchase flow for each bike.
View script and Shopify API evidence
theme.jsSizingPlugin.prod.jsCart Ajax: addCart Ajax: changeShopify section eventsOperational handoff
The operating team can continue after launch
- The catalog is merchandised by riding use—E-Urban, E-XC, E-Gravel, E-Cargo—with dedicated products such as Defender and Paladin so shortlists form by terrain.
- Frame size and colour are sellable variants; motor, torque, range, weight and load are maintained as comparable fields.
- Locks, bags and similar accessories attach by model fit after the host bike is chosen.
- The public storefront is English with USD by default and checkout preloads use en-US. Class language, regional stock, delivery and warranty stay in merchandiser-editable content, not in theme.js.
- Dealer, financing and service notes live in theme settings or content sections so the US market can change them without a vendor-bundle release.
- Wallet and payment-term messaging can appear on the theme; destination rules still sit in content and inventory.
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