E-Bikes: a Salesforce sample app pairing Lightning Web Components with Experience Cloud

What the sample demonstrates and what it is for

E-Bikes is a sample application that demonstrates how to build applications with Lightning Web Components and integrate with Salesforce Experiences. E-Bikes is a fictitious electric bicycle manufacturer, and the application helps it manage products and reseller orders using a rich user experience.

The fictional frame is deliberate and it is the standard way Salesforce ships reference applications. A retail domain gives the components something to do that is concrete enough to be instructive: a product has an image, a price and a stock level, an order has a customer and a reseller, and a flow has to move between those. A generic demo would show you a list of records and teach you nothing about the parts that are hard.

The repository is not a tutorial to read top to bottom, and the README makes that clear. It points at the Quick Start: Explore the E-Bikes Sample App Trailhead project and a short presentation video for the guided path, and the table of contents is a set of installation and tooling procedures rather than a conceptual walkthrough. Salesforce's own guidance is that the app is designed to run on Salesforce Platform, and that anyone wanting to experience Lightning Web Components on another platform should use lwc.dev and the open source LWC Recipes sample instead.

That is an honest distinction between a sample that runs on a vendor platform, where the platform is part of the environment, and a sample that runs anywhere. It also tells you where the platform-specific parts live: the Experience Cloud site, the guest user profile and the Apex that sits behind the components.

Installing into a scratch org, step by step

The scratch org path is the recommended one, because it is disposable and the configuration is repeatable.

The prerequisites come from another Trailhead project: enable Dev Hub in your Trailhead Playground, install the Salesforce CLI, install Visual Studio Code, and install the Visual Studio Code Salesforce extensions including the Lightning Web Components extension. Then you authorize the hub org and give it an alias:

sf org login web -d -a myhuborg

Clone the project and create the scratch org from its definition file, giving it the alias ebikes:

git clone https://github.com/trailheadapps/ebikes-lwc
cd ebikes-lwc

sf org create scratch -d -f config/project-scratch-def.json -a ebikes

Then you push the app, assign the permission sets the app needs, import sample data and publish the site:

sf project deploy start

sf org assign permset -n ebikes

sf org assign permset -n Walkthroughs

sf data tree import -p ./data/sample-data-plan.json

sf community publish -n "E-Bikes LWR Site"

There are two permission sets to assign, which is a detail that catches people out. The ebikes set is the app's own access model and the Walkthroughs set drives the guided tour.

The Experience Cloud site needs one more deployment, for the guest user profile, with a wait of 10 seconds between component operations:

sf project deploy start --metadata-dir=guest-profile-metadata -w 10

Finally you open the org with sf org open, and in Setup, under Themes and Branding, you activate the Lightning Lite theme before selecting the E-Bikes app in the App Launcher.

That theme step is not optional decoration. The Experience Cloud site renders in the theme you activate, and the sample assumes the Lightning Lite theme, so an org with a different active theme will not look like the sample at all.

The permanent org path and its extra prerequisites

The second installation route is for a more permanent environment: a free Developer Edition Org or a Trailhead Playground. The README is clear that you should start from a brand-new environment to avoid conflicts with previous work.

There are two extra platform-level steps here that the scratch org does not need.

First, Experiences has to be enabled manually. In Setup, under Digital Experiences, you click the Enable Digital Experiences checkbox and save. Then, under Experience Management Settings, you enable the Enable ExperienceBundle Metadata API flag and save again. That second flag is what makes the ExperienceBundle metadata deployable, and without it the site publishing step later has nothing to publish.

Second, the site metadata file has to be edited by hand. You open force-app/main/default/sites/E_Bikes_LWR_Site.site-meta.xml and replace the value between the siteAdmin tags and the value between the siteGuestRecordDefaultOwner tags with your Playground username. The site has to know who owns it and who the guest user maps to, and in a Playground those are your own username.

There is also a schema fix-up, which is worth reading because it shows the shape of the sample data. You remove the Product custom field from the Case object, through Object Manager, Fields and Relationships, and the row menu's Delete option. The README then reminds you to deploy the app with sf project deploy start -d force-app, assign the permission sets, import the sample data, publish the site, deploy the guest profile metadata, open the org and activate the theme.

The order matters in a way that is easy to get wrong. The site metadata edit has to happen before the deploy, and the schema change has to happen before the sample data import, or the import fails on a field the data plan expects.

The tooling: Jest, UTAM, Code Tours and a pre-commit hook

The repository's package.json shows the development setup, and it is a good illustration of what a Lightning Web Components project actually needs.

Unit tests run through sfdx-lwc-jest, the standard Jest wrapper for the framework, with watch, debug and coverage variants, and the script is named test:unit. The project also carries jest-sa11y-setup.js, which wires the sa11y accessibility checker into the Jest environment, and the @sa11y/jest dependency. That is the kind of detail that distinguishes a sample intended for real use from one that only demonstrates the happy path, because an accessibility regression in a component is exactly the kind of thing that goes unnoticed until a screen reader user hits it.

UI tests use UTAM, with a compile step through utam -c utam.config.js, a generated login URL script, and the tests themselves run under WebdriverIO with a wdio.conf.js. The split between unit and UI tests is the sensible one: components are tested in isolation with Jest, and the assembled experience is tested in a browser.

Code formatting is Prettier, with a verify mode as well as a write mode, and the file glob covers cls, cmp, component, css, html, js, json, md, page, trigger, xml, yaml and yml, which is a good indication of how much Apex and metadata this project actually contains alongside the JavaScript. Linting is ESLint with the @lwc/eslint-plugin-lwc and @salesforce/eslint-config-lwc plugins, plus a specific plugin for Lightning, and the prettier configuration includes a plugin for XML because metadata files have to be formatted too.

Hooks are handled with Husky, and lint-staged runs the right checks per file type: Prettier for the metadata and Apex files, ESLint for LWC JavaScript, and the Jest runner for the lwc directory with --bail --findRelatedTests and --passWithNoTests. That last flag matters, because it lets a commit with no related tests pass rather than failing the hook.

There is also a .tours/ directory for Code Tours, the in-editor guided walkthrough, and a scripts/ directory, and the top-level tree carries sfdx-project.json, the standard Salesforce project file.

Limits: a vendor-locked sample and a fictional data model

The limits are the ones that come with the shape of the project rather than with any fault in it.

The first is that it only runs on Salesforce Platform. The README says so directly and points to lwc.dev and the LWC Recipes open source sample for anyone who wants the components on another platform. That is a real constraint on reuse: the components are built against Salesforce data and Apex, and the Experience Cloud site, the guest profile and the permission sets are all platform-specific.

The second is that the domain model is specific. E-Bikes is a fictitious manufacturer with products, resellers and orders, and the Case object carries a Product field that you are told to delete in the permanent org path. Copying this project into an unrelated application means removing a domain, not adding to one.

The third is that the permission sets are part of the sample's behaviour. The app needs the ebikes set to work and the Walkthroughs set to drive the tour, which means the data access model is part of what you are studying. That is a good thing to learn from, and a complication to strip out.

The fourth is the setup cost. A scratch org requires Dev Hub, the CLI, Visual Studio Code and its extensions, and a working hub alias, and the Developer Edition path adds manual toggling of platform settings and a hand-edited metadata file. This is not a project you can clone and run; it is a project you clone and configure against a live platform.

The fifth is licensing and ownership. The package is marked CC0-1.0 in the metadata and the repository carries a LICENSE file, and it is published by salesforce.com under the trailheadapps organisation. The sample data is fictional, which removes one category of concern, but the app's structure is the vendor's own recommended pattern, so reading it teaches you the platform's preferences as much as the platform's capabilities.

The sixth is that the last push was on 2026-10-14 with no GitHub releases, so there is no version history to consult. The repository carries a CHANGELOG-style convention through the commit history and a code of conduct and contributing guide, and the sample is expected to be kept current against the platform rather than pinned.

E-Bikes against the open source LWC recipes and against building from a component generator

Two comparisons make the choice clearer.

The first is against the open source LWC Recipes sample. The README itself points there for anyone who wants Lightning Web Components on a platform other than Salesforce, and the difference in approach is the environment. LWC Recipes runs on the standard web stack with a mock API, so the components can be developed and tested without a Salesforce org at all. E-Bikes runs on the platform, so the components are wired to real platform data, real Apex and a real guest user, and the Experience Cloud site, the permission sets and the sample data are all part of the demonstration.

That is the trade. Recipes teaches you the components. E-Bikes teaches you the components as they are actually deployed, including the parts that are awkward: deploying to an org, publishing a site, configuring a guest profile and handling permissions. If you are going to work on Salesforce, E-Bikes is the more useful of the two even though it is harder to run.

The second comparison is against scaffolding a new component with a generator. The generator gives you a component with the right file structure, and for a greenfield project that is the right starting point. The difference in approach is that a sample application shows the decisions that a generator cannot: how a component gets its data, where the query lives, how the components compose into a page, and how the platform objects and the UI fit together. A generator gives you the shape of one component; the sample gives you the shape of an application.

The practical recommendation is to do both in order. Run a generator to see the minimal component, then read E-Bikes to see the application, and use the Trailhead project rather than the repository README when you want the guided version, since the tour explains the intent behind the code that the README only enumerates.

Editorial conclusion

Adopt E-Bikes as the reference project if you are learning Lightning Web Components with Experience Cloud and want to see the whole pattern rather than isolated components, since the value is in how the pieces fit together. Do not adopt it as a starting point for an unrelated application without stripping the domain, because the data model, permission sets and guest profile are specific to the retail scenario. Verify first that you have Dev Hub and the Salesforce CLI set up, that the ExperienceBundle Metadata API is enabled before you publish the site, and that the org you use is a brand-new one if you are following the Developer Edition path.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. Project website
4. README
5. trailheadapps/ebikes-lwc on GitHub