Find Your Fate — setup guide

Two pages:

  • participant.html — the URL you send to guests (name entry → wait → live flower → certificate)
  • bride.html — the URL only the bride uses (tap to eliminate → drag-and-release the flower)

No server needed. Both pages talk directly to Firebase Realtime Database from the browser.

1. Create the free Firebase project (5 minutes)

  1. Go to https://console.firebase.google.com → Add project → give it any name → you can skip Google Analytics.
  2. Once created, click the </> (web app) icon on the project overview page → register an app (any nickname, no need for Firebase Hosting yet) → it will show you a firebaseConfig object like: 
    {
  apiKey: "AIza...",
  authDomain: "your-project.firebaseapp.com",
  databaseURL: "...",  // not shown yet, added in step 3
  projectId: "your-project",
  ...
}
  3. In the left sidebar go to Build → Realtime Database → Create Database. Choose any region close to you. Start in test mode for now (rules below tighten this).
  4. Copy the databaseURL shown at the top of the Realtime Database page (looks like https://your-project-default-rtdb.firebaseio.com).
  5. Open both participant.html and bride.html in a text editor and paste your real values into the FIREBASE_CONFIG object near the top of each file (apiKey, authDomain, databaseURL, projectId).

2. Set database rules

In Realtime Database → Rules, replace the default with this. It allows anyone to read game state (needed for the live sync) and to create their own participant entry, but not to rewrite other people’s data or invent new top-level structure:

{
  "rules": {
    "state": { ".read": true, ".write": true },
    "winner": { ".read": true, ".write": true },
    "flower": { ".read": true, ".write": true },
    "meta": {
      "nextColorIndex": { ".read": true, ".write": true }
    },
    "participants": {
      ".read": true,
      "$id": {
        ".write": true,
        ".validate": "newData.hasChildren(['name','color','status','joinedAt'])"
      }
    }
  }
}

This is intentionally open (no login) so guests can join instantly by scanning a QR code — appropriate for a five-minute, low-stakes game with only first names in it. There’s no sensitive data stored. Delete the Realtime Database (or the whole Firebase project) after the wedding if you’d rather not leave it publicly writable indefinitely — takes 30 seconds in the console.

3. Fill in the certificate details

Near the top of participant.html:

const EVENT_CONFIG = {
  coupleNames: "Mesut & ——",
  date: "—— 2026",
  location: "——"
};

4. The host passcode

bride.html has a simple 4-digit gate near the top of the file:

const PASSCODE = "1234";

Change it to whatever you like. This only deters a guest from accidentally opening the control page — it is not real authentication (there’s no login system), so don’t rely on it for anything sensitive.

5. Host the two files for free

Any static file host works since there’s no backend server. Easiest options:

  • Firebase Hosting (same project, genuinely free, gives you a https://your-project.web.app URL): 
    npm install -g firebase-tools
firebase login
firebase init hosting     # pick your project, public dir = the folder with these 2 files
firebase deploy
  • GitHub Pages or Netlify (drag-and-drop the folder) also work fine — just plain HTML files.

Once deployed you’ll have two URLs, e.g.:

  • https://your-project.web.app/participant.html → put this in your QR code for guests
  • https://your-project.web.app/bride.html → keep this one to yourself

6. Rehearse before the day

Open bride.html, tap Reset game any time to wipe all test participants and start clean. Open participant.html on a few phones/laptops to simulate guests joining, eliminate a few, then drag the flower to the top zone and release to test the winner flow end-to-end, including the “Save my certificate” download button.

Capacity check (your numbers: ~50 devices, ~5 minutes)

Firebase’s free Spark plan allows:

  • 100 simultaneous Realtime Database connections (you’ll use ~51: 50 guests + the bride’s screen)
  • 1 GB stored, 10 GB/month downloaded

A 5-minute session with 50 devices watching a dozen small flower-position updates per second totals a few megabytes for the whole event — nowhere close to any limit. No paid plan is required.

How the game logic works, in case you want to tweak it

  • Firebase path /participants/{id} holds each guest’s name, assigned colour, and status (waiting / eliminated / winner).
  • /meta/nextColorIndex is incremented atomically on each join so two guests never get the same colour by a race condition (it cycles through a 14-colour palette).
  • /state (registration → tossing → result) tells every open page which screen to show.
  • /flower holds x/y as percentages of the viewport — that’s why it lines up identically on every phone regardless of screen size, per your spec.
  • When the bride releases the flower inside the drop zone (top ~20% of her screen), her page picks a random winner from everyone still waiting, writes /winner, and flips /state to result. Every open participant page reacts instantly.
  • The “you’ll find your fate until 3 times” line is used as flavor text on both the elimination toast and the certificate, exactly as you described it — the app doesn’t currently run three separate rounds. Say the word if you’d actually like three sequential toss rounds (three winners) instead of one, and I’ll extend the state machine for that.