I Built a Live Event Platform with Claude Code — and It Runs for $2 a Month

I build Kubernetes platforms for a living, so there's a certain irony in what I'm about to say: one of the most satisfying things I shipped recently has no cluster, no nodes, and no monthly infrastructure bill worth mentioning. It's a live event platform for Build With AI Sri Lanka — Google sign-in, role-based access, a live agenda, audience Q&A, project voting and a real-time leaderboard — and it runs for about $2 a month on Firebase.

I built it with Claude Code. This is the story of both halves: what building agentically with Claude actually felt like, and why a full-featured live app costs roughly the price of a coffee.

What the platform does

It's the software layer for a live hackathon:

• Google authentication so attendees, judges and organizers sign in with one tap.
• Role-based access — admin, judge and participant each see a different surface.
• A live agenda the organizers can update in real time.
• Audience Q&A during sessions.
• Project voting with a live leaderboard that updates as votes land.

All of it real-time, all of it multi-role, all of it needing to hold up while a room full of people hit it at once during the event — and then go quiet for the rest of the month.

Architecture

Nothing exotic. A Next.js front end on Firebase Hosting, Firebase Auth for identity, Firestore as the real-time database, and Cloud Functions for the server-side logic that can't be trusted to the client. GitHub Actions ships it.

flowchart TD
    U[User browser] --> H["Firebase Hosting (Next.js + React)"]
    H --> A["Firebase Auth: Google sign-in"]
    A --> R{"Custom-claims RBAC"}
    R -->|admin / judge / participant| FS[("Firestore realtime")]
    H --> FS
    H --> CF["Cloud Functions"]
    CF --> FS
    GA["GitHub Actions CI/CD"] -. deploy .-> H
    GA -. deploy .-> CF

The important design decision is where authorization lives. Anything a participant shouldn't be able to do — tallying votes, mutating the agenda, resolving Q&A — goes through a Cloud Function that verifies the caller's identity and role before it touches Firestore. The client is never trusted to grant itself a permission.

Here's the voting path, which is the part that most needed to be tamper-resistant:

sequenceDiagram
    participant P as Participant
    participant App as Next.js app
    participant Fn as Cloud Function
    participant DB as Firestore
    P->>App: cast a vote
    App->>Fn: callable submitVote (with ID token)
    Fn->>Fn: verify auth, check role, de-duplicate
    Fn->>DB: write the vote
    DB-->>App: realtime leaderboard update

Building it with Claude Code

I built this agentically — describe the feature, let Claude Code generate and wire it, run it, correct course, repeat. A few honest observations from doing it that way:

Where it flew. Scaffolding the Next.js app, standing up the Firebase SDK wiring, building out the agenda / Q&A / leaderboard UI, and turning "add a page that does X" into working screens — this is where an agent earns its keep. The loop from idea to something-on-screen was short enough that I could actually explore designs instead of committing to the first one.

Where I stayed in the driver's seat. The things that would hurt if they were wrong didn't get delegated. The authorization model — which role can do what, and enforcing it on the server via custom claims — was mine to own. So was the data model: getting Firestore documents shaped so the leaderboard stays consistent under concurrent votes, and so realtime listeners don't fan out into a surprise bill. And cost: keeping work on the client and in cheap reads/writes rather than reaching for heavier services.

The honest summary is that Claude Code moved the typing to near-zero and left the engineering — the security and data-modeling judgment — exactly where it should be. That's a good division of labour, not a threat to it.

The $2 economics

Here's why a platform like this is so cheap to run: a hackathon app is bursty. It does real work for a few hours on event day and essentially nothing the rest of the month, so you only ever pay for the traffic a single event actually generates. For this one, the whole monthly bill came to about $2:

The surprise, at least to me, is the shape of it: Hosting is the biggest line at $1.59 — not the database, not the functions. Firestore's real-time reads and writes during the event came to $0.41, and the Cloud Functions doing vote validation and RBAC-guarded writes cost all of $0.11. Google sign-in was free.

No servers to keep warm, no cluster to right-size, nothing to scale down after the event because there was never anything running between events. For a live app with auth, roles, real-time data and server-side validation, ~$2 is a remarkable price.

Roles, kept honest

Access control uses Firebase custom claims. When someone is made a judge or an organizer, a claim is set on their auth token, and the server checks that claim before allowing a privileged action. Because the role rides on the verified token rather than in a Firestore document the client can edit, a participant can't promote themselves by poking at the database — the Cloud Functions simply won't act on a request whose token doesn't carry the right claim.

The takeaway

Two things surprised me building this. First, how much of the grunt work Claude Code could carry while I kept my hands on the parts that actually needed an engineer. Second, how little a genuinely useful, real-time, multi-role event platform costs when you lean into serverless and let free tiers absorb bursty traffic.

You don't always need the heavy machinery. Sometimes the right answer really is a Next.js app, a handful of Cloud Functions, and a $2 invoice.

Links: live platform — Build With AI Sri Lanka.