How We Built Booki: From Group Chat Chaos to a Real Platform

Booki is a server-authoritative sportsbook management platform built on Supabase, with automated grading, a tamper-evident ledger, and atomic settlement reconciliation — designed for independent organizers who outgrew their spreadsheet. We built it because we were the friend group running picks through a group chat, and every existing solution was either overpriced enterprise PPH software or a toy that did not handle real money. This is how we turned that problem into a real platform.

The Problem

Every Sunday during football season, our group chat turned into chaos. Someone would text "I got Niners -3 for $50." Forty minutes later, someone else would claim they texted their pick before kickoff but nobody saw it. By Monday, half the group couldn't agree on what they owed.

The person running the book — our organizer — spent more time managing a spreadsheet than watching the games. Every pick had to be manually logged. Every result had to be looked up and cross-referenced. Every settlement turned into a chain of Venmo requests and "did you get my payment?" texts. One wrong cell in the spreadsheet and trust evaporated. There was no automated grading, no credit limit enforcement, no audit trail.

This is a universal problem. If you've ever organized bets among friends, you know. The fundamentals of running a friend-group book aren't complicated. The logistics are what kill you.

Why We Built It

We looked at what was already out there, and nothing fit. The options fell into two buckets:

Pay-per-head platforms. These are designed for professional operations running hundreds of players. They charge $10 or more per head per week, come with bloated feature sets, and look like they were designed in 2008. For a friend group of eight people, paying $80 a week to track some NFL picks is absurd. We did a full comparison of PPH vs manual systems and neither side was compelling for our use case.

Social betting apps. These are fun for casual parlays and bragging rights, but they don't handle real money flows. No credit limits, no ledger, no settlements. They're games, not tools.

What we wanted was something in between — a clean, modern tool that handled the actual work of running a small book. Real odds integration, real balances, real settlement reconciliation. No per-head fees. No enterprise onboarding. Just a tool that does what our spreadsheet was failing to do: automated grading, credit limit enforcement, parlay tracking, and a tamper-evident ledger.

So we built it.

Choosing the Stack

We started with a native iOS prototype in SwiftUI with SwiftData for local persistence. The reasoning was simple: our friend group was on iPhones, and native iOS gave us the best shot at a fast, polished experience. But we quickly realized the web needed to be the primary platform — it's accessible to everyone regardless of device, and there's no app store gatekeeping between us and our users.

For the backend, we picked Supabase. Postgres database, built-in auth, Edge Functions for server-side logic, and Realtime for live updates. The alternative was Firebase, but we wanted a relational database — betting data is inherently relational (events have markets, markets have odds, bets reference events and players and bookies). Trying to model that in Firestore's document model would have been a constant fight.

Supabase also gave us Edge Functions — Deno/TypeScript serverless functions that run close to the database. This turned out to be critical for the architecture we landed on.

Server-Authoritative Everything

Early on, we made the decision that shaped the entire product: all betting logic runs on the server. The client never calculates a balance, grades a bet, or creates a ledger entry. Every operation that touches money goes through an Edge Function that validates the request, checks business rules, and writes to the database atomically.

This is non-negotiable for financial software. The temptation with any client app is to do things locally for speed and sync later. That works for a notes app. It does not work when you are tracking who owes who $200. One inconsistency in a financial ledger and the whole system loses credibility.

Here's what the server-side architecture looks like in practice:

• Idempotency on every write. Every bet submission, settlement, and balance adjustment includes an idempotency key. If a request is retried (network hiccup, app backgrounded), the server returns the cached response instead of creating a duplicate entry. This is non-negotiable for financial operations.
• Tamper-evident ledger. Every ledger entry includes a hash of the previous entry, forming a chain. If anyone modifies a row directly in the database, the chain breaks and it's immediately detectable. Immutability triggers prevent updates and deletes on ledger rows entirely.
• Atomic settlements. When a bet is graded and settled, the grade, the ledger entry, and the balance update all happen in a single database transaction. No partial states, no orphaned records.
• Audit trail. Every operation emits an audit event. Who did what, when, and why. This is essential for dispute resolution — which, in a friend group, means being able to pull up exactly what happened when someone says "that's not what I bet."

We ended up with over 15 Edge Functions handling everything from bet submission to account deletion. Each one follows the same pattern: validate auth, check idempotency, validate business rules, execute atomically, emit audit event. It's repetitive by design.

The Web Dashboard

We knew the web had to be the primary experience. Organizers needed to manage their books from any device, any browser, no download required. So we built the web dashboard.

The stack is intentionally simple: Alpine.js for reactivity, plain CSS for styling, and the Supabase JavaScript client for data. No build step, no bundler, no framework overhead. It's a single-page app with hash-based routing that talks to the same Edge Functions as every other client.

This was only possible because of the server-authoritative architecture. The web dashboard doesn't contain any betting logic. It just calls the same server endpoints. One backend, zero duplicated business logic.

We added Stripe integration for subscriptions and a responsive sidebar layout. The whole thing is served as static files from the same domain. No separate deployment, no API gateway, no infrastructure to manage beyond what Supabase already provides.

What Surprised Us

Compliance vocabulary. We built the entire product using standard sports betting terminology — bookie, player, bet, parlay, wager. Then we realized these words carry legal baggage in certain contexts. We ended up doing a full vocabulary overhaul: bookie became "organizer," player became "member," bet became "pick," parlay became "multi-pick," wager became "stake." Every user-facing string, every landing page, every email template. The internal code still uses the original terms because renaming every type would have been a pointless refactor, but anything a user can see uses the approved language.

Live score timing. Automated grading sounds straightforward — check if the game is final, look at the score, grade the pick. In practice, knowing when to check is the hard part. We built a system that estimates game end times by sport (an NFL game is roughly 3.5 hours, an NBA game about 2.5) and only calls the scores API when a game is in its finishing window. Most scheduled checks result in zero API calls because no games are close to ending. This cut our odds integration API usage dramatically while still grading picks within minutes of a game going final.

Getting payments right. Subscription billing is straightforward in theory but full of edge cases. Status can change asynchronously — renewals, cancellations, billing retries. We built a webhook-based system where Stripe notifies our server of subscription changes, and the server updates the user's tier. The client just reads the current tier from the database. The result is a system where subscription state is always consistent between the payment provider and our backend.

Where We Are Now

The web dashboard is live. Organizers create a book, invite members, and start taking picks in under two minutes. Odds integration auto-imports lines from major sportsbooks. Automated grading resolves picks within minutes of a game going final. Settlement reconciliation is one tap. The ledger is tamper-evident and auditable. Credit limit enforcement and parlay tracking work out of the box.

We continue shipping: push notifications for real-time updates, expanded sport coverage, refined member experience. The foundation is solid — server-authoritative logic, atomic settlements, and a clean separation between clients and backend mean we ship new features and new platforms fast without consistency bugs.

If you have ever run a book out of a spreadsheet and a group chat, you know the pain. We built Booki because we lived it. The goal was never to build the next DraftKings — it was to build the tool we wished we had on Sunday morning when someone inevitably texts "wait, what did I bet?"

You can try Booki free with up to three members. No credit card, no per-head fees. Just a clean way to run your book.