Founder Story

Who Built National Sports ID — And Why It Shows

Running youth sports before building software for it is not a nice origin story. It is why requests turn into features instead of tickets.

Who is actually building your youth sports software?

Most technology aimed at youth sports is built from the outside in. Someone identifies a large, fragmented market, maps a registration workflow, and ships a product. The workflow looks correct on a whiteboard. It rarely survives contact with a gym at 7:40 a.m. on the first Saturday of a tournament.

We did not start with a market. We started with a season. We knew what it cost — in credibility, not just in time — when a program had to send families home because a roster could not be confirmed, or when a tournament director had to rule on a disputed birth certificate in a hallway while eight teams waited for tip-off.

Ten years later, that is still the reference point. Every feature gets measured against whether it would have helped us on a Saturday morning at our own gym.

Why does that make requests faster to act on?

Because we already speak the language. When a director tells us they had a roster problem at check-in, we do not schedule a discovery call to find out what a check-in table is. We know the handful of things that sentence can mean, and we know which one it usually is.

That removes an entire layer most software companies cannot avoid. There is no product manager translating an organizer’s problem into a requirements document, no engineer interpreting that document without ever having stood at a scorer’s table, no round trip where the original point quietly gets lost. The person hearing the problem has lived the problem.

How do we know what organizers actually need?

We ask — and we know which questions are worth asking.

Requests arrive constantly: from support conversations, from event-day phone calls, from board members, from directors who email us in the middle of a Saturday because something is not working the way they expected. All of it gets read by people who have run programs.

That experience matters most in the gap between what an organization asks for and what it actually needs. An organizer will request a specific button. Underneath that request is usually a process problem — a step happening too late, a document being collected twice, a decision landing on the wrong person. Having run the operation ourselves, we can usually identify the real constraint in the first conversation instead of the fourth, and solve the problem rather than shipping the button.

Where do the features actually come from?

Directly from that loop. A few examples of things that exist because organizers told us they were needed, and because we recognized the problem immediately:

• Verification before the event, not at it. Players register first, then verify well ahead of game day. Disputes handled in advance are paperwork. Disputes handled at the table are incidents.
• Photo-verified rosters. Because the person checking in a team needs to match a face to a verified record, not a name to a printed list.
• Coach verification and background checks. Because the adults on the sideline matter as much as the athletes on the floor, and organizations kept asking who was vetting them.
• 365-day validity. Because families were re-submitting the same birth certificate for every event, and every re-submission was another chance for something to go wrong.
• Multi-sport support. Because the same family plays basketball in the winter and something else in the fall, and the paperwork should not start over each season.
• Document deletion after verification. Because a birth certificate is sensitive evidence, not inventory to be stockpiled. Once verification is complete, the submitted documents are deleted.

How fast do we move when something goes wrong mid-season?

Seasons do not pause for a release cycle. Neither do we.

Support is staffed for when events actually happen — weekends and game days included — because that is when problems surface. Escalations reach people who have organized events themselves, not a scripted first tier. And when something cannot wait, it gets handled in season rather than parked on an off-season roadmap.

That is a standard we set as customers of our own category before we were a company in it. We remember what it felt like to submit a support request on a Saturday and get a reply on Tuesday, after the tournament was already over and the damage was already done.

What does this mean for your season?

More than 1 million players and 150,000 coaches have been verified through the platform across more than 20,000 events. That scale did not come from guessing what organizations wanted. It came from a decade of organizations telling us, and from a team that recognized what they were describing because we had been there.

The Aspen Institute’s Project Play research keeps landing on the same load-bearing issues in youth sports: trust, access, and whether the people running events have real support. Those are not abstractions to us. They were our problems first.

You can build for that from a distance. We would rather build for it from memory — and from the phone call you make on Saturday morning.