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: https://byvibration.com/essays/why-matching-layer-is-physically-blind
tags: typescript, postgres, webdev, supabase
I shipped a dating app five months ago. The matching engine is one Postgres function, a 100-line edge function, and a launchd job on my desk that hits a route every hour. No queue, no worker, no fancy ML stack. Here is the whole thing in order, and the small disaster that taught me to move the cron off Vercel.
What a "match" actually is
In most dating apps a match is a mutual swipe. In ours a match is a row in a suggested_matches table with a score above a threshold. Two profiles, one float in [0, 1], and a reason that gets shown to both sides.
The pipeline that creates that row is short.
launchd (hourly, on my Mac)
|
v
GET /api/cron/generate-matches (Next.js route, bearer-guarded)
|
v
Supabase Edge Function (Deno, batches users)
|
v
pgvector ANN (top 100 candidates per user, cosine over embedded prompts)
|
v
Linear scorer (four hand-weighted features over the candidate set)
|
v
INSERT into suggested_matches (above threshold only)
Five steps. The interesting line is the rerank.
The candidate generation step (and why I let pgvector do it)
Each user writes a small set of prompt responses on onboarding. We embed those responses with a single embedding call. That vector is one row in vibe_profiles.
Generating candidates for one user is then literally:
SELECT user_id, embedding <=> $1 AS cosine_distance
FROM vibe_profiles
WHERE user_id <> $1_user_id
AND completed_at IS NOT NULL
AND intent_overlap($1_intents, intents) > 0
ORDER BY embedding <=> $1
LIMIT 100;
<=> is pgvector's cosine distance operator. Smaller is closer. intent_overlap is a Postgres function that returns the size of the intersection between two intent arrays (relationship, friendship, community).
I do not run ANN search myself. I do not pre-cluster. I do not maintain a separate vector store. pgvector handles the index, the operator, the query plan, the lot. The whole "candidate generation" layer that other dating apps build entire microservices for is one ORDER BY clause.
This was the first decision that surprised me about how cheap the whole thing turned out to be.
The rerank step is four weighted features
Cosine alone is a good first pass and a bad final answer. Two profiles can be vector-near because both write reflectively and recurse on the same word, even if their actual lives have no overlap. So the top-100 candidates get rescored.
The rescorer is a linear function over four features, each in [0, 1]:
function vibeScore(seed: Profile, cand: Profile): number {
const sim = 1 - cosineDistance(seed.vec, cand.vec);
const intent = intentOverlap(seed.intents, cand.intents);
const cad = cadenceMatch(seed.cadence, cand.cadence);
const geo = geoFit(seed.geo, cand.geo);
return 0.55 * sim
+ 0.20 * intent
+ 0.15 * cad
+ 0.10 * geo;
}
That is the whole matcher.
Some notes on the weights:
-
simcarries the most weight because the prompt embedding is doing the real semantic work. The other three are guards. -
intentis binary-ish in practice: if you are here for community and I am here for a relationship, the overlap is small and the score collapses. -
cad(cadence) is a derived feature from how long a user takes to write a single prompt response. It is a very weak proxy for "how this person uses written language", but it correlates surprisingly well with whether a thread between two users sustains past day three. Worth its 15%. -
geois intentionally last and intentionally small. Most users care less about distance than they tell themselves they do, and weighting it more produces matches that are geographically convenient and texturally identical.
I tuned these by hand against the first ~50 matches that produced sustained threads, not by training a model. The set was too small for anything else. I will probably keep it that way until the set is too big for me to read in an afternoon, and even then I will resist.
The insert step is two lines
const above = scored.filter(s => s.score >= 0.45);
await sb.from("suggested_matches").upsert(above);
Threshold 0.45 was empirically the floor below which users stopped reaching out. There is no clever pruning beyond that. Upsert handles the case where the same pair gets surfaced by both directions of the cron in the same window.
The cron is where I burned a day
This is the part that humbled me.
When I wrote the Vercel cron entry, I set the schedule to 0 * * * * (every hour at the top of the hour). The Vercel CLI accepted it locally. The build then rejected it with a quiet error because hourly crons are not on the Hobby plan. Worse, the rejection blocked the deploy. Every subsequent push hung in the build queue with a confusing error. I had a stack of essays sitting in PRs that I could not figure out why were not landing.
I burned half a day before I tracked it down. The fix in the end was two parts:
- Revert the Vercel cron to daily (
0 0 * * *) so deploys flow again. Keep the function exactly as it is. - Trigger the function from my own machine, hourly, via launchd:
# scripts/matches_hourly.sh
curl -X GET \
-H "Authorization: Bearer $INTERNAL_CRON_SECRET" \
https://byvibration.com/api/cron/generate-matches
<!-- ~/Library/LaunchAgents/com.byvibration.matches-hourly.plist -->
<key>StartCalendarInterval</key>
<dict><key>Minute</key><integer>0</integer></dict>
The Vercel daily cron stays as a fallback for when the Mac is off. The hourly cadence comes from my own machine.
This feels janky in writing. It is fine in practice. A launchd entry on a Mac that is plugged in and caffeinated is more reliable than a Vercel cron on the free tier, and crucially it does not block deploys. The whole story of moving a cron off a hosted platform took thirty minutes, and the only thing it required was admitting that "real" infrastructure is not always the one with the prettier dashboard.
What I took from the build
Three things stayed with me after this pipeline landed.
The first is that the matcher is much smaller than people assume. Four features and a vector op. The intelligence is in the prompts the user writes, not in the math the engine does on top of them. If your matching layer is a regression model with 80 features, you are matching on noise.
The second is that cosine + a tiny linear rerank gets you a long way before you need to reach for anything heavier. The temptation to put a transformer-shaped thing in the rerank is real and almost always premature. Cosine over good prompt embeddings is already doing more lifting than any small model you would slot in.
The third is that you should put the cron where your deploys do not have to talk to it. The amount of incidental fragility you remove by detaching scheduled jobs from your hosting platform is genuinely surprising.
I work on byvibration, 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.