What directing tournaments taught me about building sports operations software

I direct pickleball tournaments. I also build the software that runs them. Doing both has changed how I build in ways that reading requirements documents never would have.

Here is what the operational side taught me.

The user is standing up, outdoors, holding a paddle

Almost all software design assumes a seated user with two free hands, a stable network, and undivided attention. Sports operations has none of those. The person entering a score is standing on a court, in sunlight, possibly in wind, with a paddle in one hand, while four people wait for the next match assignment.

That single constraint invalidates most of the standard toolkit. Multi-step forms are out. Anything requiring precise touch targets is out. Anything that fails ungracefully when the network drops is out — venues are frequently gymnasiums and parks with genuinely poor connectivity.

You do not discover this from a feature list. You discover it the first time you try to use your own tool during an actual event and realize the primary action requires three taps and a scroll.

The bottleneck is never the thing people ask for

Ask organizers what they need and they will describe scheduling and scoring. Those are the visible parts. The actual bottleneck in a recurring session is almost always the twenty minutes before it starts: who is confirmed, who dropped out, who showed up unannounced, and how the format has to change as a result.

Scoring is a solved problem — a phone and a group chat handle it badly but adequately. Reconciling intended attendance with actual attendance, quickly, is what organizers are really spending their attention on, and it is what nobody names when asked.

This is the general lesson: people describe the part of the workflow they can see, not the part that costs the most. Discovery has to go looking for the second one.

Fairness is a design requirement, not a feature

In competitive recreational play, perceived fairness matters more than optimality. A matchup algorithm that produces statistically better games but that players cannot understand will be rejected, argued with, and eventually overridden manually — which means the software has failed regardless of how good the algorithm was.

Explainability is not a nice-to-have here. "You are playing this match because you have not played against this pair yet, and your ratings are within range" is a feature. It is the feature that makes people accept the output.

The same principle drove Atlas, in a completely different domain: a fitness tracker whose numbers a user cannot interpret is a number generator, not a tracker.

The money problem is separate, and nobody builds for it

Tournament directors run small businesses with genuinely unusual economics: entry fees at multiple tiers, venue costs split across days, equipment amortized across events, mileage, prize purses, and receipts arriving for weeks afterward.

Every generic accounting tool handles each piece. None of them assemble the one view that matters, which is: did this specific event make money, and where did it go. Directors end up running a spreadsheet per event, which drifts, and then reconciling at tax time under duress.

Sport Margin exists because I had this problem myself and could not find anything shaped like it. That is a recurring pattern in this portfolio, and it is worth being explicit about: the best problems to build for are the ones you personally experience, because you can tell when a solution is actually working rather than merely looking correct.

Real events are the only adequate test environment

You cannot simulate an event. Load is bursty — nothing for an hour, then forty results in ten minutes. Failures are social rather than technical: the tool works fine but one person interpreted the standings differently and now there is an argument to resolve. Edge cases are constant, because someone always arrives late, someone always leaves early, and a court always goes out of service.

Running events gives me a testing environment I could not buy. It also imposes a useful discipline: if the software fails at 9am on a Saturday, I am the one standing there fixing it in front of forty people. That is a strong incentive toward building things that work.

How this generalizes

None of this is really about pickleball. The transferable pattern is that the important requirements in any operational domain are the ones that only become visible under real conditions, with real stakes, in real time — and that a feature list gathered in a meeting will systematically miss them.

That is why engagements start with the current workflow and its workarounds rather than with a desired feature set. The workarounds are where the requirements are hiding.