One Profile, Two Products: What an Identity Layer Has to Survive

SportsID is an athlete identity platform. One athlete, one permanent ID, one record that follows them from a youth camp to a college roster to whatever comes next. Achievements confirmed by the coaches and organizations who were actually there. Stats, highlights, a profile someone can scan at a check-in table. It runs on the web and in the iOS and Android apps.

CoachID is a different product for a different person. Coaches build a professional profile, search openings and track applications. Organizations post roles and work through candidates. Youth leagues through professional teams.

Same company, Ryan McNeil's SportsID out of Atlanta. Two products, one idea underneath: an identity that means something because somebody else vouched for it.

That underneath part is where most of the engineering lives, and it's where I watch founders miss by an order of magnitude. The pitch sounds like a feature. "One profile, everywhere." It isn't a feature. It's a constraint you accept in the first week and pay for every week after.

An account is not an identity

Almost every product starts with accounts. A row in a users table, an email, a password hash, a foreign key on everything that belongs to them. That works until the day the same human needs to exist in two places at once.

An identity is a different object. It belongs to the person, not to the product. It outlives any single account, survives the athlete leaving one club for another, and carries claims that other people made about them. The moment you want a record to travel, you've stopped modeling accounts and started modeling identity, whether or not anyone said so out loud.

The practical difference shows up in one question: when an athlete moves from one organization to another, does the record move with them, or does a new one get created and the old one go stale? If your answer involves a support ticket and a manual merge, you have accounts.

Verification is the product

Anyone can build a profile where users type their own achievements. That's a form. The hard part, and the reason a record is worth anything to a college recruiter, is that a coach or an organization confirmed it.

Confirmation is a workflow, not a boolean. Someone has to be asked. They have to have standing to answer. Their answer has to be recorded with who said it and when, because an endorsement without a source is a rumor with better styling. And it has to survive that person leaving the club two years later.

I'd budget more time for this than for anything else in the first release. Teams usually do the opposite: they ship the profile, the feed and the highlight reels, then discover that the one screen everybody actually trusts is the one they left for later.

What breaks when each product owns its own users

The usual shape is two products, two user tables, and a plan to reconcile them later. It's the fastest way to ship the second thing and the most expensive decision in the building.

What goes wrong is not dramatic. It's small and constant. The same person signs up twice with two emails and nobody notices for a year. A coach verified in one product shows as unverified in the other, so the support queue fills with people asking why. A name change propagates to one place. Deleting an account in one product leaves the record in the other, which is a real problem once the person is a minor and a parent is asking.

Then the reconciliation project arrives, and it is never a data migration. It's a product decision about which of two conflicting histories is true, made a hundred thousand times, usually by whoever drew the short straw.

The alternative costs more up front. One record for the person, separate from their membership in any organization. Memberships, roles and endorsements hang off it with their own lifecycles. Products read the identity and write their own context. Nobody gets to add a users table.

The second product is the test

You cannot tell whether an identity layer is real until something other than the original product reads from it. Until then it's a users table with ambitions.

This is the part I'd push a founder on before the first line of code: name the second thing. Not to build it, just to design against it. A coach hiring marketplace next to an athlete record is a good example precisely because the overlap is partial. A coach is a person with credentials, and also the person who verifies somebody else's. If the model handles that, it will handle most of what comes later.

Ryan put the working relationship better than I would:

"What I appreciate most about Valery is that he takes the time to understand what we're trying to build at SportsID, not just the technical specs, but the vision behind it. Too many agencies and developers just want to know what buttons to build. Valery wants to know why those buttons matter. That's a big difference."

Ryan McNeil, Founder & CEO, SportsID, Inc.

That's not a compliment about niceness. On a product like this, the difference between knowing what to build and knowing why is the difference between a users table and something a recruiter will trust.

Five questions for your own build

Run these before you write the second product, not after.

1. When a person moves between organizations, does their record follow them without anyone touching a database?
2. Who is allowed to verify a claim, and what happens to that verification when the verifier leaves?
3. If the same human signs up twice, how do you find out, and who decides which history wins?
4. Can a second product read a profile without creating its own copy of the user?
5. When a parent asks you to delete a minor's data, how many systems do you have to visit?

If four of the five have clean answers, you're fine. If none do, the fix is cheaper this quarter than next year, and much cheaper than after the second product launches.

Where this leaves you

Not every product needs this. A single-tenant tool with one kind of user should keep its users table and spend the time on the thing customers pay for. The structure earns its keep when records have to be believed by someone who wasn't in the room, or when you already know a second product is coming.

Christopher Campbell, who runs marketing at SportsID, described the part that makes it work in practice:

"He clearly understood how to take CMO-level marketing and go-to-market requirements and translate them into product requirements, feature enhancements, and unobtrusive in-product marketing functionality. That translation layer, where many teams struggle, is where Valery consistently excelled."

Christopher Campbell, CMO, SportsID

Name your second product this week. Then go look at your users table and see whether it survives.

Related reading

• From idea to App Store in 21 days: what shipping a mobile product on a real deadline looks like.
• The $5K MVP playbook: stack, scope, what we cut: how we decide what goes in the first release and what waits.
• A support plan for startups: what happens after launch, when the data model meets real users.

More on startmatter.com: SaaS development, SportsID and CoachID.