DEV Community

gyani
gyani

Posted on

The four-line cron that decides who falls in love (in my dating app)

#architecture #automation #postgres #showdev

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)
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

<=> 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;
}
Enter fullscreen mode Exit fullscreen mode

That is the whole matcher.

Some notes on the weights:

  • sim carries the most weight because the prompt embedding is doing the real semantic work. The other three are guards.
  • intent is 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%.
  • geo is 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);
Enter fullscreen mode Exit fullscreen mode

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:

  1. Revert the Vercel cron to daily (0 0 * * *) so deploys flow again. Keep the function exactly as it is.
  2. 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
Enter fullscreen mode Exit fullscreen mode 
   <!-- ~/Library/LaunchAgents/com.byvibration.matches-hourly.plist -->
   <key>StartCalendarInterval</key>
   <dict><key>Minute</key><integer>0</integer></dict>
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)