Dating Apps Solved the Wrong Problem

Every dating app on your phone is great at one thing. It shows you people. Endless profiles, fast filters, a swipe in under a second. That part is basically solved. So why do these apps feel worse every year? Because showing you people was never the hard part. The hard part is who actually gets seen, by whom, and how often. That is the problem I have been working on. The longer I sat with it, the more it looked like a product decision dressed up as an algorithm.

Most apps solved the easy half

Ask a founder what their app does and you get some version of “we help you find the right person.” Watch the actual product and it does something smaller. It helps you browse people fast. Those are not the same thing. Browsing is discovery. You take a messy pool of strangers and make it scrollable and filterable. We are very good at that now. Nobody built the part that decides who you should actually meet this week, out of everyone you could meet.

Allocation is hard because attention runs out. There are only so many people you can seriously consider in a week. When an app hands that attention out badly, it does not break in an obvious way. It quietly sends almost all of it to a small group of very desirable people. Everyone else swipes into nothing. The dashboards still look healthy. The market underneath them is not.

Optimizing for engagement works against the user

Here is the uncomfortable part for product people. When you tune a dating app for engagement, more time in app, more swipes, more daily actives, you are picking a goal. That goal fights the thing the user actually wants, which is to leave. Someone who finds a real partner stops opening the app. So an app built to maximize swiping is, in practice, built to keep you single but busy.

This is a plain incentive problem. The concentration is not a bug someone forgot to fix. It is where an engagement goal naturally lands, because the most desirable profiles pull swipes from everyone else.

Gale–Shapley got the important part right

People have studied this for sixty years, just not inside an app. Two old algorithms taught me how matching should feel, and where they fall short for someone trying to get married.

Gale–Shapley (1962) is the one I build on, and I keep it at the center. The idea is simple and it holds up. Only put two people together when the interest runs both ways. No match should be great for one person and miserable for the other. It also guarantees stability, which means no two people will both want to drop their match for each other. That guarantee is the core of what I do. I did not throw it out.

What Gale–Shapley does not handle is the shape of the problem, not the idea behind it. It gives each person one partner, once. Real matchmaking is a few introductions every week. It needs two clean sides. And on its own it lets the most desirable people take everything while others get skipped. Irving (1985) fixed the two-sides issue by putting everyone in one pool, but it can come back and say no stable matching exists at all. You cannot tell a paying user the system could not seat them this week.

I changed the question, not the engine

So I changed the question I was asking. “What is the one stable pairing of everyone” is the wrong question for a market that keeps running. The better question is more practical. Given how compatible people are, and how fairly each person has been treated so far, who should meet whom this week?

That one change does a lot. A single pairing becomes a weekly allocation. One partner becomes a few introductions. Last week's results feed into this week's. And because it is an optimization with limits, it always returns something. The system can fail to find a great match. It cannot fail to run.

How FairMatch actually works

FairMatch is Gale–Shapley at the center with two things wrapped around it. Fairness, and a calendar. Every week it runs the same four steps.

First it filters. Hard rules like age, location, and dealbreakers decide who is even possible. Second it scores. For every possible pair it works out a compatibility number, built so a match only counts as good when it is good for both sides. That scoring is Gale–Shapley's mutuality, kept as is. Third it balances. It tracks who has been under-served and steers desirable partners toward them. Fourth it introduces. Everyone gets the same small number of introductions, and next week the loop runs again with new feedback.

The balance step has one dial, called lambda. At zero, the system only cares about compatibility and ignores who gets left out. Turn it up and it actively pushes sought-after people toward those who keep getting skipped. Drag it below and watch quality trade against reach.

One detail here took me a while to get right. The fairness bonus has to reward a pairing, not a person. The obvious version is “give lonely people extra points,” and it does nothing. With a fixed number of introductions per person, a per-person bonus cancels out in the math and changes the result by zero. The bonus only works when it rewards connecting a lonely person to a desirable one. It has to be about the pair. You only catch that by writing the objective down and checking it.

Underneath all of it, the thing we optimize for is still a stable, mutual match. Gale–Shapley's guarantee is the target. Fairness and the weekly cap sit on top of it, not in place of it.

Show the tradeoff, do not hide it

None of this is free, and I would rather be straight about that. Spreading desirable partners around costs you some raw match quality. The system measures exactly how much and reports it.

I think the honesty is part of the product. Most platforms hide what they optimize for, because if you saw it you would not like it. I would rather count the blocking pairs and put the number on screen. A product that can show you the tradeoff it picked, and why, is making a different promise about who it is for.

This is a product problem, not a math problem

It is tempting to file this under “neat algorithm.” It is not really about the algorithm. That part is the easy half. B-matching and min-cost flow are standard, fast, and decades old. The hard half is the set of calls a product person actually owns. Deciding the job is allocation, not engagement. Deciding fairness belongs in the objective at all. Deciding where on the tradeoff to sit. Deciding to show the stability cost instead of burying it.

Each of those is a judgment about who the product serves. The math just does what you tell it. The biggest decision in a matching product is not how you compute the matches. It is what you chose to optimize for in the first place. Get that wrong and a brilliant algorithm will efficiently give you the wrong result. Get it right and a basic solver gives you a market people can trust.