Home/Writing/Build note

Let the code decide, let the model explain

300 founders, VCs and LPs in one room for one day, and every attendee asking the same question: who should I be talking to right now, and what do I say?

Saad Al-TamariFrom the work: Web3 Investor Day app · Apr–Jul 20262 min read
MatchingPrivacyProduct engineering

I built the whole platform for Decasonic’s Investor Day solo: an Expo mobile app, a React admin console and an Express API, about 60,000 hand-written lines of TypeScript. The part worth writing about is how it decided who should meet whom.

300attendees, live
21sessions, 47 speakers
~124API operations
188unit tests
The event, and the system behind it

The model never decides who matches

The pair-scoring function is pure, unit-tested code with no LLM in it. It decides who matches. The model’s only job is to write the human-readable reason, after the decision is made.

Score every pairpure, tested function
Exclude colleaguesdomain normalization
Cap per companyno fund hoards the room
Starvation floornobody gets zero
LLM writes the whyexplains, never decides
The matching pipeline: deterministic until the very last step

Fair by construction

Colleagues never match each other. Per-company caps stop one fund from taking every good introduction. A starvation floor guarantees that nobody ends the day with zero introductions, which is the failure a pure “best score wins” system produces for quieter attendees.

Lunch, as an algorithm

Lunch ran as a rotation: 9 companies, 9 timed rounds, and every attendee routed so they see every company once. A state machine invalidates a live rotation rather than corrupting it if something changes mid-event.

T1T2T3T4T5T6T7T8T9R1R2R3R4R5R6R7R8R9
One attendee’s lunch route: a different table (T) in each round (R), every company visited once

Privacy has to reach the prompt

Some attendees chose to hide their name. Masking it in the API response is not enough: if the full record reaches the model, the generated text can still name them. So masking happens server-side before any surface sees the data, including the LLM prompt.

Masked in the response only

The API hides the name, but the model saw it, and writes “you should meet Sarah from…” in a recommendation.

Masked before every surface

The record is masked on the server first. The app, the admin console and the prompt all receive the same masked data.

Why privacy is enforced as architecture, not as a filter on the way out

Boring guarantees

  • Scanning a QR code twice can’t double-count a check-in: idempotency is enforced by a database constraint, never read-then-write.
  • One OpenAPI spec generates the typed client and validation, so the app and the API cannot drift apart.
  • Every admin change writes to an audit log.

Use the model for what it is good at, language. Keep the decisions in code you can test.

Read next · Build noteWhen not to use your own gateway
Contact

Let's build

Building something like this, or want me to write about your problem next? One email is enough to start.