Rinkadia
A Finnish platform where professional ice hockey clubs find coaches, and the coach controls who gets to reach him. Built on Sharetribe with an anonymous coach side, a four-step reveal, and a privacy model that holds up against the raw API, not just the interface.
About Rinkadia
Rinkadia is a discovery platform for professional ice hockey staff. Clubs find coaches, contact them directly, and the coach decides who gets through. It was founded by Ville Kolppanen, who spent over fifteen seasons in professional hockey before building it, and who knew the problem from the inside.
That problem is the whole product. A coach who already has a job cannot let it be known that he is looking, because if his employer finds out he can lose the job he has. Hockey is a small world and word travels. So the usual marketplace answer, a searchable directory of people advertising their availability, is exactly the thing that cannot be built here.
The Challenge
Ville had rejected four agencies before he came to us, partly on visual quality. The build had to be premium and confident rather than another themed marketplace template, and it had to protect a person whose career is on the line in a product where most of the information is deliberately not shown.
Almost nothing about this is a standard marketplace:
- A coach has to be findable without being identifiable, which means an anonymous card carrying enough to be judged on and nothing that names him
- Privacy that holds at the API, not only in the interface. Anything a coach could query about himself is something his employer could eventually learn
- Two sides that must not mirror each other, when every instinct in marketplace design says to make them symmetrical
- A coach must be able to name a club that can never reach him, without that list ever becoming readable by anyone, least of all the club in it
- An interface where most values are withheld, which by default looks like a broken page rather than a product working as designed
- Coaches who will abandon a long form, so a profile that asks for as little as possible up front and still produces something a club can judge
Our Sharetribe Solution
We built Rinkadia on Sharetribe as a custom platform, with the privacy model as the architecture rather than a layer on top of it:
The Two Sides Deliberately Do Not Match
A coach is anonymous: a pseudonym, no photo, no name, no current club. A club is named and verified from the moment it appears, because a coach quietly looking will only answer someone he can see. So there is no anonymous club, no club directory and no club card to open. The asymmetry is the product, and mirroring one side onto the other is the single easiest way to break it.
A Four-Step Reveal
Browsing anonymous cards is free and unlimited. Opening one reveals the coach's name and full profile. Requesting a conversation takes a written message and reveals nothing further. Only when the coach accepts do his contact details appear. A decline never gives a reason, because a reason is itself information about him.
The Open Is Not A Transaction
Sharetribe shows a party every transaction they are in, so modelling the open as one would have let a coach query his own account and work out which club had looked at him. The interface could have hidden that; the raw API could not. So the open is a server endpoint that writes a single disclosure row instead, and a coach's dashboard shows a count with no name attached. A database constraint makes re-opening structurally impossible, and two colleagues clicking in the same second produce one row and one spend rather than a race.
Nothing Personal Is Ever Copied Into A Transaction
Identity and contact details live in the coach's own profile and are served live against the recorded state, never written into the conversation that unlocked them. Two things fall out of that for free: erasing an account needs no cleanup pass over old transactions, and a club always sees current details rather than a snapshot, so a coach who changes his number does not leave a stale one sitting in somebody's inbox.
A Coach Can Name A Club That Must Never Reach Him
Usually his current employer. One authorisation function enforces it at every action that could open or contact him, and an excluded club cannot see his card at all: not in search, not on a saved list, not through a kept link. The list is stored where only its owner can read it, is never searchable, and deliberately has no autocomplete, because confirming a typed club name would quietly tell coaches which clubs are customers.
A Language For Withheld Information
Most of this interface is information you cannot see yet, and the default treatment for that, a dashed grey box, reads as broken. On a platform sold on protecting people, what is withheld should look like the product working. So nothing is ever dashed, a withheld value keeps its shape so you can see it exists and roughly how long it is, and every redaction names the condition that would lift it. No padlock icon either: it says denied where this needs to say boundary.
One Line That Breaks The Grid
Every card sits on a strict grid, because a club scans dozens of them and they have to be comparable top to bottom. The one line the coach wrote about himself is the single element allowed to break it: it hangs into the gutter, sets a step larger, and takes the brand's gold gradient where every other block gets a plain hairline. The grid is what makes coaches comparable. That line is what makes them a person rather than a row in a table.
Every Email On One Pipeline
Mail leaves our own server rather than Sharetribe's built-in notifications, and the deciding case was mute. A muted conversation that still sends email means mute does not work, and a built-in notification cannot check whether a conversation is muted. Putting messages on our own pipeline to fix that brought every other email with it, so there is one source for wording and one place where a rule about who gets mailed can live.
The Results
Rinkadia runs as a platform where the privacy promise is structural rather than stated:
- A coach is findable without being identifiable, on a card carrying enough to be judged on and nothing that names him
- The promise holds at the API, not only on screen: a coach querying his own account cannot learn which club opened his profile, because there is no transaction there to read
- Erasure is automatic, because nothing personal was ever copied anywhere it would outlive the person it describes
- A coach can shut out a named club and that club cannot tell, see the card, or reach him through a saved link
- A redaction language that makes withheld information read as the product working rather than a page that failed to load
- A dark design system built from the client's own brand guidelines, with the marketplace template restyled into it rather than a second layer bolted beside it
- A review queue and admin surface for the Rinkadia team, with approve or reject, an internal note the applicant never sees, and a permanent record of who decided what
Technologies Used
Such a great group of people. Very easy to communicate. The whole process has been super easy and it's easy to follow where things are going. They react to suggestions very quickly, and that's why our team has felt very happy also.
Building Something Privacy Depends On?
When the promise has to hold at the API rather than in the interface, the privacy model is the architecture. We build marketplaces where what is hidden stays hidden, and what is shown is worth looking at.