Dating and social
The engineering in a dating product is not the matching. It is everything that stops the product being unusable or unlisted: moderation that does not make the app feel broken, reporting flows that work in two taps, and a matching schema that survives its own success. We have run one of these in production since 2026.
Trust and safety is not a feature you add later. It determines the shape of the write path, because a policy that says "reviewed before another user sees it" is a statement about ordering, not about a moderation vendor. Get that wrong and the fix is a rewrite of the messaging layer.
Age assurance and identity verification are moving from optional to mandatory across the UK and EU. Both are integrations rather than builds, but both add a state to every account and a branch to every gated action, and neither is cheap to retrofit.
Deletion means deletion. A dating profile carries messages, photos, reports and match edges across several stores, and a request has to reach all of them within the statutory window. We build the deletion path early because doing it later means auditing every table twice.
Asked on nearly every call.
How fast does moderation have to be?+
Fast enough that the sender never waits, which in practice means the send path acknowledges before the verdict and the verdict lands behind it. The tail of a human review queue is minutes, so any design that blocks on it is a design that is sometimes broken.
What breaks first at scale?+
The matching queries. Mutual-interest lookups written as recursive CTEs are fine at ten thousand users and painful at a million. Denormalise the edges before you need to, not during an incident.
What do the app stores actually require?+
A reporting flow reachable in two taps, a block that takes effect immediately, and a documented moderation process. The first review rejection most dating apps get is for one of those three, not for the content itself.