starter-kittemplatesfirestore

Starter Kit: Decision Logic Micro App (Dining Picker) — Firestore Rules, Templates, and UI

ffirebase

2026-01-31

12 min read

Clone a lightweight dining decision micro app: Firestore model, security rules, auth flows, and minimal React UI to ship in hours.

Hook: Stop group decision fatigue — ship a lightweight micro app in hours

Decision fatigue in group chats is real: endless messages, five suggestions, and nobody can pick a place. If your team needs a fast, reusable micro app to solve this — for company socials, student groups, or friends — this starter kit gives you a production-ready blueprint you can clone and customize in hours. It includes a Firestore data model, security rules, auth flows, a minimal UI template, and notes on cost, scaling, and observability for 2026.

Why a Dining Picker micro app in 2026?

Micro apps exploded in popularity through 2024–2026 as non-developers and small teams adopted rapid 'vibe-coding' aided by AI assistants and low-code tooling. These apps are:

Small and focused—single-purpose, easy to maintain.
Composable—plug into larger platforms or embed in Slack/Teams or embed in Slack/Teams.
Realtime-first—users expect live updates (votes, presence).

That makes Firebase (Firestore, Auth, Functions) an excellent fit: realtime listeners, offline persistence, and simple auth integration let you ship fast while preserving security and scale.

Starter kit overview — what you get

Canonical Firestore data model for rooms, options, votes, and results.
Security rules that protect data and enforce role-based access.
Auth flows: anonymous, provider sign-in, invite links, and account linking.
Minimal React UI components you can clone and reuse.
Operational tips for cost, scaling, and monitoring in 2026.

Firestore data model (canonical)

Design goals: easy joins, few reads per user, and optimistic concurrency for votes. Use collection documents sized conservatively to avoid hot-spots.

Top-level collections

rooms (roomId)
rooms/{roomId}/options (optionId)
rooms/{roomId}/votes (voteId or userId)
users (uid)
invites (token)

rooms document shape

{
  name: string,          // e.g., "Friday Lunch"
  creatorId: string,     // uid
  createdAt: timestamp,
  status: string,        // 'open' | 'closed' | 'revealed'
  settings: {
    allowMultipleVotes: boolean,
    anonymity: 'named' | 'anonymous',
    voteLimit: number | null
  },
  result: { optionId: string | null, computedAt: timestamp | null }
}

options document shape

{
  title: string,         // "Taqueria El Sol"
  url?: string,          // link to menu or map
  createdBy: uid,
  createdAt: timestamp
}

votes document shape

Two patterns: 1) store each user's vote in a document with their uid as the ID (fast reads); 2) for anonymous, create vote documents with a generated id. We recommend the uid-as-id pattern for clarity.

{
  userId: uid,
  optionId: string,
  createdAt: timestamp
}
// doc id: userId

invites document shape

{
  token: string,          // short, unguessable
  roomId: string,
  createdBy: uid,
  expiresAt: timestamp,
  maxUses: number | null
}

Design patterns and read/write strategy

Read-efficiency: use a single room document as the primary payload; load options via a small collection query and votes via onSnapshot for live tallies.
Realtime tallies: keep client-side tallies via snapshot listeners, or use a small aggregate in rooms.result for quick reads when revealing results.
Write contention: store votes per-user (doc id = uid) to avoid hotspots and simplify rules.
Analytics-friendly: optionally export events (vote.created) to BigQuery / Firestore export using BigQuery or Firestore export using Cloud Functions for post-analysis and cost tracking.

Security rules — enforce ownership, anonymity, and rate limits

Rules below are conservative, support anonymous users, and require account linking for sensitive actions. Replace placeholders like request.auth.uid checks with your specific fields as needed.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Public room metadata: readable, but writes by creator only
    match /rooms/{roomId} {
      allow read: if true;
      allow create: if request.auth != null;
      allow update: if request.auth != null && resource.data.creatorId == request.auth.uid;
      allow delete: if request.auth != null && resource.data.creatorId == request.auth.uid;

      // Options within a room
      match /options/{optionId} {
        allow read: if true;
        allow create: if request.auth != null && get(/databases/$(database)/documents/rooms/$(roomId)).data.status == 'open';
        allow update, delete: if request.auth != null && resource.data.createdBy == request.auth.uid;
      }

      // Votes: one vote document per user id recommended
      match /votes/{voteId} {
        allow read: if request.auth != null;

        // Only allow a user to create or modify their own vote doc
        allow create: if request.auth != null && request.auth.uid == voteId && get(/databases/$(database)/documents/rooms/$(roomId)).data.status == 'open';
        allow update: if request.auth != null && request.auth.uid == voteId && get(/databases/$(database)/documents/rooms/$(roomId)).data.status == 'open';
        allow delete: if request.auth != null && (request.auth.uid == voteId || get(/databases/$(database)/documents/rooms/$(roomId)).data.creatorId == request.auth.uid);
      }
    }

    // Users collection: readable only to the authenticated user
    match /users/{uid} {
      allow read, write: if request.auth != null && request.auth.uid == uid;
    }

    // Invites: only creators can create tokens, validation read-only
    match /invites/{token} {
      allow create: if request.auth != null;
      allow read: if true;
      allow delete: if request.auth != null && resource.data.createdBy == request.auth.uid;
    }
  }
}

Notes: These rules expect that the client cannot arbitrarily change room.status to 'revealed' — only the creator should change it. Enforce complex business logic (rate-limits, maxUses) using Cloud Functions or Firestore transactions.

Auth flows — support both quick access and persistent identity

Design goals: let people join fast (low friction) while enabling persistent identity for audit and account linking.

Flow A — Quick join (Anonymous)

Sign in anonymously: low friction for social gatherings.
User can add options and vote, but limited by session-only identity.
Offer in-app prompt to link account (Google/Email) for permanent history and cross-device sync.

Flow B — Authenticated (recommended)

Sign in with Google/Email (or SSO for enterprise).
Creator creates room; invite tokens or shareable roomId added to clipboard or chat.
Members join via provider-based sign-in or via an invite token that creates a temporary session if they decline to sign in — encourage linking later.

Implementing invite tokens

Invite workflow: creator creates an invite doc with a short random token. When a user follows the link, your UI resolves the token and adds the user to an ephemeral membership list or prefills roomId.

// Example: create invite cloud function (pseudo)
const token = nanoid(8);
await addDoc(collection(db, 'invites'), {
  token,
  roomId,
  createdBy: auth.uid,
  expiresAt: serverTimestamp() + 24*60*60*1000,
  maxUses: 10
});

Minimal UI components — React (modular Firebase SDK)

The design is intentionally minimal so non-devs can fork and tweak. We provide four components: RoomList, CreateRoom, RoomView (options + voting), and Results. Use Tailwind or plain CSS.

Bootstrap (client-side init)

import { initializeApp } from 'firebase/app';
import { getAuth, signInAnonymously, GoogleAuthProvider, signInWithPopup } from 'firebase/auth';
import { getFirestore } from 'firebase/firestore';

const firebaseConfig = { /* your config */ };
const app = initializeApp(firebaseConfig);
export const auth = getAuth(app);
export const db = getFirestore(app);

export async function quickSignIn() {
  if (!auth.currentUser) {
    try {
      await signInAnonymously(auth);
    } catch (e) {
      console.error(e);
    }
  }
}

export async function signInWithGoogle() {
  const provider = new GoogleAuthProvider();
  await signInWithPopup(auth, provider);
}

CreateRoom component (simplified)

function CreateRoom({ onCreated }) {
  const [name, setName] = useState('');
  async function handleCreate() {
    const docRef = await addDoc(collection(db, 'rooms'), {
      name,
      creatorId: auth.currentUser.uid,
      createdAt: serverTimestamp(),
      status: 'open',
      settings: { allowMultipleVotes: false, anonymity: 'named', voteLimit: null },
      result: { optionId: null, computedAt: null }
    });
    onCreated(docRef.id);
  }
  return (
    
       setName(e.target.value)} placeholder="Room name" />
      
    
  );
}

RoomView (options + voting)

Key ideas: use onSnapshot to show realtime updates, and write the vote as a document with id = uid to avoid collisions.

function RoomView({ roomId }) {
  const [room, setRoom] = useState(null);
  const [options, setOptions] = useState([]);
  const uid = auth.currentUser?.uid;

  useEffect(() => {
    const unsubRoom = onSnapshot(doc(db, 'rooms', roomId), snap => setRoom(snap.data()));
    const optsQuery = collection(db, 'rooms', roomId, 'options');
    const unsubOpts = onSnapshot(optsQuery, snap => setOptions(snap.docs.map(d => ({ id: d.id, ...d.data() }))));
    return () => { unsubRoom(); unsubOpts(); };
  }, [roomId]);

  async function vote(optionId) {
    if (!uid) return;
    const voteRef = doc(db, 'rooms', roomId, 'votes', uid);
    await setDoc(voteRef, { userId: uid, optionId, createdAt: serverTimestamp() });
  }

  return (
    
      {room?.name}
      {options.map(o => (
        
          {o.title}
          
        
      ))}
    
  );
}

Results (aggregate)

Client-side aggregation works well for small rooms. For large groups or to avoid trust issues, compute results with a Cloud Function and store them in rooms.result.

function Results({ roomId }) {
  const [counts, setCounts] = useState({});
  useEffect(() => {
    const votesRef = collection(db, 'rooms', roomId, 'votes');
    const unsub = onSnapshot(votesRef, snap => {
      const tally = {};
      snap.docs.forEach(d => {
        const { optionId } = d.data();
        tally[optionId] = (tally[optionId] || 0) + 1;
      });
      setCounts(tally);
    });
    return unsub;
  }, [roomId]);
  return (
    
      {Object.entries(counts).map(([optionId, c]) => ({optionId}: {c}))}
    
  );
}

Cloud Function: trustworthy result computation

When the room creator clicks 'reveal', trigger a callable function that:

Verifies caller is room.creatorId.
Runs a transaction to count votes and write rooms.result.
Sets room.status = 'revealed'.

exports.revealResult = functions.https.onCall(async (data, context) => {
  if (!context.auth) throw new functions.https.HttpsError('unauthenticated');
  const roomId = data.roomId;
  const roomRef = db.doc(`rooms/${roomId}`);
  const roomSnap = await roomRef.get();
  if (roomSnap.data().creatorId !== context.auth.uid) throw new functions.https.HttpsError('permission-denied');

  return db.runTransaction(async tx => {
    const votesSnap = await tx.get(roomRef.collection('votes'));
    const tally = {};
    votesSnap.forEach(v => { tally[v.data().optionId] = (tally[v.data().optionId] || 0) + 1; });
    const winner = Object.entries(tally).sort((a,b) => b[1] - a[1])[0]?.[0] || null;
    tx.update(roomRef, { 'result.optionId': winner, 'result.computedAt': admin.firestore.FieldValue.serverTimestamp(), status: 'revealed' });
    return { winner, tally };
  });
});

Operational guidance — costs, scaling, and observability

2026 trends: Teams increasingly optimize Firestore reads and favor server-side aggregation to cut costs. Use these best practices:

Minimize reads: use onSnapshot only on small collections (options, votes per room). Avoid full collection scans on large datasets.
Aggregate server-side: for rooms with >200 participants, compute tallies in Cloud Functions and store an aggregate.
Use Firestore bundles or prefetch when embedding rooms in emails or external pages to reduce client reads; for large embedded previews consider edge-powered prefetch techniques.
Monitor costs: export billing to BigQuery and create alerts using Cloud Monitoring for read/write spikes. Pair this with proxy and tooling playbooks (for teams that need observability and automation) like proxy management tools.
Protect against hot writes: don't store entire room activity in one document that updates per-vote; use per-user vote docs or batched updates.

Accessibility, internationalization, and UX tips

Make vote buttons large and keyboard-accessible. Use aria-live regions for live tallies.
Support date/time and language localization for international groups.
Provide a simple 'random pick' fallback — useful when votes tie or people want instant results.

Extensibility: where teams usually add integrations

Slack / Microsoft Teams bots to create rooms from chat and post results.
Maps / restaurant APIs (Yelp, Google Places) to auto-populate options.
Analytics export to BigQuery for corporate event insights; see collaborative & edge-indexing playbooks like Beyond Filing for integration notes.

2026-specific trends and future-proofing

Looking ahead, here are trends to design for:

AI-assisted personalization: add a recommendation layer (LLM or vector search) that suggests options based on participants' preferences. Use embeddings + Pinecone/Milvus or Firestore + vector DBs. See adjacent trends in developer tooling and preference-managed rooms for inspiration on preference-driven UX.
Edge compute: use edge functions for low-latency invite handling and link previews in 2026 platforms.
Privacy-by-default: prefer anonymous voting modes and ephemeral invites to comply with privacy-first workplace policies.

Troubleshooting & debugging checklist

Authentication errors: check provider setup and OAuth redirect URIs.
Security rules failing: use the Rules simulator and structured logging in production to see rejections.
Unexpected billing spikes: audit read patterns and snapshot usage; enable billing alerts.
Race conditions writing results: verify transaction success and idempotency in your Cloud Functions.

Pro tip: In 2026 many teams adopted a lightweight observability stack — Firestore + Cloud Logging + BigQuery for cost auditing — giving fast, actionable insights into which micro apps need optimization.

How non-developers can customize quickly

Non-devs can adapt this starter kit by:

Using the provided React components and swapping branding (CSS variables or Tailwind config).
Changing room settings via a simple JSON form in the UI and saving to rooms.settings.
Adding integrations by using Zapier / Make.com to call Cloud Functions webhooks for invites and results.

Checklist to clone and launch (under 2 hours)

Create a Firebase project and enable Auth providers (Anonymous, Google).
Enable Firestore and deploy the security rules above.
Clone the starter repo (role: front-end only); add your Firebase config.
Start the app locally, create a room, and share the link to test with friends.
Optional: deploy a small Cloud Function to compute results and create an invite generator. If you run live events or pop-ups, check field tools and printing workflows like field kit reviews or PocketPrint for event-friendly flows.

Actionable takeaways

Use per-user vote documents to keep writes idempotent and rules simple.
Protect room state by letting only the creator reveal results via a callable function.
Optimize reads with client-side snapshot listeners and server-side aggregates for large rooms.
Start anonymous to reduce friction, but encourage linking for cross-device persistence.

Further resources

Firebase documentation: Firestore, Auth, Cloud Functions (official docs).
Observability guides: export Firestore usage to BigQuery for cost analysis.
Micro app case studies from 2024–2026: lessons on rapid iteration and privacy. For pop-up and micro-market playbooks see Micro-Market Menus & Pop-Up Playbooks.

Final words — ship a useful micro app, not a reinvented platform

Micro apps shine because they solve a single, common pain — in this case, dining decisions — with minimal friction. This starter kit is intentionally opinionated: keep the data model small, secure access with strict rules, and prefer server-side aggregation when scale causes client costs to spike. In 2026, teams that pair lightweight frontend templates with robust security rules and simple server logic can iterate faster and safely hand the app off to non-dev owners.

Ready to get started? Clone the starter kit, drop in your Firebase config, and invite your first group. If you want a polished clone, sign up for the firebase.live starter templates and get a pre-configured repo, CI/CD and monitoring baked in.

Call to action: Fork the starter kit, deploy the Firestore rules above, and share your first room link with your team — then iterate with one integration (Slack or Maps). Need help customizing for enterprise SSO or analytics? Reach out on firebase.live for a consult and enterprise-ready template.

firebase

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.