Hoverboard: a conference site template that assumes the venue WiFi will fail

A template written by people who run conferences

Hoverboard is a conference website template that helps you set up a mobile-first conference website with blog, speaker and schedule management in a few minutes.

The provenance is the first thing to understand about it. The template is created based on 7 years of GDG Lviv team experience of running conferences and feedback from more than 500 event organizers from all around the world who were using previous Hoverboard versions. The stated goal is to allow event organizers to set up a professional conference website with minimum resources, and the stated price of entry is basic knowledge of web technologies and a free Firebase account.

That is a much better fit than the usual template, which ships a beautiful site with content about a fictional conference and no idea what a real one needs. The people behind Hoverboard have run conferences. The feature list reflects the resulting priorities, and the vocabulary of the feature table is the vocabulary of an event organiser rather than a front-end developer: My schedule, an attending page, session feedback, reactions.

The user is a volunteer or a small organising team with a website to build in the week before tickets go on sale. The maintainer is Abraham Williams, and the README credits the original authors Oleh Zasadnyy and Sophie Huts. There is also a note worth repeating for anyone deploying this publicly: GDG[x] is not endorsed and/or supported by Google, the corporation.

The documentation is structured for that user. There is a set up guide at `docs/tutorials/00-set-up.md` and a full documentation directory, and the README points there as the first port of call.

The offline assumption and the venue WiFi problem

Two features in the table stand out because they encode an experience the authors clearly had many times.

The first is Works offline, described in the table as "shitty WiFi on the venue is not a problem anymore". The second is the Attending page, which collects directions, doors, accessibility, hotels and Wi-Fi information in one page that works offline at the venue.

This is the insight behind the whole project. A conference website is used in exactly the places where connectivity is worst: in the venue, in a packed hall on conference wifi, in a basement, in a queue. A site that degrades gracefully there is worth more to an attendee than a faster one that needs a connection. The attending page is the clearest expression of that idea, since the practical questions a visitor has on arrival are exactly the ones that fail when the network does.

The offline behaviour is implemented with a service worker, and the site is a progressive web app that can be installed as a native app on a phone. The performance claim in the table is a 91 out of 100 PWA score on Lighthouse, measured against a WebPageTest run linked from the README.

The rest of the feature list follows the same pattern of solving event problems rather than demonstrating web capabilities. Push notifications remind people about sessions in My schedule, about session feedback, or send a custom message to target users. My schedule lets attendees save the sessions they want to visit. Reactions let attendees react to sessions with applause, love and more. The blog is for announcements and updates. The theme is light and dark with your own colours and fonts.

SEO is in the list too, because a conference site is a marketing site as well as a schedule, and being indexed for the sessions and speakers is part of the job.

Firebase holds the content, so does your event data

Speakers and schedule management is the entry in the feature table that describes keeping and updating all information in Firebase. Firebase is also listed in the technology stack, alongside LitElement, Redux, a Service Worker and CSS Grid, with Polymer 3 marked as deprecated with a link to issue 796.

That is a coherent architecture for a template, and it explains the design constraints. The site is a client-side application whose data lives in Firestore, which is why the content management features need no separate CMS and no admin server, and why the whole thing can be hosted as static files with a Firebase project behind it.

The trade is the usual one. You get a working content model, attendee features and a deploy path in minutes, and in exchange your event's data lives in a Google account, your site's runtime depends on the Firebase client SDK, and a real event with a real audience is running on a free tier of a service whose limits are not designed around you.

The `firebase.json` at the repository root and the `packages/` directory show the shape of the current codebase. It is an npm workspace with separate packages for the web application, a CLI, a server component and a storage component, plus a translations package, and the root `package.json` orchestrates them with prefixed scripts. The install step runs a `postinstall` that installs the server, CLI, web and storage packages, and there are separate scripts for building the web package, deploying, running the doctor command and starting the emulators.

For a local run, the root `package.json` has a `serve` script that starts the Firestore emulator with a demo project, which is the fastest way to see the template populated with data before you connect it to your own Firebase project.

The hb command and the upgrade branch workflow

The upgrade story is the part of Hoverboard that most template documentation skips, and it is handled by a bundled tool rather than by hand.

The command is:

./hb upgrade

The README describes what it does in detail. It shows the release notes, merges the release into a new branch named `upgrade/v<version>`, and resolves the lockfiles and `package.json` files itself. It then installs, migrates your config, builds and commits, and offers to open a pull request. On other conflicts it stops, and you resolve them and then run `./hb upgrade --continue`, or go back with `./hb upgrade --abort`. The pull request is then merged with a merge commit, not a squash.

Three things in that description are worth pausing on. The upgrade works on a branch and offers a pull request, so a version bump is reviewed like any other change to your site. The lockfiles are resolved automatically, which matters in a project with this many workspace packages. And the merge must be a merge commit rather than a squash, which is a specific instruction to the human doing the merge, because the tool's state depends on the history.

The documentation for the release process lives at `docs/releases.md`, with the upgrading section as the anchor.

The development workflow around it is modern and worth noting if you plan to contribute. The root `package.json` requires Node 22 and npm 10, and the scripts are split per package with a prefix, so a build is `npm run build` and the emulators are `npm run emulators`. The lint story is unusually thorough, with separate scripts for eslint, prettier, syncpack for dependency version consistency, the lit analyzer for the web components, the translations check, and type checks for Astro, the server, storage, translations and the web package. The test runner is Vitest, configured in `vitest.config.ts`, and releases are handled with release-please and its manifest.

A README that describes a stack the repository has partly left behind

There is a mismatch in this repository between the README and the code, and it is the kind of thing a prospective user will hit within an hour.

The README's technology stack lists Polymer 3, marked deprecated with a link to issue 796, plus LitElement, Redux, Firebase, a Service Worker and CSS Grid. The repository itself is a TypeScript npm workspace with `packages/` for the web app, the CLI, the server, the storage layer and the translations, with an `AGENTS.md`, a `vitest.config.ts`, a flat `eslint.config.js`, a `syncpack` configuration and a release-please setup.

So the project is being actively maintained, and the last push to `main` was on 2026-10-17, but the README's stack list still reflects the earlier generation of the codebase rather than the current one. The type checking scripts even mention Astro in the web package, which is not in the README's list at all.

The practical consequence is that the README should be read as the user-facing overview and the repository as the truth about the build. If you are evaluating whether to adopt this, look at `packages/` and the root `package.json` rather than at the technology list, and expect to read the set up guide in `docs/` with that discrepancy in mind.

The release history is the other thing to reconcile. The most recent tags are v3.0.0 and v2.3.2, both from 2020-02-24, and v2.3.1 from 2020-02-10, and the root `package.json` still reports version 3.0.0. The last push was in October 2026, so the code is moving while the tags are from 2020. A new user is therefore installing from a branch that has six years of changes on top of a tag that says 3.0.0, and the `hb upgrade` command, which shows release notes and merges a release branch, operates on tags that are six years old.

The compatibility statement is another one to test rather than assume: Hoverboard is compatible with the latest two major versions of browsers that support ES Modules, which is a moving target rather than a fixed one.

Licence, hosting costs, and when a template is the wrong answer

The README says the project is published under the MIT license, with the file at the root, and adds a request rather than a condition: feel free to clone and modify the repo as you want, but don't forget to add a reference to the authors. The licence file in the repository is `LICENSE.md`.

That said, the licence recorded in the project metadata for this repository is other, a custom licence that GitHub cannot classify, which does not match the MIT statement in the README. If you are going to fork and redistribute, read the `LICENSE.md` file itself and resolve the discrepancy rather than assuming which one is authoritative. This is a description of the files, not advice on how to apply them.

The cost side of the decision is Firebase. The template's value proposition is minimum resources, and a free Firebase account is the stated prerequisite, but a conference that runs push notifications to a few thousand attendees, serves attendee features like My Schedule and reactions, and hosts a public schedule for search engines is not a small account. Someone has to look at the billing console during the event, and that is a real operational commitment that the template does not make for you.

The wrong-tool cases are more common than the feature list suggests. If your event needs a registration and ticketing flow integrated with a third party, the template does not cover it and you will be writing it yourself. If you need the content to live in a CMS your marketing team already uses, Firestore is the wrong answer. If you need to guarantee behaviour on a locked-down corporate network, a service worker and a client-side app are a liability.

The alternative approach is a static site generator with a hosted CMS, which gives you ownership of the content and predictable hosting cost, and gives up the offline behaviour and the Firebase-native attendee features. The difference in approach is exactly the trade Hoverboard makes: a runtime-driven application that works on bad networks, versus pre-rendered pages that are cheap and fast but need a connection.

For a single-venue conference in a place with good connectivity, the static site is the smaller commitment. For a multi-track event where attendees move between rooms on a saturated network and use My Schedule all day, the offline behaviour is the reason to accept the Firebase dependency.

Editorial conclusion

Adopt Hoverboard if you are organising a conference with a small team, you want a professional site with schedule and speaker management in a few minutes, and you accept Firebase as the backend and as a cost. Do not adopt it if you need a content model you control, if your event cannot live on Google infrastructure, or if you need a supported product, since the project is a community template with a volunteer maintainer. Verify three things first: that the set up guide in `docs/tutorials/00-set-up.md` matches the current monorepo layout, since the README still lists a stack the repository has partly moved past, that the `hb` upgrade flow works on a clean clone before you rely on it to migrate your own configuration, and that the licence file at the root is the MIT terms the README describes.

Frequently asked questions

Official sources

1. gdg-x/hoverboard on GitHub
2. Issues
3. Project website
4. README
5. Releases