METHODOLOGY
The Algorithm
How a 141-kink, 4-dimension compatibility model actually works. The math, the design choices, the trade-offs — explained without obfuscation. The first dating algorithm to publish itself.
01
Why a kink is more than a checkbox
Most dating apps treat kink as a binary preference. You're into rope bondage, or you're not. This is the same engineering shortcut that lets Tinder treat every user as essentially identical and then optimise for time-on-app rather than match quality.
Two people can both select "Rope bondage" and be completely incompatible. One wants to tie. The other wants to tie. Same checkbox, no scene. The kink isn't the unit of compatibility — the relationship to the kink is.
We capture four dimensions per kink, per person:
- Selection. Is this kink in your space at all?
- Role lean. Where do you sit on the giver/receiver spectrum for this specific kink? (Switch, leaning, dedicated, varies.)
- Centrality. How essential is this to your sexuality? Casual interest, moderate desire, or core need?
- Limit type. Open to exploring, soft limit (negotiable with care), or hard limit (absolute boundary).
141 kinks × 4 dimensions = 564 data points per profile. That's the raw material. The algorithm is what turns it into a match.
02
Per-kink compatibility
For each kink both people care about, we compute three independent factors and combine them.
RECIPROCITY (role compatibility)
c_reciprocity = max(1 − |1 − (lean_A + lean_B)|, 0) ^ 1.5
Two givers (lean=0+0): close to zero. A perfect giver/receiver pair (0+1): perfect 1.0. Two switches (0.5+0.5): 1.0. The exponent of 1.5 means small mismatches penalise modestly while large mismatches drop sharply.
SIGNIFICANCE (importance weighting)
m_user = (1 + 1.5 · centrality_user + 0.5 · centrality_partner) / 2
How much does this kink count toward each person's overall score? Your own centrality weighs more than your partner's, but theirs still counts — you should care that something matters to them. Range: 0.5 (both incidental) to 1.5 (both essential).
BOUNDARIES
b_penalty = 1.0 · (no soft limits) | 0.3 · (one soft limit)
Hard limits are filtered out before scoring. Soft limits don't disqualify the kink — they reduce its weight by 70% to reflect the added negotiation friction.
The per-kink score for each person is simply
c_reciprocity × m × b_penalty.
Notably, scores are directional — you and your match can see
different compatibility numbers because your essential kinks aren't the
same as theirs. That asymmetry is honest.
03
Hard limits are sacred
A hard limit on either side removes that kink from compatibility scoring entirely. But it also penalises overall coverage if the other person wanted it — specifically by 0.5 × the wanting person's centrality. You don't get to want something essential and have us hide that the only candidate is someone whose hard limit it is.
No app can know what you'll regret. But it can refuse to match around stated boundaries. This is one of two non-negotiables in the design.
04
From per-kink to overall match
We aggregate two ways — both matter.
QUALITY
quality = sum(actual_scores) / sum(max_possible_scores)
Of the kinks you both engage with, how good are the matches? A score of 0.85 means the average shared kink is 85% as compatible as it could possibly be.
COVERAGE
coverage = (sum(shared_centrality × reciprocity) − hard_limit_penalty) / total_centrality
What fraction of your needs does this person actually meet? Someone who matches perfectly on three things you barely care about and nothing on the things you'd die for is not a good match. Coverage catches that.
The headline percentage you see is
quality × coverage, clipped to [0, 1].
Coverage has a floor of 0.3 to prevent perfectly-compatible-but-narrow
matches from disappearing, but that floor is the only prosocial thumb on
the scale anywhere in the system.
05
What this algorithm refuses to do
- No desirability ranking. No "Elo score" tracking who matches with whom. We compute compatibility between specific pairs, full stop.
- No engagement-driven downranking. We don't suppress matches to push you toward premium tiers. There are no premium tiers.
- No infinite swipe. Match quality is not a function of how long you stay on the app.
- No data sharing. Kink data is special category data under GDPR Article 9. It does not leave our systems. Ever.
- No silent A/B tests on humans. Algorithm changes are versioned, dated, and visible.
06
What we're still figuring out
Honest answers to questions we don't yet know the answers to:
- The reciprocity exponent (1.5) is calibrated to feel right at the boundary cases. With real usage data, this will get more rigorous.
- The 0.3 coverage floor might be too high for highly-focused kinks. We may make it adaptive.
- We don't yet model the difference between "I want this with anyone" and "I want this with the right person." These feel like centrality but they're not.
- Group dynamics (threesomes, swinging) need their own scoring layer. Currently they're treated as shared interests, which under-models the actual matching problem.
The algorithm will change. When it does, you'll see it here, dated and explained, before it changes.
See it in action
Take the 5-minute quiz and watch your own data flow through these formulas.
DISCOVER YOUR DESIRE MAP