That line is from a 2012 slide, the second one in the deck I used to explain what we were actually building. EveryMatch was unofficially scoped as “everything but dating” — helping people find the right partner for any part of life that needs one: a sports team, a travel companion, a business collaborator. Not romance specifically. Just people or groups who fit.
The instinct, especially in 2012, was to treat this like a search problem. Someone types in criteria, you rank a list of candidates by relevance, best match on top. That’s how most product people think about “matching” by default, because search is the mental model everyone already has.
It doesn’t work, because a search has one direction. A match has two.
Why it has to work both ways
Every question in our system existed on both sides of the match at once: who I am, and who I’m looking for. A match wasn’t computed from one side’s criteria — it came from checking compatibility both ways at the same time: not just “does this candidate meet my criteria,” but “do I meet theirs, too.” And most of that compatibility was a matter of degree, not pass/fail — closer to a score than a checkbox. Rank a list against one query, and you’ve built a recommendation engine. Score two people’s criteria against each other in both directions, and you’ve built something else — closer to a negotiation than a lookup.
That’s the whole point. The weighting, the deal-breakers, the scoring math — all of it exists to make a two-way fit computable at scale, instead of something a matchmaker used to do by feel. In one internal walkthrough of the actual engine, a real pairing scored a 74% match — both directions checked out, but neither side was a perfect 100. That’s the normal outcome, not a failure state.
A concrete example
We modeled some criteria as ordinary preferences and others as deal-breakers. An ordinary preference contributes a percentage to the overall score. A deal-breaker doesn’t — if a deal-breaker question comes back a hard no, the entire match is zero, no matter how well everything else lines up. Location was a common one: define an acceptable radius, and a candidate outside it doesn’t get a discount, they get excluded. That distinction — most things are a matter of degree, a few things aren’t — is the difference between a system that feels like it understands people and one that just averages numbers.
What made it hard
The part I never fully solved is versioning. Once real matches exist, a live question isn’t just a form field anymore — it’s load-bearing. Some changes were safe: adjust a weight, add a new answer option, remove a question nobody answers. Others quietly broke everything: change what a question actually means, or convert it from “pick several” to “pick one,” and every previously computed match built on the old answer becomes wrong without anyone necessarily noticing. It’s the kind of problem that looks like a UI decision and is actually a data-model decision, and I’d take that more seriously earlier if I were starting over.
What I’d do differently
The technology wasn’t the mistake — plain SQL-based scoring, later a relational-style Mongo setup, nothing resembling big data or AI, because those weren’t really options yet. The mistake was in the name. “Every” meant we tried to build one generic pattern that could handle every domain — sports, travel, business, all of it — instead of committing to one first. We spent two years in stealth, and by the time we launched we couldn’t get traction; the ad spend went in too many directions at once. We eventually narrowed to sports, but by then it was too late and the money was gone.
If I were doing it today, I’d use better tools, obviously. But the bigger fix isn’t technical: focus one domain, prove it, then branch out — not the other way around. That’s still the part I think about more than the scoring math.