Arc: Can a Dating App Stop Pretending to Predict Chemistry?
Profile content barely predicts who people will be attracted to, yet every major dating app ranks and matches on it. I designed Arc end-to-end on the opposite premise: don't predict chemistry, engineer the situations where it forms and learn from every outcome. Then I tested the matching engine and the business model in simulation.
/// the problem
In speed-dating data, machine learning trained on 100+ profile measures could not predict who would desire whom (Joel, Eastwick & Finkel, 2017). A meta-analysis of 43 datasets and 11,000+ couples found relationship quality is driven by dynamics that emerge through interaction, not partner traits (Joel et al., PNAS 2020). Swipe apps optimize the part of the problem that isn't predictable, and they concentrate attention on a few consensus-attractive profiles.
/// the product
- A short, ML-bounded swipe phase. Active learning (uncertainty sampling over a Bayesian Bradley–Terry taste model) picks each photo and stops once the posterior converges, typically after 30–80 swipes. The output is an attraction floor for matching, not a ranking.
- Avatar-first matching. Members pick stylized avatars. Match cards lead with behavioral evidence from a situational interview, and real photos unlock only when both people accept. Attraction is already checked, so the decision can focus on the rest.
- The three-date arc. Talk, then Do, then Solve: structured dates with paired disclosure prompts and private post-date reflections that feed the model.
- An IRL layer. Activity integrations (Strava clubs, Meetup, Eventbrite) and a partner café and restaurant network with held tables and per-seated-date referral fees.
- Tiers. Free members get 5 matches a week and one pair at a time. Arc+ gets 10 a week and up to 3 concurrent pairs, always disclosed, with a free opt-out from being matched with people dating more than one member.
/// testing the matching engine
I built a 300×300 agent simulation over 26 weeks. Ground-truth date outcomes have a small predictable component (idiosyncratic taste × features, format fit, a little consensus attractiveness) and a large irreducible one, calibrated to the attraction-unpredictability literature. Arc observes taste only noisily. Three policies, all respecting dealbreakers:
- Swipe leaderboard: always pursue the most consensus-attractive candidate; popular targets reject less-attractive seekers.
- Random within dealbreakers.
- Arc engine: an attraction floor plus a Thompson-sampling Bayesian linear bandit updated weekly from date outcomes.
The leaderboard does worse than random (13.1% vs 29.5%) because most of its intros end in rejection. The bandit reaches 42.7% without predicting chemistry at all: it learns which observable structure (floor, format fit) matters from revealed outcomes and allocates exploration accordingly.
/// the business model
Revenue comes from Arc+ ($39/mo), a ~$6 referral per seated partner-venue date, and ticketed events. Member lifetimes are short on purpose (median ~5.5 months), because a couple leaving the app is the product working. The Monte Carlo draws lifetimes from a Weibull, usage from venue and event distributions, and CAC from the go-to-market channel mix.
The venue-referral line is what makes short lifetimes pay: it earns on dates rather than time-on-app, so the incentive to help people leave holds up in the P&L. Sensitivity analysis sets two guardrails: CAC under ~$85 and at least 1.5 seated dates per member per month.
/// caveats
These are modeled scenarios, not observations. The size of the bandit's advantage depends on the assumed share of predictable variance; the ordering (bandit > random > leaderboard) held across seeds. Funnel rates and pricing are hypotheses to replace with beta-cohort data, and the code is parameterized for that.
/// stack
Python NumPy Matplotlib Thompson sampling Bayesian linear models active learning Monte Carlo agent-based simulation HTML/CSS/JS prototyping Chart.js