What I Learned Building a Dating App That Punishes Engagement

Most dating apps make money when you don't meet anyone. Every night spent swiping is a night of subscription value and ad impressions. The product is quietly optimized for engagement, not for two people actually meeting.

I'm building the opposite — an app whose only job is to get you off your phone and into a real conversation, fast. I'm building it in Belgrade with a co-founder, and this is an honest write-up of what I've learned so far. I'm going to keep the exact mechanics vague on purpose (it's pre-launch), but the lessons are the useful part anyway.

Lesson 1: I designed a mechanic before designing the psychology

My first version demoed fine and was, when I sat with it honestly, bad. It was a flow, not a feeling. Nothing about it built anticipation or made anyone want to open the app twice.

The fix wasn't new screens. It was going back to actual research on how attraction and closeness form, and letting that research constrain the mechanic instead of decorating it. The meta-lesson: citing psychology papers while building generic features is worse than not citing them at all. If the research doesn't visibly shape what the user does, you're bluffing.

Lesson 2: symmetry is non-negotiable

Every interaction I designed that was one-directional felt broken the moment I prototyped it. One person acts, the other watches? Broken — that's a spotlight on one and a hunt for the other. One answers first? Broken — going first is exposure.

The versions that work are relentlessly simultaneous: both people act at the same moment, neither more exposed than the other. If you're building anything social, audit every interaction for asymmetric vulnerability. If one user is ever more exposed than the other at the same instant, you've designed anxiety into the product.

Lesson 3: your values will cost you revenue, and that's the point

I rejected freemium early — not for business reasons. In a dating product, any paid advantage means money buys romantic access. That corrupts the core promise. Revenue instead comes from the venue side, structured so users never pay to compete with each other. Sometimes the right monetization is the one your product values forbid, and you build around the hole.

Lesson 4: feel before finalize

The entire prototype is a single HTML/JS file. This sounds primitive, but it enforced the most important principle I've got: every mechanic sounded fine in a design doc — the bad first version included. Only tapping through a working prototype revealed which ones produced the feeling they were supposed to. A single file meant iteration in minutes and threw-away entire interaction models without ceremony.

Related: I've leaned on AI heavily for prototyping, and it taught me exactly where the line is. AI will hand you a polished, great-looking product almost instantly — screens, flow, structure, all of it. What it won't hand you is a mechanic that actually works. The surface is the easy part now. The core interaction, the thing the whole product depends on, is where AI kept giving me stuff that looked right and did nothing — and the polish is dangerous precisely because it hides that the hard part isn't solved. My honest take: you can't design good mechanics with AI alone yet. That part still needs a human who knows why it should work.

Why Belgrade, not San Francisco

I'm validating hyperlocally first, then expanding outward, with the US deliberately last. A location-dependent product lives or dies on density — you need enough of the right people in one place at one time. That's winnable neighborhood by neighborhood and unwinnable if you spread thin across a huge market on day one. It also means I can physically walk into venues and talk to owners, which is exactly what's happening now.

What's next

Field validation, then the production build — the genuinely hard engineering is real-time coordination between two live phones, which a scripted demo lets you dodge. I'll write a follow-up once real humans are meeting through it.

If you're building something whose job is to create a feeling rather than complete a task, I'd love to hear how you validate that. For me, prototypes said more than any spec ever did.