Adham
Eissa

A discovery feed is the product. If the first thirty seconds are boring, nothing else in the app matters. But at launch there is no engagement history, no labelled data, and no traffic to learn from — the classic cold start, except the thing that needs bootstrapping is also the thing users judge you on immediately.

Running underneath it is a second problem with a much sharper edge. User-generated video is a trust-and-safety liability from the first upload: one unmoderated clip is not a bad metric, it is an app store removal — and a removal before launch is indistinguishable from never having launched at all.

Three pieces follow from that constraint: a serving path that can degrade inside a single request, a retrieval model cheap enough to train without traffic, and a moderation pipeline whose cost does not scale with upload volume. The whole surface it runs on is below.

The Go service owns the request end to end. Ranking is an interface with two implementations: a heuristic ranker that runs in-process, and a neural ranker that calls the Python service over gRPC. The neural path gets an 80 ms deadline. Deadline exceeded, transport error, and malformed response all resolve the same way — fall back inside the same request, no retry, no queue. The user gets a feed.

Two towers, trained jointly. UserTower and VideoTower are separate networks, but they read from the same category embedding table — a user’s taste for a category and a video’s membership in it are literally the same vectors. That is not a parameter-count optimisation; it removes an entire class of alignment problem and behaves far better when the interaction data is sparse, which pre-launch it always is.

Training uses in-batch InfoNCE: every other item in the batch acts as a negative, so a batch of N yields N−1 negatives per positive at no labelling cost. That is what makes the model trainable at the data volume a product actually has before it launches.

But InfoNCE alone gives you ranking — relative order — and nothing else. So there is a BCE auxiliary head on explicit interaction labels, which gives calibration: an absolute probability of engagement. You need both. Relative order tells you what to show first; a calibrated score tells you whether an item belongs in the feed at all.

The towers are the retrieval half. A LightGBM ranker sits behind them and does the ordering: retrieval narrows a corpus to a shortlist cheaply, and a gradient-boosted model — which handles heterogeneous tabular signals far better than an embedding dot product — decides what actually goes first. Both stages live inside the same 80 ms budget.

The heuristic that carries the cold start is not a placeholder either: it scores on quality, recency and affinity, then applies diversity re-ranking so a new user's first feed is varied rather than five clips from one creator.

Every upload fans out across three modalities before it can be published: sampled frames through NudeNet, audio through faster-whisper and then Detoxify on the transcript, and text — caption, title, description — through Detoxify directly. Those become a composite weighted score rather than three independent vetoes, because one channel at 0.6 is a genuinely different situation from three channels sitting at 0.5.

Then the part that matters: two thresholds, not one. A clear pass publishes, a clear fail rejects, and the band in between — roughly 5% of uploads — escalates to the Claude API for a judgement with context. A single threshold on a single model either over-blocks, which kills creator supply on a product that has none yet, or under-blocks, which gets you removed from a store. The band buys both, and it bounds cost by construction: the expensive call only ever sees the ambiguous tail.

The feed is the part worth drawing, but it is not the part that took the most time. The same service also carries:

Tarneeb is the trick-taking partnership game of the Gulf, the Levant and Egypt, and the interesting part is the bid: a commitment of 7 to 13 made under partial information, with scoring that punishes you for missing it. Cloning Jawaker means matching the scoring people already know — an audience that has played thousands of hands will find a rules discrepancy in minutes, and once they do, nothing else about the app gets the benefit of the doubt.

The harder problem is specific to partnership games: your partner is a bot. A weak opponent is a boring game. A weak partner is a broken game — the player loses hands they played correctly, blames the software, and is right to.

One self-contained HTML file. No server, no build step, no package manager, no external assets. That rules out audio files, sprite sheets and frameworks — and, most consequentially, it rules out learning anything from real players before shipping. There is no telemetry endpoint and no A/B infrastructure to lean on.

The game is a state machine — deal, bid, thirteen tricks, score the contract, settle the economy — with all state in plain objects and no framework mediating anything. Rendering is a function of state, persistence is localStorage, and every sound is synthesised on demand through the Web Audio API, so the asset payload is exactly zero bytes.

On top of the hand loop sit tournament flows and a layered monetisation model: AdMob, coin packs on region-appropriate payment rails, and tournament rake. The rails matter more than the model — a Gulf player and an Egyptian player do not reach for the same payment method, and a game that only takes one of them has quietly halved its own market.

The three difficulty levels differ in how much information the bot reasons over, not in how often it is told to play badly: hand strength for the bid, then suit and void tracking through play, then inference about what a partner’s plays imply about their hand. Randomised mistakes produce a bot that is weak and incoherent, which players read as broken rather than easy.

40,000+ hands, bot against bot. Hard difficulty converges to a ≈54% win rate — and the interesting thing about that number is that 54 is the target, not a ceiling I failed to clear. In a partnership game dealt at random, the deal is most of the variance. A bot winning 90% of its hands is not strong, it is peeking. 54% against the tier below it means the difficulty ladder is real, the AI is genuinely applying skill, and the game is still a game — which is the actual product requirement.