an okcupid alternative for people who miss the original questions app.

people searching "okcupid alternative" are usually doing one of two things. they are either fresh users who tried okcupid recently and bounced off the swipe-deck-with-a-thin-layer-of-questions-on-top experience, or they are older users who remember the original okcupid from the late 2000s and early 2010s and want that thing back. those two searchers are looking for different products, but the second group is the larger and more interesting one.

the original okcupid sold a real argument. you answered a long list of questions. you marked, for each one, which answers from a hypothetical match would be acceptable and how much each question mattered to you. a match percentage came out the back end. it was a working text-first matching engine, and it was the only one of its kind at scale. there is a generation of people who first met their now-spouse via an okcupid 92 percent match in 2011. those people are not nostalgic for nothing. the system actually worked, in the narrow sense that it produced introductions where the two parties had pre-aligned on the things they had already said mattered.

then the company was acquired, then it was acquired again, and somewhere in there the swipe became the primary interaction. the questions are still there, technically. they are just no longer the spine. the spine is the photo and the swipe, like everywhere else in the match group portfolio, and the questions are decoration that occasionally surfaces in a sidebar. people who remember the old version are not crazy when they say it feels different. it is different. the optimization function changed.

this essay is about what the original okcupid was actually doing under the hood, why no one rebuilt it for fifteen years, and what we have built at byvibration to bring that thing back, in a form that fits how people actually want to be matched in 2026.

what the original okcupid was structurally

at the engine level, the original okcupid was a constraint-satisfaction matcher with a user-weighted feature space. each question you answered defined a small axis. each axis had three pieces of information: your answer, the answers you would accept from a match, and how much you cared. the system computed, for every pair of users, the percentage of axes on which their declared values overlapped, weighted by the importance both of you had assigned. that percentage was the match score.

the design choice that made it work was that the user controlled the feature definitions. the system did not infer what you cared about from your behavior. it asked you, directly, and then matched on the answer. it was a self-declared compatibility model. it had problems (people lie to themselves; people answer aspirationally; nobody fills out 800 questions), but the failure mode was at least legible. you knew why it matched you with someone. you could read the agreed-on questions.

the modern dating-app stack does the opposite. it infers a feature vector from your clicks, your swipes, your photo, the time you spend hovering, and the system learns what you "actually like" via implicit feedback, then uses that vector to predict swipes. it is a recommendation system. it is the same shape as the system that picks your next youtube video. you cannot tell it what to optimize for, because the optimization target is "your next right swipe," which is not the same thing as your next good relationship and is sometimes the opposite.

the original okcupid did the harder, less profitable thing: it asked you what mattered, and then matched on what you said.

what we built at byvibration and how it relates

byvibration's matching engine, soulmate-core, is open source at github dot com slash donnowyu slash soulmate-core. it is the public layer that the byvibration app sits on. the engine has a strong design constraint baked into the type signature: the function that ranks two profiles cannot reach a photograph at all. there is no photo input in the matching function. the build fails if anyone tries to thread one through.

this is not the same as the original okcupid. it is a different generation of the same thesis. instead of asking users to answer 800 questions and weight each, byvibration asks each user to write a short prose self-description (a vibe profile), embeds it semantically, and matches on semantic proximity weighted by intent overlap and a few hard filters. the user does not have to weight individual axes. the embedding does that work. but the principle is the same as the old okcupid: the matching layer cannot see appearance, only declared signal, and the user controls the signal.

if you came to byvibration from a search like "okcupid alternative," the relevant translation is this: you are not going to find a return of the 800-questions interface, because almost no one fills 800 questions out anymore and the design space has moved on. but you will find an app where the engine that ranks people structurally cannot read photos, and where the input you give it is text you wrote about yourself, not behavior the system inferred from how you swipe. that is the closest 2026 equivalent to what the original okcupid was actually doing.

byvibration covers three connection intents in the same engine: dating, friendship, and community matching. you pick which intents you want when you build your profile. that is the most important practical difference from any modern dating-only app, and it is one of the reasons people stay even when the dating side of their search is quiet. when one intent is empty, the others are usually not.

who this essay is honest with

okcupid was good at one specific thing. it was good at producing introductions between people who had pre-stated a few hard preferences and one or two strong values and had filtered each other on those before either of them looked at a photo. it was bad at high-volume short-term matching. people who wanted a hookup mostly went elsewhere even in the okcupid era.

byvibration has a similar honest shape. it is good at producing introductions where two people have already aligned, in their prose self-description, on the things they care about. it is bad as a tool for scanning hundreds of profiles per session. there is no scrollable deck. there is no infinite supply. the engine returns a small number of well-aligned suggestions and asks you to actually read each one. that is the trade. if you are looking for volume, this is not your tool. if you are looking for the kind of introduction the old okcupid produced occasionally and accidentally as a side effect of its compatibility math, byvibration is built to produce that on purpose.

it is also worth being direct about what byvibration does not do. it does not have a giant existing user base. okcupid in 2011 had its scale earned over a decade. byvibration is small. small means the matching pool is smaller, and a search returning four good matches in your city is going to feel different from a swipe app returning four hundred. for some users that is correct (four real matches is more useful than four hundred fake ones). for other users it is wrong (if your city has very few onboarded users in your intent, the pool is just thin). this is the structural early-stage trade. we are honest about it.

what to do if you want to try

go to byvibration dot com, write a short prose vibe profile in your own words (the engine works on what you write, not what you select from a list), pick which connection intents you care about, and let the matching layer run. the layer runs on a regular cadence on the backend. you will get a small number of suggestions, ranked by semantic compatibility weighted by intent overlap. you read each one, the same way you would have read an old okcupid match. you decide whether to send an invitation.

it is free. there is no premium tier. there is no algorithmic boost you can buy. the engine ranks the same way for every user, because the engine is published openly and anyone can read what it does.

if the photo-blind constraint is the part you came in skeptical of, the engineering essay explaining why we removed the photo from the type signature is at byvibration dot com slash essays slash why-matching-layer-is-physically-blind, and the matching engine itself is at the github link above. the type signature really is the constraint. you can read it.

a 30-second test for any "questions-app" successor

if you are evaluating other apps that pitch themselves as the "real okcupid replacement," run this check. open the app's matching screen. look at the first few suggestions. ask yourself: can i tell, from the surface, why these specific people were suggested to me, in terms of things i declared mattered? if the answer is "no, it just feels random or photo-driven," the app is not a questions-app successor regardless of what the marketing says. if the answer is "yes, i can see a clear reason these specific people came up and it traces back to things i wrote about myself," the app is doing the old okcupid's work, even if the surface looks different.

byvibration passes that test on purpose. the test is the design.

if the deeper complaint is the format itself rather than okcupid specifically, the wider map of what an alternative actually has to change at the protocol layer is at byvibration.com/essays/alternative-to-dating-apps. that essay is the category parent this one is a child of.

i work on byvibration. it is the first product i have shipped that took a real engineering constraint and turned it into a marketing claim. the open-source matching engine is soulmate-core (github dot com slash donnowyu slash soulmate-core, MIT licensed, 65 unit tests). thank you for reading this far.