Last post I argued that the matcher in our dating app cannot read photos because the TypeScript types make it impossible. A few people asked the obvious follow-up. If the matcher never sees a face, what does it see, and how does it decide who you should meet this week?
This post is that. Code samples, vector math, the one heuristic that does most of the work, and the three things we explicitly chose not to do. Repo is at github.com/donnowyu/soulmate-core, MIT.
The thing the matcher actually sees
A profile, in the eyes of the ranker, is this:
type Profile = {
prompts: PromptAnswers; // five short text answers
voice: VoiceTranscript; // ~30s recording, kept as text
intent: Intent; // 'friendship' | 'relationship' | 'community'
meta: ProfileMeta; // age band, language, city, locale
};
No photo field. No height. No income. No "tags." The strongest input by mass is the prompts plus the voice transcript, which together produce somewhere between 800 and 2,500 tokens of free-form text about how this person actually thinks.
That text is the matching substrate. Everything downstream is a function of it.
Step 1: turn text into a vector
We embed the concatenated prompts-plus-voice into a fixed-size vector using a text embedding model. The exact provider does not matter much. We use OpenAI's text-embedding-3-small (1536 dims) because it is cheap, multilingual, and good enough that the rest of the system survives provider churn.
// soulmate-core/src/embed.ts
export async function embedProfile(p: Profile): Promise<Vector> {
const text = formatForEmbedding(p);
const { data } = await openai.embeddings.create({
model: "text-embedding-3-small",
input: text,
});
return data[0].embedding as Vector;
}
function formatForEmbedding(p: Profile): string {
return [
...Object.values(p.prompts),
p.voice.text,
].filter(Boolean).join("\n\n");
}
The vector is what gets stored in Postgres, in a column typed vector(1536) thanks to pgvector. The profile row also stores the prompts and the voice transcript for display, but the matcher reads the vector and only the vector. Whatever else lives on the row is not in the function signature, so the compiler cannot accidentally let it leak in.
Step 2: find candidates with pgvector
Given a viewer with embedded vector v, the candidate query is a cosine-distance ANN lookup, filtered by intent overlap and a completed-profile gate:
SELECT id, embedding <=> $1 AS distance
FROM profiles
WHERE id != $2
AND completed_at IS NOT NULL
AND $3 = ANY(intents)
AND id NOT IN (SELECT target_id FROM blocks WHERE actor_id = $2)
ORDER BY embedding <=> $1
LIMIT 100;
<=> is the pgvector cosine-distance operator. The index is an HNSW on the embedding column so that "100 nearest" runs in milliseconds even at 100k+ profiles. Smaller-distance is more similar, since cosine-distance is 1 - cosine-similarity and the operator returns the distance form.
Two things to notice. First, the SQL itself reads no photo data. There is no photo table in this join. Second, the candidate set is bounded to 100. The ranker never sees more.
Step 3: rank the 100 with a more expensive signal
Cosine distance on embeddings is the cheap pass. It is right about taste, off about intent depth. Two people can write similarly and want very different things. So we re-rank the 100 with a second function that does not call an LLM but does look at structured signals the embedding tends to flatten.
// soulmate-core/src/rank.ts
export function rank(viewer: Profile, candidate: Profile): number {
const text = textSim(viewer, candidate); // 0..1
const intent = intentOverlap(viewer, candidate); // 0..1
const energy = energyMatch(viewer, candidate); // 0..1
const cadence = cadenceMatch(viewer, candidate); // 0..1
return (
text * 0.55 +
intent * 0.25 +
energy * 0.12 +
cadence * 0.08
);
}
textSim is the cosine similarity reconstructed from the distance returned by Postgres. intentOverlap weighs whether both sides want the same kind of connection (friendship, relationship, community), and how strongly. energyMatch and cadenceMatch are small heuristics derived from how much text the person wrote and how fast they answer messages historically. They mostly catch the case where two people are similar on substance but operate on incompatible rhythms.
The weights are not fitted. They are intuitions we did not have data to fit yet, and we kept them in code so any future change is a real diff and not a parameter twiddle that nobody notices. When we have enough signal to fit them, we will, and that PR will be reviewable in one page.
The function returns one float. We pick the top 5 above a 0.45 threshold for the weekly batch. If fewer than 5 cross the threshold, we send fewer. We do not pad.
What we explicitly did not do
Three things kept coming up in design review and we kept choosing not to.
We did not build a feed. There is no infinite-scroll candidate stream in this product. The weekly batch is the whole surface. The argument for a feed is engagement; we are intentionally trading engagement for a different shape of behavior, the one where the user opens the app rarely and deliberately.
We did not let the matcher see photos, not even as a tiebreaker. We considered the version where photos enter at rank time with a small weight, and rejected it for the obvious type-system reason and the less obvious behavioral one: as soon as the matcher can see faces, the production data collection of "what humans clicked on" starts encoding face preference into the ranker even if no explicit feature does. The cleanest defense is to make the photo bytes literally unreachable from the function. The compiler is the policy.
We did not put an LLM in the ranker. The temptation is real, especially since we are already embedding text. We resisted because an LLM in the loop makes the function opaque in a way that the four-feature linear combination is not. If a match is wrong, we can read the four numbers. We cannot read an LLM the same way.
Why this matters outside dating
The pattern, embedding-plus-pgvector-plus-small-linear-rerank, is good for any product where the primary signal is "how this user thinks" rather than "what this user clicked on." Documentation search, similar-issue triage, mentor matching, study-group formation. The dating context is just the one where the cost of being wrong is most visible to the user.
If you want to read the full implementation, it is at github.com/donnowyu/soulmate-core, all of it under MIT. The vector math is in src/rank.ts and src/embed.ts; the SQL is in db/migrations/. Tests cover the rank function and the edge cases of empty profiles, missing voices, and intent mismatch.
The product that wraps this engine is byvibration.com. It is the same idea taken all the way to a working app: you write, the engine reads how you think, you meet by mind not by face.
I work on byvibration. The framework above stands on its own; the product is one way to live inside it.---
title: "The four-line cron that decides who falls in love (in my dating app)"
published: true
canonical_url: , a dating and friendship app that matches by what people write, not by photos. The whole matcher described above is in the soulmate-core repo (MIT, 65 passing tests). If any of this resonates and you want to see how the four-feature rerank reads on real prompts, that is what the live site does.
SOCIAL SHARE CARD GENERATOR