One meet day,start to finish.
Deck Buddy follows the same shape every meet has: set up before, work the sheet on deck, and score what just happened — plus what a swimmer or parent sees on the other side of the same app. Here's what each part actually does — tap the + marks on the mocks below for detail.
Before the meet
Getting the team and the meet set up before anyone touches the pool deck.

- 1Create a team, or join one with a code — a coach creates a team at sign-up and gets a join code back; swimmers and other coaches join with that code, no invite email.
- 2Bring in the roster — paste a CSV (first name, last name, age, gender); it's validated row by row and applied atomically, so one bad line doesn't block the rest.
- 3Build the meet — a four-step wizard: basics, sessions, events (with a duplicate guard and reordering), then rules — points table, relay multiplier, DQ sheet, and timing mode.
- 4Set entries and relays — swimmers get a seed time and a lane; the relay builder assembles legs from the roster.
- 5Lock the entry deadline — past the deadline the editing surface disappears, but scratches, relay swaps, export, and simulation keep working.
On deck
What the coach is actually looking at and touching while the meet is running.

- 1The sheet goes live — searchable, filterable to your own swimmers, with a Now marker sitting over the current event.
- 2The heat pointer moves the meet along — in manual timing mode, “Next heat ▸” (undoable) advances Current / Previous / On-Deck; in system mode, timeline estimates do it instead.
- 3The console board always shows something — the last finished event, then the newest event with times as LIVE — UNOFFICIAL, then the current event.
- 4A DQ is a list of codes, not one reason — pick from the built-in USA Swimming or VCSL sheets, or an imported league sheet; compact codes like DQ 1C,3D show everywhere a swim renders.
- 5A note is three taps — stroke, then part of the stroke, then the specific nitpick, plus a good / needs-work verdict.
- 6Scratches and relay swaps happen in place — a scratched leg gets a replacement swimmer without leaving the sheet.
After each event
What happens to a swim the moment it finishes.

- 1Results place and score by the meet's mode — dual (only home and away score, 6-4-3-2-1), champs (top-10 board, 11-9-8-7-6-5-4-3-2-1), or the full 16-place table.
- 2Standings update off the same points logic — no separate scoring pass, just the real placing and points numbers aggregated per team.
- 3Time drops show against seed — negative when a swimmer is faster than their seed time, positive when slower.
- 4Every swimmer gets an improvement band — p10 / p50 / p90 across their swims, so a coach can see where someone typically lands, not just their best.
- 5Results export as SDIF — fixed-width .sd3 files, handed off through the share sheet on native or downloaded on web; native .hy3 is proprietary and stays out of scope.
What the swimmer sees
The coach isn't the only person using Deck Buddy on meet day. Swimmers and parents get their own side of the same app.

- 1Sign up with the same team join code — pick swimmer or parent instead of coach, and land in a role-gated section built for that side.
- 2See the real meet sheet — the same live sheet and event details the coach is running, not a separate copy that can drift out of sync.
- 3Get projections for their own events — expected time, P(beat PB), P(top 3) — every number labeled ESTIMATE, off the same simulation engine that runs the coach's side.
- 4Pick a rival and compare — a per-event win probability against them, not just a raw time difference.
- 5Claim a roster spot and edit a profile, message the coach directly, and get in-app notifications.
- 6Ask the coach a question in Coach Q&A — structured asks with asked/answered status, separate from the message threads. One thing isn't built yet: push notifications. Said plainly, not implied.
And the whole time, it's estimating who wins.
A seeded Monte Carlo engine runs 2,000 simulations per swimmer over personal bests, seed times, this meet's drops, age, event load, and DQ history — reusing the same placing and points logic that scores the meet, not a separate model. Every prediction is labeled an estimate, lists the factors behind it, and is deterministic under its seed: run it again with the same inputs and you get the same number. When there isn't enough history for a factor, it's marked low data and skipped rather than guessed.
None of this needs a signal.
Every step above — roster imports, DQs, notes, scratches, results — queues locally and syncs when a connection comes back. Last write wins. Nothing on the deck waits on a spinner.